Hi Fatih, On Sun, Oct 25, 2009 at 3:07 AM, Fatih Aygün <cyco130@yahoo.com> wrote: > Hi, > >> I must admit that this seems totally reasonable to me... >> If you have a two color driver with the valid values 0 and 1 then >> there should be two macros with the values 0 and 1. Most probably >> called COLOR_BLACK and COLOR_WHITE. > > I must disagree. I don't know much about c64 but the values we're > talking about are not colors, they are palette indices. So, one can > change the palette so that 0 is red and 1 is blue for example. In that > case defining macros as COLOR_BLACK and COLOR_WHITE will > simply be wrong. COLOR_BACK and COLOR_FORE is much more > reasonable but other graphics modes have more colors. So these > macros are only meaningfull for 2-color modes only. > > In other words, I think that COLOR_xxx macros belong to palette > definitions (tgi_setpalette) not to palette index selection (tgi_setcolor). I understand your argumentation well and in general agree - because it was mine when I discussed that matter some months ago in an off-list discussion with Uz. However Uz pointed out (hopefully not misrepresenting) that these thoughts are just beyond the TGI API specification. Think for example of tgi_getpixel(). It is described to return a color but the real implementations rather return a palette index. To do it "right" you'd need to do a reverse lookup in the palette. Result: The TGI API supplies three palette oriented functions. But in contrast to that all other functions only really work as described with the default palette. And therefore the COLOR_xxx macros are used in places where rather palette indexes should be used. It's a flaw in the TGI API specification. So it doesn't help if you do it "right" along your argumentation above if that's just not the way TGI is "in fact" used / implemented / expected to behave... Best, 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 Sun Oct 25 11:58:45 2009
This archive was generated by hypermail 2.1.8 : 2009-10-25 11:58:47 CET