Mail Archives: djgpp/1998/02/14/17:17:39
Glenn Reed wrote:
> Here is a proposal I have. Just posting it here to make sure it
> hasn't already been done. I have been thinking of writing a program
> (actually a C procedure) which will read in a bitmap file and using an
> appropriate callback function display it on the screen. In this way
> it can be written to be graphics card independent.
>
> I've thought of something similar to the following structure:
>
> LoadGraphicsFile (char *filename);
>
> DisplayGraphicsFile (char *filename, int x, int y,
> void (*PutPixel) (int x, int y, int PaletteEntry) );
>
> Where PutPixel is defined by the user. These two functions should be
> desigined to be ANSI compatible. Comments?
Not all graphics formats are indexed color (for instance, JPEG, which
you explicitly mention in the Subject line, is not), and so having a
palette entry is probably not sufficient.
What you'd end up with is different formats for the data depending on
the type. Unfortunately, there are an awful lot of conceivable types
you'd want to support -- 8-bit indexed, 16-bit indexed, 32-bit indexed,
8-bit RGB, 16-bit RGB, 8-bit ARGB, 8-bit CMYK, 8-bit HSB, etc.
Also, for efficiency's sake, you'd almost certainly want to send the
data line by line, or at least in arbitrary block sizes, rather than
pixel by pixel. The best solution would probably be something along the
lines of "send me the next n pixels," it would tell you the number of
pixels it actually sent (in case you asked for more than were left), and
the block of data associated with those pixels would be dependent on the
color space of the input (which would be specified to begin with by the
initialization routine).
--
Erik Max Francis, &tSftDotIotE / mailto:max AT alcyone DOT com
Alcyone Systems / http://www.alcyone.com/max/
San Jose, California, United States / icbm://+37.20.07/-121.53.38
\
"Life may be / the product of imperfections."
/ (Marclo Gleiser)
- Raw text -