Hi! I've been unavailable for several days - sorry. On Sat, May 07, 2011 at 12:21:31PM +0200, Oliver Schmidt wrote: > If yes: See this section from tgi.h: > ========== > void __fastcall__ tgi_setpalette (const unsigned char* palette); > /* Set the palette (not available with all drivers/hardware). palette is > * a pointer to as many entries as there are colors. > */ > ========== > - The prototype requires a pointer to unsigned char's. > - The comment states that the array size corresponds to the number of colors. > > I don't see any room for interpretation from the side of the TGI driver... It is in fact correct that when I made up the TGI API, the tgi_setpalette function was designed as you describe it. But I designed the API with little knowledge about the broad range of 6502 platforms available. I have quite some experience with BGI drivers, so TGI was influenced heavily by the API Borland designed in the eighties. And even while I knew that some of the design decisions were bad, I made the same decisions because TGI was planned to be "tiny". Some of the TGI functions have never been used (and tested) widely, and the palette functions are probably among them. So ... while your interpretation is correct, there may be room for improvement. The old Borland drivers had a palette based on char sized values because this is what the old EGA and VGA cards supported. When cards with 16 bit colors started to arrive, it was obvious that the old palette functions didn't work any longer. 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. Regards Uz -- Ullrich von Bassewitz uz@musoftware.de ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Mon May 9 18:31:42 2011
This archive was generated by hypermail 2.1.8 : 2011-05-09 18:31:45 CEST