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

From: Greg King <>
Date: 2011-05-15 11:40:12
From: "Oliver Schmidt"; on Sat., May 14, 2011; at 02:53 PM -0400
>> /* Allocate and return one color. The function takes a color using
one of
>>  * the TGI_COLOR_XXX constants, or (non-portable) some other value
>>  * depends on the platform and driver. It returns an opaque,  driver
>>  * dependent index that can be used in a call to tgi_setcolor, or
>>  * TGI_COLOR_INVALID if the given color cannot be allocated. In case
>>  * the given color is unavailable, the driver will allocate a similar
>>  * color and return its index.
>>  */
> Hmm, do we really want to go into color approximation? What is the
> metric for similarity? I'd rather go for a simple "Either I have what
> you ask for, or I don't". The additional function allocating colors
> from RGB values (see above) maybe could allow for approximation.

An obvious metric is "use the dark color when the light/bright version
isn't available".  But, a program might need to know when it must use
some method, other than a bright color, to highlight a graphics figure.
Therefore, _automatic_ approximation is a bad idea.

>> Anything else?
> However, I somehow feel that the background color is somewhat special.
> What exactly is the description of tgi_clear()? Maybe, the color
> allocator should return one color less than the driver can display, to
> keep the background -- and thus, the behaviour of tgi_clear() --
> consistent (and, to avoid the re-colorring of the background)?
> But, that would allow for only one single color allocation
> on monochrome drivers.

And, we could not use the background color to erase pixels.

To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Sun May 15 12:41:48 2011

This archive was generated by hypermail 2.1.8 : 2011-05-15 12:41:51 CEST