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

From: Oliver Schmidt <ol.sc1web.de>
Date: 2011-05-12 14:15:56
Hi Daniel,

> mode 8: 2 colors paletted, default is index 0=blue, index  1=white.
> mode 9: 16 colors, no palette, 0=black, 1 to 15 are 15 different
>         colors of the same brightness.
> mode 10: 9 colors paletted.
> mode 11: 16 brightness, no palette. 0=dark, 15=light, all of
>          the same color.
> mode 15: 4 colors, paletted, default is 0=black, 1=red, 2=green, 3=blue.

Thanks for providing the information above :-) Unfortunately the
snapshot docs currently don't contain any anything at all about the
numerous Atari TGI drivers...

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.

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

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

Is the above correct?

Regards,
Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Thu May 12 14:16:14 2011

This archive was generated by hypermail 2.1.8 : 2011-05-12 14:16:18 CEST