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

Hi!

On Sat, May 14, 2011 at 08:53:27PM +0200, Oliver Schmidt wrote:
> > 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.

I don't think the long here are really a problem, since calls to
tgi_alloccolor are rare. For a few colors, a program would use separate calls,
for more colors, a program will probably use a table with a loop and just one
call to the function. So the additional overhead is small but we gain
flexibility. And, if we find out that this is really a problem, we can add a
second call that takes an unsigned or unsigned char.

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

Maybe something like a picture viewer, I don't know. How about the DTV, does
it have video modes with more than 256 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.

No, I share your opinion here.

> For the tgi_getmaxcolor: You ask to change it below (?)

This was a typo, I meant tgi_getcolorcount.

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

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

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.

> 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

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.

> However I somehow feel that the background color is somewhat special.

Yes, I forgot that one. We could introduce

    void __fastcall__ tgi_setbgcolor (unsigned color);

which sets the background color. Calling tgi_clear without setting the
background color might be either "undefined behaviour" or "implementation
defined behaviour", which means the driver chooses how to do it and we can
either document it or not - whatever seems to be easier.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.