Mail Archives: djgpp/1998/02/17/18:11:04
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?
You might wanna check out "DataTypes" on the Amiga OS (check v3.x), they
provide as part of the OS, a standard set of routines for manipulating data
with plug in read/write modules and standard "display" routines, which
includes displaying text, gfx, animations, playing sounds, etc. What each
module does is mostly to read from disk or ram and covert to a standard
internal format. Also to convert to it's format. Then, it's trivial for
any program that uses these OS features to support, well, pretty much all
file formats. With the user's choice of implimentation too. There are
tuneable JPG coders, speed vs quality. Sound, even compression, etc....
There are types of data, bitmap (converts to 32b truecolour internally),
digital sound (converts to 16b internally), text, etc.... Then any program
can use these functions to support any format because it always knows that
it'll get a 32b truecolour bitmap to do with as it pleases.
Most people these days would laugh at an OS that didn't abstract the
hardware, after all who would think it a good idea to have everyone write
their own HD controller code? :) Why then, does everybody think it's OK to
have everybody write their own JPG/PNG/GIF/PCX encoder/decoder? Or even if
you just link somebody else's, why have 10 copies of the same code? Or code
that can't be updated? With datatypes, a guy can write a great bitmap
editor, move to mars, and you can still add PNG support to his editor, you
don't have to beg him to add it or anything. :) And when the new and
improved RPNG comes out, you can just copy it into your datatypes directory
and like magic, everything supports RPNG or whatever.... This isn't
dreaming, the Amiga has actually had this for years....
Erik Max Francis wrote
>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).
Regardless of the file format, a 32b or 64b truecolour internal format
would pretty much handle them all. Each module only needs to know how to
read foo format and convert to/from the system's internal representation.
Then a standard set of routines can display, slice, dice or mutilate the
bitmap, before you spit it back out onto the screen, or disk as JPG, GIF,
PCX, C source, raw binary, whatever.....
Haveing the routine spit out a single block of 32b truecolour would allow
you to use any display tech you wanted 32, 24, 16, 15, 12, 8, or dither it
for a printer or whatever.
X
- Raw text -