Death Rally BPK Format
The BPK format is a format used by Death Rally which usually contains graphics.
It contains encrypted LZW-compressed data.
Before the image is compressed, every byte is rotated left by 3 bits.
So after the image is decompressed, every byte needs to be rotated right by 3 bits.
The BPK format uses LZW Compression of each byte in the image, using the values 0x100 to mark EOF and 0x101 to reset the LZW tables. The initial bit width is 9 bits. The dictionary size is capped at 4096 entries, so the bit width is capped at 12 bits. Once the dictionary is full, it accepts no more entries until the dictionary is reset and the width then gets returned to 9 bits.
Some files (e.g. TIRE?.BPK in MENU.BPA) contain data after the EOF mark. Figure out what's going on here.
The data is packed in little-endian and always starts with an LZW table reset (0x101). There is no bit swapping.
So, at the start of the file, you'll have bytes in this form:
aaaaaaaa bbbbbbbA ccccccBB dddddCCC eeeeDDDD fffEEEEE ggFFFFFF hGGGGGGG HHHHHHHH
While the bit width is 9 bits, these are to be interpreted as:
Aaaaaaaaa BBbbbbbbb CCCcccccc DDDDddddd EEEEEeeee FFFFFFfff GGGGGGGgg HHHHHHHHh
The formats identified here are:
- Raw VGA Image - image dimensions are unknown.
- RIX3 image - comes with a header featuring dimensions and a palette. Pixels are stored left-to-right then top-to-bottom, one byte per pixel as per VGA.
- Some other formats of currently unknown purpose. For TR?-SHA there's a lot of INT32LE values. And for TR?-SCE there's a lot of INT32LE values offset by 1 byte or something.
RIX3 images have the following header:
|char||The string "RIX3"|
|UINT16LE||Unknown purpose, appears to always be 0x00AF|
Should this be shifted out to a separate page, or should we wait until the subformats have been better fleshed-out?
This file format was reverse engineered by GreaseMonkey. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)