The UI elements on the ReplayTV 4000 are created from graphics files in
three formats: BMP, BMX and JPEG. BMP and JPEG files are standard (defacto
and dejure) formats; BMX appears to be Replay-specific, but is closely related
to the BMP format.
BMP
I think all the BMP files on the system use the same colormap, and are a
holdover from the 256-color graphics capability of the 2000 and 3000 series
models.
This writeup
on the BMP format is useful.
JPG
The JPG files appear to be perfectly standard JPG/JFIF files.
BMX
BMX files have a header, a colormap, and bitmap data encoded in a
restricted subset of the 8-bit RLE encoding used in BMP files.
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];
The bitmap byte stream consists of pairs of counts and
values, each one byte. If the count is non-zero, the
value is repeated count times.
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.
Usually, graphics files are actually read from two sets of resource
files, AppShell? and Apps; each set consists of .Bitmaps.dat
,
.Bitmaps.idx
, .Bitmaps.prm
and .ResInfo.txt
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,
Given this file, and the graphics files listed in the Bitmaps section, the
Replay builds the other files itself.
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:
Offset | Size | Name | Notes |
0 | 8 | start | offset into the .Bitamp.dat file of the start of this bitmap's data |
8 | 4 | length | length of the data stored in the .Bitmap.dat file |
12 | 4 | width | image width in pixels |
16 | 4 | height | image height in pixels |
20 | 2 | unk1 | data type code 0=uncompressed bmp, 1=8bit-rle bmp 8 = jpg, 16 = png (unimplemented) 32 = bmx |
22 | 1 | unk2 | vertical flip flag? every sample has '8' |
23 | 1 | unk3 | bitdepth 8 for bmp, 32 for jpg and bmx |
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:
Offset | Size | Name | Notes |
0 | 4 | magic | always '1' -- probably a version tag |
4 | 4 | first_resource_id | corresponds to FirstResourceID? value |
8 | 4 | index_buffer_size | corresponds to IndexBuferSize? value |
12 | 4 | bitmap_buffer_size | corresponds to BitmapBufferSize? |
16 | 4 | bitmap_buffer_threshhold | corresponds to BitmapBufferThreshold? |
20 | 4 | index_read_policy | a BufferedFileReadPolicyCode which corresponds to IndexReadPolicy? |
24 | 4 | bitmap_read_policy | a BufferedFileReadPolicyCode which corresponds to BitmapReadPolicy? |
- 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
Revision r1.10 - 01 Apr 2003 - 04:21 GMT - TWikiGuest Parents: WebHome
|
Copyright © 2001 by the contributing authors.
All material on this collaboration tool is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback.
|
|