Replay	GraphicsFiles
	Home | Changes | Index | Search | Go

Graphic File Formats and Scheme Info

Introduction

BMP

This writeup on the BMP format is useful.

JPG

BMX

Unlike other file formats on the Replay, all the multi-byte fields in BMX files are stored in little-endian format.

BMX header

struct bmx_header {
    u32 magic;       /* 'BMX ' */
    u16 version;     /* guess -- always 1 */
    u16 width;       /* image width in pixels */
    u16 height;      /* image height in pixels */
    u16 colors;      /* guess -- always 0x100 */
    u32 datasize;    /* the size of the compressed bitmap data, in bytes */
};

BMX Color Map

struct colors {
    u8 unused;       /* always 0xff  - may be alpha channel for future use */
    u8 blue;
    u8 green;
    u8 red;
} colors[256];

Bitmap Stream

If count is zero, then value is an escape code. If it's 0, then the row is complete; this is used at the end of every row, and only after every pixel in that row has been filled in. If it's 1, then the bitmap is complete; this is always used at the end of the bitmap, and only after the final row is finished. The value 2, used for arbitary horizontal/vertical deltas in BMP files, isn't used in BMX files. Values of 3 or above mean that that many bytes following are literal values; if it's odd, then there's a junk byte to throw away immediately following.

This encoding is a restricted form of the BMP 8-bit RLE encoding; end-of-row markers occur only at the end of rows; end-of-bitmap markers occur only after the last row; delta encodings aren't used.

The rows are filled in left to right, bottom to top.

The pixel values are indices into the color table, which gives actual red/green/blue values.

Resource Files

The ResInfo?.txt file is a text file in a Windows .ini-style format:

[Resource]
FirstResourceID = 1
IndexBufferSize = 4096
BitmapBufferSize = 81920
BitmapBufferThreshhold = 81920
IndexReadPolicy = ReadAhead
BitmapReadPolicy = ReadAhead

[Bitmaps]

"PopupMenu/menuTitle.bmx"                           // IDB_POPUPMENU_TITLE,
"PopupMenu/menuTitleCap.bmx"                        // IDB_POPUPMENU_TITLE_CAP,
"PopupMenu/menuDescriptionArea.bmx"                 // IDB_POPUPMENU_DESCRIPTION,
"PopupMenu/menuItemNormal.bmx"                      // IDB_POPUPMENU_ITEM_NORMAL,

The .Bitmap.dat file contains the actual graphics contents, essentially the files concatenated together. Padding is added between files as necessary so each one starts on a 4-byte boundary. BMP files are stored without their header and colormap (as mentioned above, all the BMP files on the system share a palette, apparently partially hardcoded and partially loaded from the Palette/_2_(normal).pal BMP file); JPEG and BMX files are stored intact.

The .Bitmap.idx file is a FiledArray file of 24-byte AppResource?::BitmapDesc records.

AppResource?::BitmapDesc:

The last word is troublesome; sometimes it's treated as a high u16 and a low u8 (and the u8 in the middle ignored); sometimes it's treated as a word, with bitmasking. bitmasks 0xffc0f700 and 0x003f08ff are treated as disjoint sets; everything in the index matches the second mask (assuming type is only 6 bits).

The .prm files are paramters from the [Resource] block of the ResInfo?.txt file. They consist of a single 28-byte record:

Code

• dump-bmx.c parses BMX files, prints out a summary line, and writes a Portable Pixmap (.ppm) file of its contents -- this uses handwritten code to write the PPM; the netpbm library itself can't read the resulting ppm files, but I don't know why. As far as I can tell, they match the spec.
• dump-bitmap-idx.c parses an idx file and displays its content in a text format.
• split-bitmap.c uses an idx file to split a Bitmap.dat file into its component parts, including adding the stripped BMP headers.
• bmx2ppm.c reads a BMX file on standard input and writes a PPM file on standard output. This duplicates most of the functionality of dump-bmx, but it uses the netpbm library and the resulting files are usable with the rest of the pbm utils, including:
• ppm2bmx.c reads a PPM file on standard input and writes a BMX file on standard output. This also uses the netpbm library. It doesn't compress quite as well as whatever Replay uses, but it gets pretty close; think their utility is probably smarter about coalescing small repeat blocks into surrounding literal blocks to avoid some overhead.

-- ToddLarason - 09 Mar 2002

Attachment:	Action:	Size:	Date:	Who:	Comment:
dump-bmx.c	action	3962	10 Mar 2002 - 23:13	ToddLarason	dump-bmx.c
dump-bitmap-idx.c	action	1665	24 Mar 2002 - 21:05	ToddLarason	dump-bitmap-idx.c
split-bitmap.c	action	8944	24 Mar 2002 - 21:12	ToddLarason	split-bitmap.c
bmx2ppm.c	action	3517	10 Mar 2002 - 00:21	ToddLarason
ppm2bmx.c	action	4786	10 Mar 2002 - 01:09	ToddLarason