Hi Daniel, > 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? > 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... > 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. Regards, Oliver ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Wed May 11 18:52:19 2011
This archive was generated by hypermail 2.1.8 : 2011-05-11 18:52:22 CEST