/* superview/svgfxbuffer.h */ /* Version : 11.3 */ /* Date : 30.04.1995 */ /* Written by : Andreas R. Kleinert */ #ifndef SUPERVIEW_SVGFXBUFFER_H #define SUPERVIEW_SVGFXBUFFER_H #ifndef SUPERVIEW_SUPERVIEW_H #include #endif /* SUPERVIEW_SUPERVIEW_H */ struct SV_GfxBuffer { /* All pointers (e.g. svgfx_Buffer) have to be and are AllocVec()'ed (as well as usually the structure itself). If you did not allocate SV_GfxBuffers by yourself, you must neither free them nor do write-accesses to them. If you allocated them by yourself, you also have to free them by yourself - if no one else is still accessing them. */ ULONG svgfx_Version; /* structure version, see below */ ULONG svgfx_BufferType; /* Data organization, see below */ ULONG svgfx_Width; /* Graphic's Width */ ULONG svgfx_Height; /* Graphic's Height */ ULONG svgfx_ColorDepth; /* Graphic's ColorDepth */ ULONG svgfx_ViewMode32; /* if NULL, best ScreenMode is suggested */ /* (results in LowRes, if not changed). */ UBYTE svgfx_Colors[256][3]; /* For ColorDepth <= 8 : 3-Byte RGB entries */ /* >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> begin of "case-dependent" entries >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ONLY if svgfx_BufferType == SVGFX_BUFFERTYPE_BITPLANE, else NULL. svgfx_BytesPerLine : size of one row of a plane in Bytes = Bytes per Row : (( [width] +7)>>3) Number of Rows per Plane : [height] Number of Planes : [depth] */ ULONG svgfx_BytesPerLine; /* see above */ ULONG svgfx_PixelBits; /* see below */ /* ONLY if svgfx_BufferType == SVGFX_BUFFERTYPE_ONEPLANE, else NULL. svgfx_PixelBits : Bits Per Pixel (8, 16, 24, ...) => Bytes per Row : (svgfx_PixelBits>>3) * [width] Number of Rows per Plane : [height] Number of Planes : ONE <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< end of "case-dependent" entries <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< */ APTR svgfx_Buffer; /* any kind of memory (no chip ram needed) */ ULONG svgfx_BufferSize; /* if you want to copy it ... */ /* ----------------------------------------------------------------------- */ /* Begin of Version 2 entries: Check Version before reading further */ /* ----------------------------------------------------------------------- */ ULONG svgfx_NativeDIPF; /* This one contains the DIPF_-Flags, which */ /* have been native to the original ViewMode */ /* of the graphics. So you may determine */ /* whether a graphics is HAM, EHB or such. */ /* May be NULL for non-Amiga sources. */ /* ----------------------------------------------------------------------- */ /* Size of structure may grow in future versions... */ /* ----------------------------------------------------------------------- */ }; #define SVGFX_VERSION (1) /* this is the minimum */ #define SVGFX_ACT_VERSION (2) /* this is the current max. version */ /* When copying a GfxBuffer you usually refer to sizeof(struct SV_GfxBuffer), which differs from version to version. So you have to check, whether svgfx_Version is > SVGFX_ACT_VERSION. If it is, just set svgfx_Version = SVGFX_ACT_VERSION, else keep it untouched (or maybe set the version you need). */ #define SVGFX_BUFFERTYPE_BITPLANE (1) /* Amiga-like BitPlanes (unaligned) */ #define SVGFX_BUFFERTYPE_ONEPLANE (2) /* single Byte-/Word-/24 Bit-Plane */ /* there may be more types in the future */ /* (at least reject all types > 2) */ /* Some words about interpreting and using SV_GfxBuffer structures ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SVGFX_BUFFERTYPE_BITPLANE ========================= SVGFX_BUFFERTYPE_BITPLANE means, that there's plane stored after plane, but _no padding_ of the lines is done (e.g. to word- or longword- boundaries), which is different from Amiga-BPs or ACBM-ABITs : | line 1 of plane 1 | (each with svgfx_BytesPerLine) | ... | | line [height] of plane 1 | ... | line 1 of plane [] | | ... | | line [height] of plane [] | ... | line 1 of plane [depth] | | ... | | line [height] of plane [depth] | SVGFX_BUFFERTYPE_BITPLANE is only used upto 256 Colors at the time : 16 and 24 Bit data will usually not be stored this way. SVGFX_BUFFERTYPE_ONEPLANE ========================= SVGFX_BUFFERTYPE_ONEPLANE means, that there's only one single plane stored. The size of one pixel in this plane is defined in svgfx_PixelBits (currently 8 for ChunkyPixel graphics or 24 for 24 Bit graphics). | line 1 with ([PixelBits] / 8) * [width] Bytes | | ... | | line [height] with ([PixelBits] / 8) * [width] Bytes | 8 Bit : Chunky Pixel (ColorMap) = 8 ; ColorRegister index 16 Bit : R:G:B = 5:5:5:1 ; + 1 Bit Alpha Channel : IGNORED 24 Bit : R:G:B = 8:8:8 ; RGB-value So 8 Bit Data contains [width] bytes in a row, 16 Bit Data contains [width]*2 bytes in a row and 24 Bit Data contains [width]*3 bytes in a row. Currently you will not find any SV_GfxBuffers with 16 Bit data, but this may change in the future. Differences, which perhaps are not obviously ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In SV_GfxBuffer structures there are two "case-dependent" entries (see structure definition of SV_GfxBuffer) : BITPLANE : svgfx_BytesPerLine = ( [width] +7 )>>3 svgfx_PixelBits = 0; ** IGNORE IT svgfx_ColorDepth = [number of planes] ONEPLANE : svgfx_BytesPerLine = 0; ** IGNORE IT svgfx_PixelBits = 8; ** or == 24 svgfx_ColorDepth = [used PixelBits] svgfx_ColorDepth always describes the _real_ ColorDepth of the graphics, which means the stored number of planes for BITPLANE data and the number of _actually_ used pixelbits for ONEPLANE data. If svgfx_PixelBits is 24, svgfx_ColorDepth will perhaps always be 24, too. But if svgfx_PixelBits is 8, it may be anything between 1 and 8. The reason is, that e.g. GIF pictures are always stored 8 Bit-wide, no matter if they contain 4, 8 or 256 Colors. This is just because these 8 Bit are simply a ColorRegister index (into the field of RGB-Colors : svgfx_Colors). OK, there's no problem in displaying a ONEPLANE-8 graphics on a 256 Color Screen, no matter which value svgfx_ColorDepth actually contains. But if svgfx_ColorDepth is, let's say, only 4, this will be just a waste of memory (and the last 256-16 = 240 colors will be black, anyway). So finally we can say, that the data in a ONEPLANE SV_GfxBuffer is just stored the same way, as e.g. in ChunkyPixel modes of VGA-like Graphic Cards or in the source-buffers for GfxLibs's WritePixelLine8(). (See "graphics.library"'s AutoDocs for more information on ChunkyPixel buffer (PixelLine8) handling under V37-40 with ECS/AGA or RTG). Which kind of data-storage is more likely ? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The way of data-storage only depend on the specific SVObject. Some Examples : FileType BufferType PixelBits ColorDepth GIF ONEPLANE 8 1..8 ILBM BITPLANE - 1..8 JPEG ONEPLANE 8/24 8/24 So any program, which supports GfxBuffers should handle both formats. This is not difficult, since superviewsupport.library contains functions to convert ONEPLANE buffers into BITPLANE buffers and vice versa. So you actually only have to support one of the data-storage alternatives. (See Example-SourceCodes for more and detailed information !) */ #endif /* SUPERVIEW_SVGFXBUFFER_H */