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

Hi Uz,

> unsigned __fastcall__ tgi_alloccolor (unsigned long color);

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.

There's no reason why there couldn't be an additional color allocator
for RGB values. That one could take the unsigned long or three
unsigned chars. The overhead of yet another entrypoint in the TGI
header seems smaller than having "everybody" deal with unsigned
long's.

Another approach could be to classify RGB based color allocation as
proprietary and have the drivers in question supply an IOCTL for that
scenario.

> If we're sure that there will never be a platform with more than 256 color
> entries, above function can return an unsigned char.

With an unsigend char return value we'd no limit the number color
"entries" but only the number of colors an application can use
simulataniously. I don't see an application working avtively with so
many colors.

>  * we have to decide if we want to leave the TGI colors platform depdendent
>    or not,

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.

>  * tgi_setpalette, tgi_getpalette, tgi_getdefpalette and tgi_getmaxcolor
>    will get deleted,

For the palette functions: Of course - that's what this is all about.
For the tgi_getmaxcolor: You ask to change it below (?)

>  * the description of tgi_getmaxcolor must be changed, but how?

My take:

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

- tgi_getmaxcolor should be deleted as there's no implied ordering of
the color "handles" returned by the color allocator.

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

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

> Anything else?

We need to be clear that there's a major semantic difference between
i.e. a 2-color paletted driver and a 16-color non-paletted driver if
an application...
- allocates two colors
- draws with them
- frees them
- allocates two other colors

This will cause re-coloring of the already drawn stuff on the paletted
driver only. So far so good. This is just where the abstraction ends.
If an application WANTS to know - for i.e. rather allocating less
colors rather then have re-coloring then it can check
tgi_getcolorcount.

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 re-coloring of the background) ? But that would allow
only for one single color allocation on monochrome drivers?

This is the only aspect known to me so far that seems troublesome with
the color allocation approach...

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