On Wed, May 25, 2011 at 09:03:20AM -0400, Greg King wrote: > I previously gave an example of a program that does need to do something > about an approximation. That program wants to use a light/bright color > to highlight one of the graphics objects on its screen. But, a driver > might not support light colors. Therefore, it would substitute the dark > version of that color. The program needs to know about that act, so > that it can choose a different method of highlighting that graphics > object (when it is using that particular driver). Of course I don't know how TGI will be used in the future. But above seems rather obscure for me. TGI will never cover more than 30% of what people need. It's a simple method to draw some lines on the screen - not more. > That can be true when the platform has only one kind of driver; but, the > Atari platform has many different kinds. A versatile program might ask > the user which of those drivers he wants to use. Then, it would load, > and adjust itself to, that driver. That is why TGI has functions that > describe the driver's characteristics. It shouldn't be the job of the > program to know, ahead of time, _everything_ about _every_ TGI driver > that it might use. It should be the job of each driver to "explain" > itself. That explanation should include alerting the program when the > driver approximates a color! There's also the other extreme. If you look at the Lynx, you have exactly one video mode and one input device. Karri has done a great job of writing a TGI driver and a joystick driver - despite the fact that there will never be a second TGI driver or a second joystick driver. He is even going through all the trouble and link these drivers statically to every executable, because there has been no file I/O. For the Lynx (and this is also true for most other consoles), there is absolutely no advantage in loadable drivers. Now we're going to pack more and more stuff into the TGI driver that may be nice if one wants to port Photoshop to the C64, but completely useless for many of the supported platforms. If we go further this way, people will stop using the portable stuff, because it's too big and complex and use small target specific libraries instead. It seems that for the NES such a library is already in use. Having a general way to write target independent graphics platforms by quering the driver is a nice idea for larger platforms, where memory and CPU power aren't limiting factors. But even if you look on random Windows programs, you will notice that many of them don't run in monochrome or 16 color mode any more. And there are more than enough programs that don't adjust to uncommon screen resolutions. If this doesn't work on a platforms where it is technically possible to use this information, I don't think it will work on 6502 platforms. I would really prefer to keep the API as simple as possible. So lets at least try to keep it simple in the beginning. If we find out later that it is an absolute must to detect color approximation done by the driver, we can always add a function which asks the driver if a certain color will get approximated. 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 Fri May 27 20:59:56 2011
This archive was generated by hypermail 2.1.8 : 2011-05-27 20:59:58 CEST