Re: [cc65] TGI palettes (was: TGI colors revisited)

Hi,

>> What's your opinion on the discussed approach to step away
>> from a bgcolor and instead add a color parameter to tgi_clear? That
>> seems somewhat more straightforward to me.

> I don't like the approach very much, because it requires us to pass an
> additional color every time we want to "clear" anything. If we would for
> example add a draw mode for bitmapped fonts that "clears" the background
> behind the characters, we will have to pass the background color for this
> operation somehow to the routine.

I see. Maybe it's rather a misunderstanding than different opinions
anyway: Would the tgi_setbgcolor function take a color "handle"
returned from tgi_alloccolor? So that it would work similiar to
tgi_setcolor? If yes then I've no "objections".

> I could live with not having a background color if we remove the concept of
> "clearing" something completely from TGI. Currently, tgi_clear is just a
> special case of tgi_bar, which uses a predefined color and the coordinates of
> the whole screen. This can be easily special cased in the tgi_bar routine, so
> there's not really a big penalty.

But given the fact that tgi_init doesn't modify the buffer that would
mean that really _every_ program would need to get the screen
resolution etc...

> What I currently fear is that we're changing the tgi api to be more logical
> and portable, but far harder to grasp.

I see. Therefore the idea of pre-allocated black and white...

> I can easily think of several people
> who will have problems if you tell them that they have to allocate colors
> before being able to use them.

At least the TGI programs I'vee seen so far showed all traces from
being copy&pasted from the TGI demo. I'd say that even now the
boilerplate code is enough to drive new users to that approach. So it
maybe doesn't hurt too much to increase it.

> And that TGI_COLOR_RED is not meant to be
> passed to tgi_setcolor, but must be fed into tgi_alloccolor first, which may
> generate an error. If not, the result may then be passed to tgi_setcolor.

But given that the most popular cc65 target - at least by now - has
only a monochrome but paletted driver we can't shield the "typical"
user from complexity anyway - and the "strange" multi-usage of the
TGI_COLOR_... macros when it comes to palette handling isn't that easy
to grasp either - is it?

> BTW: What happens if I call tgi_alloccolor twice using TGI_COLOR_RED as an
> argument? Will the second call return an error? Will it return two different
> color handles or just one? Or does this depend on the platform? And, do I need
> to know this as a programmer, or not? :-)

In one of my lenghty messages I discussed this already. My opinion was
that the same handle is to be returned by all drivers. At that time we
were still presuming the presence of a tgi_freecolor and I suggested
reference counting. However now that tgi_freecolor is gone it seems
even more reasonable to go for identical handles - as far as I know
this behaviour of tgi_alloccolor is described as "omnipotence".

Regards,
Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.