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

Hi,

On Wed, May 11, 2011 at 7:33 AM, Oliver Schmidt <ol.sc@web.de> wrote:
> Hi,
>
>> [...]
>> What that means is that if there is a better idea to implement palette
>> functions in a portable way, I see no problem in changing the API. Even
>> removing the functions alltogether might be an option, because I cannot
>> imagine using them in a portable way.
>
> I see. After thinking about it for a while this is my take on it....
>
> Maybe it makes sense to classify the TGI driver into three categories:
>
> A) Drivers without palette support.
>
> B) Drivers with "few" simultanious colors (2-4) and a palette with
> "several" colors (8-16).
>
> C) Drivers with "several" simultanious colors (8-16) and a palette
> with "many" colors (>=64).

Remember that in Atari, you have a driver with few simultaneous
colors (ie, 1 or 2) from a palette with many (128) and at the same
time drivers with several colors (16) with no palette. And you can
select the driver at run-time.

> But instead of diving further into potential technical possibilities
> let's rather have a look at the topic for the user/program
> perspective:
>
> Starting from the presumption that TGI is about portable graphics
> programs it's quite clear that the need for "many" colors is a no-go
> for a TGI program. On the other hand it is quite reasonable that a
> program likes to draw let's say a red line. So what can a TGI driver
> offer to the program to allow for that red line?
>
> Drivers of type A) can't do much about it. In fact the target might
> not even have a macro TGI_COLOR_RED. The TGI program needs a #ifndef
> fallback to handle that scenario.
>
> Drivers of type B) can allow the program to setup a palette that
> contains TGI_COLOR_RED and use the corresponding palette index for
> drawing.
>
> Drivers of type C) can allow the program to just draw using
> TGI_COLOR_RED because the driver put that color into the default
> palette.
>
> So I think that from the user/program perspective a TGI palette API
> both is relevant. Therefore I would opt to NOT remove it.
>
> But the - at first glance likely surprising - result is that drivers
> of type C) should NOT offer TGI palette functions that map "several"
> colors to "many" colors as they
> - are unnecessary for the type of program TGI wants to support
> - make TGI programs fail because the programs will setup an invalid palette
>
> However a type C) driver could offer palette functions that
> (technically certainly unnecessarily) map i.e. "several" colors to
> "several" colors. Simply because that might increase the portability:
> A TGI program could both on a type B) and type C) driver setup a
> palette with two entries using TGI_COLOR_... macros and then draw
> using those two colors by using the colors 0 and 1.
>
> So the in my opinion most interesting question is: Should a type C)
> driver just offer no (working) palette functions at all or offer
> palette functions with "several" colors for compatibility reasons?
>
> Let's again look at it from the user/program perspective. I see two
> options for a portable TGI program to draw in red:
>
> 1.: Same code path for driver A) and driver C)
>
> - Is the TGI_COLOR_RED macro present ?
>  - Yes:
>    - Is the TGI_COLOR_RED macro value smaller than tgi_getcolorcount() ?
>      - Yes:
>        - tgi_setcolor(TGI_COLOR_RED)
>      - No:
>        - Setup a palette containing TGI_COLOR_RED
>        - Does tgi_setpalette(<mypalette>) return success ?
>        - Yes:
>            - tgi_setcolor(<myindex>)
>          - No:
>            - Some fallback
>  - No:
>    - Some fallback
>
> 2.: Same code path for driver B) and driver C)
>
> - Is the TGI_COLOR_RED macro present ?
>  - Yes:
>    - Setup a palette containing TGI_COLOR_RED
>    - Does tgi_setpalette(<mypalette>) return success ?
>      - Yes:
>        - tgi_setcolor(<myindex>)
>      - No:
>        - Is the TGI_COLOR_RED macro value smaller than tgi_getcolorcount() ?
>        - Yes:
>          - tgi_setcolor(TGI_COLOR_RED)
>        - No:
>          - Some fallback
>  - No:
>    - Some fallback
>

There is another option, the one used by earlier X windows functions. In those,
you can "allocate" a new color, and the driver returns the best approximation
of that color.

In your case, it could be like:

 // Get's the new color. Can fail if there are not enough colors!
 char index = tgi_alloccolor(TGI_COLOR_RED);
 if (index > TGI_MAX_COLOR_INDEX)
 {
  puts("Error, can not draw with less than X colors.");
  exit(1);
 }
 // Now, draw using the index
 tgi_setcolor(index);


This allows adapting to all different drivers, using the constants
"TGI_COLOR_*" defined to the best representation on the
platform.

On simple, two color pallete-less driver, the first call to tgi_alloccolor
can return the index that is most like the passed one (for example,
white is called with anything other than TGI_COLOR_BLACK) and
the next call simply returns other index.

The only missing functionality is palette changing effects. For that,
on drivers that support changing the palette, you can offer a new
function "tgi_altercolor(index, color)" to set the index to a new
color. Also, you could add a "tgi_darkencolor(index)" and a
"tgi_lightencolor(index)", useful to add transition effects, like:

 // Makes the index black in smooth steps.
 while(tgi_darkencolor(index))
  delay(1);

In drivers like c64, you need a table with the next "dark" color from
the current and the next "light" color.

Regards,

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