In this "issue":
We got a cracking piece of Email this month, which read "IS FANTA_C VAPORWARE?". Well, the answer is no, it's just a big project. Indeed work is about to start on the preprocessor #3 (which, incidentally, I'm really looking forward to). We really have no idea when it will be a sell able product, but it will make it to market (even if it does kill Rob!).
Eclipse has had some support programs written for it, including a map designer (for the scrolling bits) and a control compiler for the control mechanisms and is coming on smoothly. We've investigated the PowerPC Floating Point architecture quite extensively, and as I write, Rob is just putting the finishing touches to an article about the F.P.U. for Random Rob.
At the very last minute, we've decided to release Eddie V1.4 build 2, as it makes Eddie a lot more stable. This update will be replaced by the official V4.11 release when ready.
Development
Consider the scene. You need to get graphics in for your game,
but you need to be able to print these graphics in memory without
loads of GWorld code and overhead. How? Well, the first obvious
thought is as PICTs - great until you find that they can be compressed
"n" different ways and you'd have to write a whole state
engine to decode them. What about raw data? Excellent thought,
so long as you don't mind completely huge apps, and finding an
App. that will output as straight raw data isn't easy.
Ok, so now you realise you have to search the world looking for a suitable format that is compressed (but you can decompress without too much thought and in a realistic time scale), your Mac can handle and is not patented (too heavily at least!).
Immediately you think of GIF, then you find that it is copyright and you must display a notice to that effect. Fairly naff. Jpeg? Lossy and complex. TIFF - huge files.
Something that tells you the image size, the palette and has simple Run Length Encoding compression would be great - but what?
Turns out that the Windows(tm) and OS2(tm) format "BMP" does just this, and there are good shareware programs on the Mac (Graphic Convertor for example) that can take a PICT and convert it to a BMP. Ideal? Almost. BMP defines that the origin is the bottom left of the screen, whereas we would really like it to be top left, but hey, who cares? Either flip it in your art package, or get your routine to flip it whilst decompressing.
Here then is the details about BMP format files that I've verified and works (I'm not sure who wrote this, or if it is copyright, as there is no information on the copy I have - hence I'll paste in the whole lot):
BITMAPFILEHEADER [3.0]
Bitmap File Information
The BITMAPFILEHEADER data structure contains information about the type,
size, and layout of a device-independent bitmap (DIB) file.
typedef struct tagBITMAPFILEHEADER {
WORD bfType; 0
DWORD bfSize; 2
WORD bfReserved1; 6
WORD bfReserved2; 8
DWORD bfOffBits; 10
} BITMAPFILEHEADER;
The BITMAPFILEHEADER data structure contains the following fields:
Field Description
bfType Specifies the type of file. It must be BM.
bfSize Specifies the size in DWORDs of the file.
bfReserved1 Is reserved and must be set to zero.
bfReserved2 Is reserved and must be set to zero.
bfOffBits Specifies in bytes the offset from the BITMAPFILEHEADER
of the actual bitmap in the file.
Comments A BITMAPINFO or BITMAPCOREINFO data structure immediately
follows the BITMAPFILEHEADER structure in the DIB file.
BITMAPINFO [3.0]
Device-Indpendent Bitmap Information
The BITMAPINFO structure fully defines the dimensions and color
information for a Windows 3.0 device-independent bitmap.
typedef struct tagBITMAPINFO {
BITMAPINFOHEADER bmiHeader;
RGBQUAD bmiColors[1];
} BITMAPINFO;
The BITMAPINFO structure contains the following fields:
Field Description
bmiHeader Specifies a BITMAPINFOHEADER data structure that
contains information about the dimensions and color
format of a device-independent bitmap.
bmiColors Specifies an array of RGBQUAD data structures that
define the colors in the bitmap.
Comments: A Windows 3.0 device-independent bitmap consists of two
distinct parts: a BITMAPINFO data structure that describes the dimensions
and colors of the bitmap, and an array of bytes that define the pixels of
the bitmap. The bits in the array are packed together, but each scan line
must be zero-padded to end on a LONG boundary. Segment boundaries can
appear anywhere in the bitmap, however. The origin of the bitmap is the
lower-left corner.
The biBitCount field of the BITMAPINFOHEADER structure determines the
number of bits which define each pixel and the maximum number of colors
in the bitmap. This field may be set to any of the following values:
Value Meaning
1 The bitmap is monochrome, and the bmiColors field must
contain two entries. Each bit in the bitmap array represents a
pixel. If the bit is clear, the pixel is displayed with the
color of the first entry in the bmiColors table; if the bit is
set, the pixel has the color of the second entry in the table.
4 The bitmap has a maximum of 16 colors, and the bmiColors
field contains up to 16 entries. Each pixel in the bitmap is
represented by a four-bit index into the color table.
For example, if the first byte in the bitmap is 0x1F, then the
byte represents two pixels. The first pixel contains the color
in the second table entry, and the second pixel contains the
color in the 16th table entry.
8 The bitmap has a maximum of 256 colors, and the bmiColors
field contains up to 256 entries. In this case, each byte in the
array represents a single pixel.
24 The bitmap has a maximum of 2^24 colors. The bmiColors
field is NULL, and each three bytes in the bitmap array
represents the relative intensities of red, green, and blue,
respectively, of a pixel.
The biClrUsed field of the BITMAPINFOHEADER structure specifies the number
of color indexes in the color table actually used by the bitmap. If the
biClrUsed field is set to 0, the bitmap uses the maximum number of colors
corresponding to the value of the biBitCount field.
The colors in the bmiColors table should appear in order of importance.
Alternatively, for functions that use device-independent bitmaps, the
bmiColors field can be an array of 16-bit unsigned integers that specify
an index into the currently realized logical palette instead of explicit
RGB values. In this case, an application using the bitmap must call
device-independent bitmap functions with the wUsage parameter set to
DIB_PAL_COLORS.
Note: The bmiColors field should not contain palette indices if the
bitmap is to be stored in a file or transferred to another application.
Unless the application uses the bitmap exclusively and under its complete
control, the bitmap color table should contain explicit RGB values.
BITMAPINFOHEADER [3.0]
Device-Independent Bitmap Format Information
The BITMAPINFOHEADER structure contains information about the dimensions
and color format of a Windows 3.0 device-independent bitmap.
typedef struct tagBITMAPINFOHEADER{
DWORD biSize; 14
DWORD biWidth; 18
DWORD biHeight; 22
WORD biPlanes; 26
WORD biBitCount 28
DWORD biCompression; 30
DWORD biSizeImage; 34
DWORD biXPelsPerMeter;
DWORD biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrImportant;
} BITMAPINFOHEADER;
The BITMAPINFOHEADER structure has the following fields:
Field Description
biSize Specifies the number of bytes required by the
BITMAPINFOHEADER structure.
biWidth Specifies the width of the bitmap in pixels.
biHeight Specifies the height of the bitmap in pixels.
biPlanes Specifies the number of planes for the target device and
must be set to 1.
biBitCount Specifies the number of bits per pixel. This value must
be 1, 4, 8, or 24.
biCompression Specifies the type of compression for a compressed
bitmap. It can be one of the following values:.
Value Meaning
BI_RGB Specifies that the bitmap is not
compressed.
BI_RLE8 Specifies a run-length encoded format
for bitmaps with 8 bits per pixel. The
compression format is a two-byte
format consisting of a count byte
followed by a byte containing a color
index. See the following 'Comments'
section for more information.
BI_RLE4 Specifies a run-length encoded format
for bitmaps with 4 bits per pixel. The
compression format is a two-byte
format consisting of a count byte
followed by two word-length color
indexes. See the following 'Comments'
section for more information.
biSizeImage Specifies the size in bytes of the image.
biXPelsPerMeter
Specifies the horizontal resolution in pixels per meter
of the target device for the bitmap. An application can
use this value to select a bitmap from a resource group
that best matches the characteristics of the current
device. biYPelsPerMeter Specifies the vertical
resolution in pixels per meter of the target device for
the bitmap.
biClrUsed
Specifies the number of color indexes in the color table
actually used by the bitmap. If this value is 0, the
bitmap uses the maximum number of colors corresponding
to the value of the biBitCount field. See the
description of the BITMAPINFO data structure earlier in
this chapter for more information on the maximum sizes
of the color table. If biClrUsed is nonzero, then the
biClrUsed field specifies the actual number of colors
which the graphics engine or device driver will access
if the biBitCount field is less than 24. If the
biBitCount field is set to 24, the biClrUsed field
specifies the size of the reference color table used to
optimize performance of Windows color palettes.
If the bitmap is a 'packed' bitmap (that is, a bitmap in
which the bitmap array immediately follows the
BITMAPINFO header and which is referenced by a single
pointer), the biClrUsed field must be set to 0 or to the
actual size of the color table.
biClrImportant
Specifies the number of color indexes that are considered
important for displaying the bitmap. If this value is 0,
then all colors are important.
Comments: The BITMAPINFO data structure combines the
BITMAPINFOHEADER structure and a color table to provide a complete
definition of the dimensions and colors of a Windows 3.0
device-independent bitmap. See the description of the BITMAPINFO data
structure for more information about specifying a Windows 3.0
device-independent bitmap.
An application should use the information stored in the biSize field to
locate the color table in a BITMAPINFO data structure with a method such
as the following:
pColor = ((LPSTR) pBitmapInfo + (WORD) (pBitmapInfo -> biSize))
Bitmap Compression Formats Windows supports formats for compressing
bitmaps that define their colors with 8 bits per pixel and with 4 bits
per pixel. Compression reduces the disk and memory storage required for
the bitmap. The following paragraphs describe these formats.
When the biCompression field is set to BI_RLE8, the bitmap is compressed
using a run-length encoding format for an 8-bit bitmap. This format may
be compressed in either of two modes:
7 Encoded
7 Absolute
Both modes can occur anywhere throughout a single bitmap.
Encoded mode consists of two bytes: the first byte specifies the number
of consecutive pixels to be drawn using the color index contained in the
second byte. In addition, the first byte of the pair can be set to zero
to indicate an escape that denotes an end of line, end of bitmap, or a
delta. The interpretation of the escape depends on the value of the
second byte of the pair. The following list shows the meaning of the
second byte:
Second Byte
Of Escape
Meaning
0 End of line.
1 End of bitmap.
2 Delta. The two bytes following the escape contain
unsigned values indicating the horizontal and vertical
offset of the next pixel from the current position.
Absolute mode is signalled by the first byte set to zero and the second
byte set to a value between 03H and FFH. In absolute mode, the second
byte represents the number of bytes which follow, each of which contains
the color index of a single pixel. When the second byte is set to 2 or
less, the escape has the same meaning as in encoded mode.
In absolute mode, each run must be aligned on a word boundary.
The following example shows the hexadecimal values of an 8-bit compressed
bitmap:
03 04 05 06 00 03 45 56 67 00 02 78 00 02 05 01
02 78 00 00 09 1E 00 01
This bitmap would expand as follows (two-digit values represent a color
index for a single pixel):
04 04 04
06 06 06 06 06
45 56 67
78 78
move current position 5 right and 1 down
78 78
end of line
1E 1E 1E 1E 1E 1E 1E 1E 1E
end of RLE bitmap
When the biCompression field is set to BI_RLE4, the bitmap is compressed
using a run-length encoding format for a 4-bit bitmap, which also uses
encoded and absolute modes. In encoded mode, the first byte of the pair
contains the number of pixels to be drawn using the color indexes in the
second byte. The second byte contains two color indexes, one in its
high-order nibble (that is, its low-order four bits) and one in its
low-order nibble. The first of the pixels is drawn using the color
specified by the high-order nibble, the second is drawn using the color
in the low-order nibble, the third is drawn with the color in the
high-order nibble, and so on, until all the pixels specified by the
first byte have been drawn.
In absolute mode, the first byte contains zero, the second byte contains
the number of color indexes that follow, and subsequent bytes contain
color indexes in their high- and low-order nibbles, one color index for
each pixel. In absolute mode, each run must be aligned on a word boundary.
The end-of-line, end-of-bitmap, and delta escapes also apply to BI_RLE4.
The following example shows the hexadecimal values of a 4-bit compressed
bitmap:
03 04 05 06 00 06 45 56 67 00 04 78 00 02 05 01
04 78 00 00 09 1E 00 01
This bitmap would expand as follows (single-digit values represent a
color index for a single pixel):
0 4 0
0 6 0 6 0
4 5 5 6 6 7
7 8 7 8
move current position 5 right and 1 down
7 8 7 8
end of line
1 E 1 E 1 E 1 E 1
end of RLE bitmap
RGBQUAD [3.0]
RGB Color Structure
The RGBQUAD data structure describes a color consisting of relative
intensities of red, green, and blue. The bmiColors field of the
BITMAPINFO data structure consists of an array of RGBQUAD data structures.
typedef struct tagRGBQUAD {
BYTE rgbBlue;
BYTE rgbGreen;
BYTE rgbRed;
BYTE rgbReserved;
} RGBQUAD;
The RGBQUAD structure contains the following fields:
Field Description
rgbBlue Specifies the intensity of blue in the color.
rgbGreen Specifies the intensity of green in the color.
rgbRed Specifies the intensity of red in the color.
rgbReserved Is not used and must be set to zero.
#define BI_RGB 0L
#define BI_RLE8 1L
#define BI_RLE4 2L
BITMAPCOREINFO [3.0]
Device-Indpendent Bitmap Information
The BITMAPCOREINFO structure fully defines the dimensions and color
information for a device-independent bitmap that is compatible with
Microsoft OS/2 Presentation Manager versions 1.1 and 1.2 bitmaps.
typedef struct _BITMAPCOREINFO {
BITMAPCOREHEADER bmciHeader;
RGBTRIPLE bmciColors[];
} BITMAPCOREINFO;
The BITMAPCOREINFO structure contains the following fields:
Field Description
bmciHeader Specifies a BITMAPCOREHEADER data structure that
contains information about the dimensions and color
format of a device-independent bitmap.
bmciColors Specifies an array of RGBTRIPLE data structures that
define the colors in the bitmap.
Comments An OS/2 Presentation Manager device-independent bitmap
consists of two distinct parts: a BITMAPCOREINFO data structure that
describes the dimensions and colors of the bitmap, and an array of bytes
which define the pixels of the bitmap. The bits in the array are packed
together, but each scan line must be zero-padded to end on a LONG
boundary. Segment boundaries can appear anywhere in the bitmap, however.
The origin of the bitmap is the lower-left corner.
The bcBitCount field of the BITMAPCOREHEADER structure determines the
number of bits which define each pixel and the maximum number of colors
in the bitmap. This field may be set to any of the following values:
Value Meaning
1 The bitmap is monochrome, and the bmciColors field must
contain two entries. Each bit in the bitmap array represents a
pixel. If the bit is clear, the pixel is displayed with the
color of the first entry in the bmciColors table; if the bit is
set, the pixel has the color of the second entry in the table.
4 The bitmap has a maximum of 16 colors, and the bmciColors
field contains 16 entries. Each pixel in the bitmap is represented
by a four-bit index into the color table.
For example, if the first byte in the bitmap is 0x1F, then the
byte represents two pixels. The first pixel contains the color in
the second table entry, and the second pixel contains the color
in the 16th table entry.
8 The bitmap has a maximum of 256 colors, and the bmciColors
field contains 256 entries. In this case, each byte in the array
represents a single pixel.
24 The bitmap has a maximum of 2^24 colors. The bmciColors
field is NULL, and each three bytes in the bitmap array
represents the relative intensities of red, green, and blue,
respectively, of a pixel.
The colors in the bmciColors table should appear in order of importance.
Alternatively, for functions that use device-independent bitmaps, the
bmciColors field can be an array of 16-bit unsigned integers that
specify an index into the currently realized logical palette instead of
explicit RGB values. In this case, an application using the bitmap must
call device-independent bitmap functions with the wUsage parameter
set to DIB_PAL_COLORS.
Note The bmciColors field should not contain palette indexes if the
bitmap is to be stored in a file or transferred to another application.
Unless the application uses the bitmap exclusively and under its
complete control, the bitmap color table should contain explicit
RGB values.
BITMAPCOREHEADER [3.0]
Device-Independent Bitmap Format Information
The BITMAPCOREHEADER structure contains information about the dimensions
and color format of a device-independent bitmap that is compatible with
Microsoft OS/2 Presentation Manager versions 1.1 and 1.2 bitmaps.
typedef struct tagBITMAPCOREHEADER {
DWORD bcSize;
WORD bcWidth;
WORD bcHeight;
WORD bcPlanes;
WORD bcBitCount;
} BITMAPCOREHEADER;
The BITMAPCOREHEADER structure has the following fields:
Field Description
bcSize Specifies the number of bytes required by the BITMAPCOREHEADER
structure.
bcWidth Specifies the width of the bitmap in pixels.
bcHeight Specifies the height of the bitmap in pixels.
bcPlanes Specifies the number of planes for the target device and
must be set to 1.
bcBitCount Specifies the number of bits per pixel. This value must
be 1, 4, 8, or 24.
Comments The BITMAPCOREINFO data structure combines the
BITMAPCOREHEADER structure and a color table to provide a complete
definition of the dimensions and colors of a device-independent bitmap.
See the description of the BITMAPCOREINFO data structure for more
information about specifying a device-independent bitmap.
An application should use the information stored in the bcSize field to
locate the color table in a BITMAPCOREINFO data structure with a method
such as the following:
pColor = ((LPSTR) pBitmapCoreInfo + (WORD) (pBitmapCoreInfo -> bcSize))
RGBTRIPLE [3.0]
RGB Color Structure
The RGBTRIPLE data structure describes a color consisting of relative
intensities of red, green, and blue. The bmciColors field of the
BITMAPCOREINFO data structure consists of an array of RGBTRIPLE data
structures.
typedef struct tagRGBTRIPLE {
BYTE rgbtBlue;
BYTE rgbtGreen;
BYTE rgbtRed;
} RGBTRIPLE;
The RGBTRIPLE structure contains the following fields:
Field Description
rgbtBlue Specifies the intensity of blue in the color.
rgbtGreen Specifies the intensity of green in the color.
rgbtRed Specifies the intensity of red in the color.
How to distinguish between BITMAPINFO and BITMAPCOREINFO when reading
in a BMP file.
After reading the BITMAPFILEHEADER read the next DWORD from the file.
If it is 12 you are reading a BITMAPCOREHEADER, if it is 40 you are
reading a BITMAPINFOHEADER.
********************************************************************
Note that an WORD is 16 bit and a DWORD is 32 bit. The bytes are reversed because this a Windows (spit) format that follows Intel byte numbering - i.e. reversed compared to Motorola 68k and standard Mac PPC.
If the above looks complicated, don't worry - it isn't. If you ignore the palette, it's even simpler. Below I've pasted some PPC code that will take a bitmap and decompress it into memory (ignoring the palette). It assumes the off screen screen is 1024 pixels wide and in 256 colour mode - i.e. 1byte=1 pixel. It's fairly complete and takes a BMP resource ID, and x and y coordinates (for the screen in memory). It does not handle:
a) the decompressed form
b) the BMP delta command and
c) expects the BMP to encoded in RLE8 form
****************************************************************** **print_pic **takes a res ID in r3, x coord in r4, y coord in r5 **expands the picture into offscreen screen at r4,r5 **destroys all regs. **(C) Lightsoft 1996. print_pic: sub_in mr r20,r3 mr r21,r4 mr r22,r5 *Save off params - what stack? **set resload true li r3,1 Xcall SetResLoad **first get resource lis r3," B" ori r3,r3,"MP" mr r4,r20 *ID Xcall GetResource cmpwi r3,0 beq pp_fail stw r3,picture_source_handle(`bss) lwz r3,(r3) cmpwi r3,0 beq pp_fail *call me paranoid.. stw r3,picture_source_memory(`bss) **r3 pointrrs to BMP data **get offset to data lbz r4,11(r3) slwi r4,r4,8 *Intel format lbz r5,10(r3) or r4,r4,r5 *now proper format :-) - offset to picture data add r6,r4,r3 *r6->data mr r20,r3 *save master pointer to data addi r3,r3,18 *get width bl get_intel_4 *reverse bytes stw r4,pic_width(`bss) addi r3,r20,22 bl get_intel_4 stw r4,pic_h(`bss) *given up mis-spelling height addi r3,r20,30 bl get_intel_4 *compressed? cmpwi r4,1 bne uncompressed_pic **Decompressor **this is compressed data expansion...(I think) mr r11,r6 *data pointer mr r3,r21 *x mr r4,r22 *y lwz r6,my_screen_buffer(`bss) slwi r4,r4,10 *y times 1024 add r7,r4,r6 *plus base address add r7,r7,r3 *plus x mr r8,r7 *copy for add 1024 - point to next line. lwz r13,pic_h(`bss) expand_line: lbz r9,(r11) *get control cmpwi r9,0 beq escape *eol,eof or abs mode switch mtctr r9 lbz r9,1(r11) *colour splat_run: stb r9,(r7) addi r7,r7,1 bdnz splat_run addi r11,r11,2 b expand_line escape: **second byte can be 0=eol, 1=eof, 2=Delta (error),3-ff=Absolute mode (uncompressed) lbz r9,1(r11) addi r11,r11,2 cmpwi r9,0 beq eol cmpwi r9,1 beq eof cmpwi r9,3 bge abs_mode *n uncompressed bytes follow lwz r3,bmp_err_text(rtoc) Xcall DebugStr bmp_err_text: pstring "BMP Error - Delta found!" **Absolute mode - BMP switches to this when the data gets complex, to save space. abs_mode: mtctr r9 *number of bytes following amode_print: lbz r9,(r11) stb r9,(r7) addi r11,r11,1 addi r7,r7,1 bdnz amode_print *straight copy andi. r12,r11,1 *check for misaligned beq not_mis addi r11,r11,1 not_mis: b expand_line *carry on with encoded mode eol: subic. r13,r13,1 mr r7,r8 addi r7,r7,1024 *next line mr r8,r7 bne expand_line *double check just in case eof doesn't exist eof: **Do nothing here.. b pic_done **Doesn't handle uncompressed pictures uncompressed_pic: pic_done: **Finally, get the memory back lwz r3,picture_source_handle(`bss) Xcall ReleaseResource li r3,0 sub_out pp_fail: li r3,-1 sub_out ******************* **Byte reversal routines **returns r4 with dword at r3 **destroys r3,4,5 get_intel_4: addi r3,r3,4 *for Intel backwards byte placement lbzu r4,-1(r3) slwi r4,r4,8 lbzu r5,-1(r3) or r4,r4,r5 slwi r4,r4,8 lbzu r5,-1(r3) or r4,r4,r5 slwi r4,r4,8 lbzu r5,-1(r3) or r4,r4,r5 blr **returns r4 with word at r3 **destroys r3,4,5 get_intel_2: addi r3,r3,2 *for Intel backwards byte placement lbzu r4,-1(r3) slwi r4,r4,8 lbzu r5,-1(r3) or r4,r4,r5 blr
Note, that in the byte reversal routines, I could have switched the processor modes, but it involves a lot of overhead and simply was not worth it, as each endian mode switch takes 7 instructions.
Well, I was right - I correctly predicted that a picture war was about to start :-)
And have you noticed? I'm not saying Rob is vain, but he even linked to the picture in StuChat10 just in case you missed it!
We're maxxed out, so I'd better go get on with it. Till next time...
Code on!
Stu.