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

Hi Oliver!

On Wed, May 11, 2011 at 12:52 PM, Oliver Schmidt <ol.sc@web.de> wrote:
>
>> 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.
>
> All my statements so far claim to justify such a scenario. Especially
> the pseudo codeline
>
> "Is the TGI_COLOR_RED macro value smaller than tgi_getcolorcount() ?"
>
> tries to find out if the TGI_COLOR_RED macro is usable as "direct"
> color in the currently at run-time selected driver. Such a macro would
> be expected to have a values > 1 but < 16 so that the pseudocode would
> do the right thing for both types of drivers - on the same target and
> therefore with the same value for TGI_COLOR_RED. Or am I wrong at some
> point?

I think it could work, but in atari you have at least:

mode 8: 2 colors paletted, default is index 0=blue, index  1=white.
mode 9: 16 colors, no palette, 0=black, 1 to 15 are 15 different
        colors of the same brightness.
mode 10: 9 colors paletted.
mode 11: 16 brightness, no palette. 0=dark, 15=light, all of
         the same color.
mode 15: 4 colors, paletted, default is 0=black, 1=red, 2=green, 3=blue.

>
>> 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.
>> [...]
>
> While I agree that this approach is conceptually the
> correct/right/best I personally feel that it is (way) too complicated
> both for the driver and program implementator. Just my two cents...

I think that is not that difficult, either for the driver or the program.
For example, this code would work:

 // get colors
 char black, red;
 black = tgi_alloccolor(TGI_COLOR_BLACK);
 red   = tgi_alloccolor(TGI_COLOR_RED);
 // draw
 tgi_clear();
 tgi_setcolor(red);
 tgi_bar(10,10,40,30);
 tgi_setcolor(black);
 tgi_circle(25,20,5);

In the driver, this would be implemented as:

 // Fixed mode, with no palette:
 static char color_map[]; // array with index for each color value
 char tgi_alloccolor(int color)
 {
  return color_map[color];
 }
 void tgi_freecolor(char index)
 {
  // NOP
 }

 // Palleted mode
 static char num_index; // Number of indexes
 static char used_index[max_index]; // flags
 char tgi_alloccolor(int color)
 {
  char i;
  for(i=0;i<max_index;i++)
   if( !used_index[i] )
    break;
  if( i == max_index )
   return max_index -1; // Returns last index if no more colors.
  set_palette(i,color);
  used_index[i] = 1;
  return i;
 }
 void tgi_freecolor(char index)
 {
  used_index[i] = 0;
 }

>
>> The only missing functionality is palette changing effects.
>
> Hm, it seems that we're still looking at the topic from quite
> different perspectives: Many TGI drivers don't support palettes.
> Therefore a portable TGI program can't even think about palette-based
> effects. For me this falls exactly into the same category sprites fall
> into. Great stuff but just not portable enough.
>
> What I wanted to point out in response to Uz' idea of dropping
> palettes altogether was this:
>
> TGI palettes aren't for useres/programs who WANT palettes to create
> something beyond the ordinary. TGI palettes are rather for
> users/programs who NEED palettes to reach the ordinary on as many
> targets/drivers as possible.
>

I agree, but with only one simple functions (tgi_darkencolor) you can
implement palette effects in atari and c64, making the fade-out
effects portable.

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