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

From: Daniel Serpell <>
Date: 2011-05-13 01:49:39
Hi Oliver!

On Thu, May 12, 2011 at 8:15 AM, Oliver Schmidt <> wrote:
[about atari colors]
> At least with the defaults as described above it doesn't work as-is
> with the color handling I described in my OP. I.e. TGI_COLOR_BLUE can
> only have the value 0 _OR_ the value 3.
> I don't know if the following is technically feasable but it would at
> least fit into the color handling I described:
> TGI_COLOR_<color names>  [4..15]
> - Mode 8 would need a default palette with 0=black, 1=white.
> - Mode 9 would need a runtime color value mapping making sure that
> black=0, white=1, red=2, green=3.
> - Mode 15 would need a default palette with  0=black, 1=white, 2=red, 3=green.
> - Mode 11 would probably not use TGI_COLOR_... macros at all but
> rather use the raw values 0..15 to describe the luminance.
> - Mode 10 would need a default palette matching the first 9 colors of mode 9.

Yes, that would work, there is no need for the default tgi colors to match the
default OS colors.

>>>> There is another option, the one used by earlier X windows functions. In those,
>>>> you can "allocate" a new color, and the driver returns the best approximation
>>>> of that color.
>> I think that is not that difficult, either for the driver or the program.
>> For example, this code would work:
>> [...]
>> In the driver, this would be implemented as:
>> [...]
> Let me see if I get that right...
> 1. The TGI_COLOR_... macros are only used as parameter to tgi_alloccolor().


> 2. The color allocation paradigm fully replaces the palettes paradigm.
> Because the program never ever handles a palette datastructure it
> doesn't need to know about the layout of a palette.


> Now 1.) and 2.) together nean that the values of the TGI_COLOR_...
> macros can be choosen freely because they are
> - not shared anymore between drivers on the same target as parameter
> to tgi_setcolor().
> - not used anymore as palette indexes.
> - not used anymore as palette values.
> It might however still be usefull to allow for target-specific
> TGI_COLOR... macro values as that might allow for simpler coloralloc()
> implementations - especially on targets with one/few/similiar TGI
> drivers.


> The pseudo-code in one of my previous postings needed to distinguish
> between beeing able to use a color "directly" as tgi_setcolor()
> parameter and the necessity to create a palette with that color und
> use the palette index. With the color allocation paradigm this
> distinction isn't necessary anymore.

That's why I think that color allocation is simpler.

> The color allocation paradigm doesn't necessarily include the
> complexities of color approximation. It can be as well a simple
> true/false decision of having the exact color / being able to allocate
> the exact color (in a palette).
> BTW: The tgi_alloccolor() driver code provided by Daniel could
> probably use reference counters instead of flags allowing several
> tgi_alloccolor() calls with the same parameter to share a palette
> entry...

Yes, you are right. This is as simple as doing "used_index[i]++"
and "if(used_index[i]) used_index[i]--;"

Also, perhaps a simple "tgi_freeallcolors()" could be implemented,
called from initialization.

> Is the above correct?

Yes, it's correct :-)

To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Fri May 13 01:49:58 2011

This archive was generated by hypermail 2.1.8 : 2011-05-13 01:50:02 CEST