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

Hi,

>> Hmm, do we really want to go into color approximation? What is the
>> metric for similarity? I'd rather go for a simple "Either I have what
>> you ask for, or I don't". The additional function allocating colors
>> from RGB values (see above) maybe could allow for approximation.

> An obvious metric is "use the dark color when the light/bright version
> isn't available".

Hm, "obvious" might easily be sort of subjective... The Apple II
perspective: The hires mode allows beside black and white for orange,
blue, green and violet - no palette. You see - it's especially
annoying that red is missing. From that perspective a hue based
approximation would be most useful. It would return the orange color
handle when asking for red and thus allow to run programs asking for
red, green and blue...

>  But, a program might need to know when it must use
> some method, other than a bright color, to highlight a graphics figure.
> Therefore, _automatic_ approximation is a bad idea.

Full ACK.

>> However, I somehow feel that the background color is somewhat special.
>> What exactly is the description of tgi_clear()? Maybe, the color
>> allocator should return one color less than the driver can display, to
>> keep the background -- and thus, the behaviour of tgi_clear() --
>> consistent (and, to avoid the re-colorring of the background)?
>> But, that would allow for only one single color allocation
>> on monochrome drivers.

> And, we could not use the background color to erase pixels.

Okay, I'll give it a try:

From a technical perspective tgi_clear() sets the frame buffer to the
value zero. But the the collor allocation approach means that colors
are opaque handles - so zero has no special meaning. The app has no
way to handle interaction between color allocation on paletted drivers
and the result of tgi_clear(). The only outcome of this issue can be
that tgi_clear() has to go. It needs to be replaced by
tgi_fill(unsigend char color). With that change all (?) drawing TGI
primitives would work with some explicitly given color value.

Another somewhat related aspect is the semantics of tgi_init(). In the
current cc65 release it does an internal tgi_clear(). However after a
discussion I initiated we decided to drop that functionality from
tgi_init() - which is the case in the current snapshot. But what is
still left is that tgi_init() does an internal
tgi_setcolor(TGI_COLOR_WHITE). I see two options:

1. Remove that tgi_setcolor(TGI_COLOR_WHITE) from tgi_init(). That
means the app needs to take full control over allocating the color
handles it needs.

2. Have tgi_init() do an internal tgi_alloccolor(TGI_COLOR_WHITE) -
and for consistency probably tgi_alloccolor(TGI_COLOR_BLACK) too - and
then the tgi_setcolor(white). Most likely that would mean to introduce
something like two "standard color handles" sort of similiar to the
three standard file i/o handles. Apps interested in black&white only
could use those standard handles and get along without any explicit
color allocation calls.

Probably 2.) is preferable because b&w apps would look like today with
the one exception of tgi_clear() being replaced by
tgi_fill(TGI_STD_BLACK). I don't know if a wrapper to that call named
tgi_clear() would actually be beneficial or rather confusing...

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