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

Hi Oliver!

On Thu, May 12, 2011 at 8:15 AM, Oliver Schmidt <ol.sc@web.de> 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_BLACK 0
> TGI_COLOR_WHITE 1
> TGI_COLOR_RED 2
> TGI_COLOR_GREEN 3
> 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().

Yes.

> 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.

Yes.

> 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.

Yes!

> 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 :-)

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