Re: [cc65] Re: TGI colors revisited

From: "Oliver Schmidt"; on Tues, May 03, 2011; at 08:57 AM -0400
>
>>> - 'lynx' has only a 16-color mode driver. So the (black/white = 0/1)
>>> rules do _NOT_ above apply. In fact white has the value $0F so this
>>> target benefits from the target-specific TGI_COLOR_... macros. I
>>> defined the 16 macros to be identical to the TGI_COLOR_... macros.
>>> Please speak up if this is wrong and needs to be changed!
>
> If the Lynx doesn't have conio support, then the stuff I put into
> <lynx.h> doesn't make sense. Instead of
>
> #define COLOR_BLACK 0x00
> #define TGI_COLOR_BLACK COLOR_BLACK
>
> it should rather just be
>
> #define TGI_COLOR_BLACK 0x00

The Lynx library _will_ have conio support (20 columns by 12 lines)!
The default text colors will be the same as the default graphics colors.
You can leave those macroes as they are now.

>
>>> However, the
>>> default palette has totally different values than the TGI_COLOR_...
>>> macros -- they even seem to be 16-bit values;
>>> so, there is some work in
>>> the drivers necessary -- which I can't do.
>>
>> The actual 16-bit value for a color is RGB with 4 bits
>> for each component. (The order is $0GBR to confuse the programmers.)
>
> I understand and I believe that this is the very thing that needs to
> be "abstracted away" in the driver.
>
>> I easily can change all the color values to comply with the TGI_COLOR
>> defines. Black can be 0, and white can be 1.
>
> As I tried to point out, there's no reason to map
> TGI_COLOR_BLACK/TGI_COLOR_WHITE to 0/1 if that isn't the "natural"
> choice for the the Lynx.
>
>> Please tell me what the default TGI-palette should look like.
>
> Just to make sure there's no misunderstanding which might result in
> potentially unnecessary work on your side:
>
> - The default palette needs to contain the values 0, 1, ..., 14, 15,
> in that order.
>
> - The TGI functions tgi_setpalette/tgi_getpalette/tgi_getdefpalette
> need to operate on palettes being 16 bytes large.
> So, there needs to be some mapping between the "TGI palette"
> and the "12-bit palette".
>
> - If you feel that this doesn't give a fine-grained enough
> control over the colors used, you might consider to provide some
> tgi_ioctl function to manipulate the 12-bit palette directly.

My reason for not replying sooner is that the implications are too
complex to be digested quickly.  But, I see that I must speak up before
the misunderstandings go too far.

First things first:  Those new rules mean that tgi_getdefpalette() has
become pointless!  It always will return the exact same thing -- on all
platforms.  A program can generate an ascending array if it's needed.
When it isn't needed, that function just wastes space in the driver.

The Lynx's graphics engine uses two palettes: the hardware palette is
the 12-bit one that Karri described, the software palette actually is a
mapping table.  The number that we give to tgi_setcolor() is used as an
index into the pen (or paint-brush) table; the value from that table is
used as an index into the hardware-palette table.  That second
(hardware) index is stored on the screen.

In order to allow the palette manipulation that you have described
earlier, we must use the brush table as the TGI palette.  But, after the
palette is changed, there might not be a one-to-one match between the
values that were given to tgi_setcolor() and the values that are
returned when tgi_getpixel() is used on "old" pixels (ones that were
drawn before the palette was changed)!

We don't need a tgi_ioctl function for the hardware palette.  It sits in
global chip registers; we can access it outside of TGI.

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