From: "Oliver Schmidt"; on Sat., May 14, 2011; at 02:53 PM -0400 > >> /* Allocate and return one color. The function takes a color using one of >> * the TGI_COLOR_XXX constants, or (non-portable) some other value that >> * depends on the platform and driver. It returns an opaque, driver >> * dependent index that can be used in a call to tgi_setcolor, or >> * TGI_COLOR_INVALID if the given color cannot be allocated. In case >> * the given color is unavailable, the driver will allocate a similar >> * color and return its index. >> */ > > Hmm, do we really want to go into color approximation? What is the > metric for similarity? I'd rather go for a simple "Either I have what > you ask for, or I don't". The additional function allocating colors > from RGB values (see above) maybe could allow for approximation. An obvious metric is "use the dark color when the light/bright version isn't available". But, a program might need to know when it must use some method, other than a bright color, to highlight a graphics figure. Therefore, _automatic_ approximation is a bad idea. > >> Anything else? > > However, I somehow feel that the background color is somewhat special. > What exactly is the description of tgi_clear()? Maybe, the color > allocator should return one color less than the driver can display, to > keep the background -- and thus, the behaviour of tgi_clear() -- > consistent (and, to avoid the re-colorring of the background)? > But, that would allow for only one single color allocation > on monochrome drivers. And, we could not use the background color to erase pixels. ---------------------------------------------------------------------- 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 May 15 12:41:48 2011
This archive was generated by hypermail 2.1.8 : 2011-05-15 12:41:51 CEST