Re: [cc65] Re: TGI colors revisited

On 03.05.2011 22:01, Greg King wrote:
> The Lynx library _will_ have conio support (20 columns by 12 lines)!

Nice :)

> First things first:  Those new rules mean that tgi_getdefpalette() has
> become pointless!  It always will return the exact same thing -- on all
> platforms.

The idea is cool but I wonder if it is realistic. I mean some hardware 
may only support stupid colors while the Lynx has a large set of nice 
colors. Is there a risk to lose red,green,blue,orange, levels of grey?

After all it is important to have usable colors.

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

True. The most used palette functions are fade-in, fade-out and fade-to. 
In these cases the pixels are unchanged but the RGB colors are smoothly 
changed from one setting to another. This is very nice in games.

--
Karri

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