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

From: Greg King <greg.king41verizon.net>
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
that
>>  * 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 majordomo@musoftware.de 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