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

Hi,

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

Okay.

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

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