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

From: Oliver Schmidt <>
Date: 2011-05-22 23:36:06

>> Hm, do we really want to spend the overhaed of unsigned long's just
>> for the RGB scenario? I'd rather go for an unsigned char parameter.

> I don't think the long here are really a problem, since calls to
> tgi_alloccolor are rare.

I see.

>> I personally would stay with the recently introduced platform
>> dependent values but if the "general opinion" turns out to be
>> different I'm okay with that too.

> No, I share your opinion here.


>> - tgi_getcolorcount should be described as returning the number of
>> unique colors that can be successfully allocated. As far as I see the
>> implementation stays as-is for all drivers.

> But how does that help? A programmer can still not know if a call to
> tgi_alloccolor will fail, even if less colors are allocated.

I see. So tgi_getcolorcount is to be removed too?

>> Hm, 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 addional function allocating colors from
>> RGB values (see above) could maybe allow for approxamation...

> Ok, how about "In case the given color is unavailable, the driver MAY allocate
> a similar color and return its index." This leaves it open to the driver and
> will help in cases where approximation is easy - for example for a monochrome
> driver that may return black for TGI_COLOR_BLACK and white for all others.

With "MAY" it makes sense to me too.

> I wouldn't allow freeing colors because that complicates things a lot. So
> tgi_alloccolor is a one way operation. The table is cleared when calling
> tgi_init.

I see. Omitting color freeing both reduces implementation complexity
and behaviour deviation.

To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Sun May 22 23:36:27 2011

This archive was generated by hypermail 2.1.8 : 2011-05-22 23:36:31 CEST