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

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

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

As you see it's just a matter of code ordering. So the simplest (and
smallest !) approach for type C) drivers would be to hide the palette
from the TGI API and behave like drivers without palette support.

Just to make sure there's no misunderstanding: According to the
approach described so far it's no option to keep TGI palete functions
with "many" colors as a portable TGI program would create and use an
invalid palette.

Ideas, comments, opinions, objections?

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