Rollcage 2 IMG
Back to index | Edit this page
Contents
IMG + IDX
- Format type: Archive
- Endianness: Little-endian
Format Specifications
- // for each file
- uint32 {4} - File Offset
- uint32 {4} - Compressed File Length
- uint32 {4} - Decompressed File Length
- uint32 {4} - Unused
// IMG FILE
- // for each file
- char {4} - File Header (GT20)
- uint32 {4} - Decompressed File Length
- uint32 {4} - Unused (Same as the Unused field in the IDX File)
- uint32 {4} - Length of additional Information
- char {X} - Additional Information
- byte {X} - Compressed Data
Compressed Data:
- uint32 {4} - 'ControlBits'
- char {X} - Data Segment
- uint32 {4} - 'ControlBits'
- char {X} - Data Segment
- ..
- ControlBits occur in the Input Stream whenever the algorithm requires another Bit, not when the last Bit in the ControlBits has been read.
- Uncompressed Data is read verbatim from a Data Segment in the Input Stream, and placed in the Output Stream.
- The Data Compression method is to copy previously decompressed bytes in the Output Buffer, to the Output Stream.
- This is always in the form of a negative Offset + Copy Count.
- The ControlBits are parsed starting with the least significant bit.
- If the Bit is 0 then the next Byte is not compressed, and copied directly from the Input Stream
- If the Bit is 1 then the next Bytes are compressed.
- The next ControlBit shows how to derive the Offset and Copy Count.
- If the Next Bit is 0:
- Read the next Byte from the Input Stream.
- This Byte-256 is the Offset.
- From that position copy 2 bytes to the end of the already decompressed Data.
- If the next ControlBit is 1 copy 2 additional Bytes.
- If the next ControlBit is 1 copy 1 additional Byte.
- If the Next Bit is 1:
- Read the next two Bytes from the Input Stream.
- The first three bits is the Copy Count-2.
- The remaining 13 bits-8192 is the Offset.
- If the Copy Count is 0, read the next Byte from the Input Stream.
- The most significant bit of this Byte (&128) indicates whether another 8192 should be deducted from the Offset
- The rest (&127) is the Copy Count-2.
- If this is again 0, read the next 2 Bytes, for the exact Copy Count.
MultiEx BMS
Not written yet
Notes and Comments
- The *.IDX file contains the directory, the *.IMG file contains the data
Supported Programs
Contents
When extracted, the IMG file contains several file types which can be identified by their header.
- BMP - Standard Microsoft Bitmap format
- BTP + GFXM - Track Textures and Models.
- PINP - Car Textures and Models
BTP
- char {4} - File Header (BTP )
- uint32 {4} - ?
- uint32 {4} - ?
- uint32 {4} - ?
- uint32 {4} - ?
- uint32 {4} - Number of COBJECTS
- uint32 {4} - ?
- uint32 {4} - Skybox Data
- uint32 {4} - ?
- uint32 {4} - Texture Data
- uint32 {4} - COBJECTS (Collision Data?)
- uint32 {4} - ?
- uint32 {4} - ?
- uint16 {2} - Number of Textures
- uint16 {2} - Number of Palettes
- uint32 {4} - TPAGE - Texture Page Table
- uint32 {4} - Palette Data
Texture Page Table
Textures are stored as indexed 8-bit images. Each Texture can index against a different Palette. The Texture Page Table section defines the dimensions of the texture, and which colour palette to use for indexing. There is one 12byte entry for each texture.
- uint16 {2} - Width
- uint16 {2} - Height
- uint32 {4} - Palette
- uint32 {4} - Offset of Texture in Texture Data Section
Palette Data
Each colour is stored as four bytes: G/B/R/A. Each palette contains 256 entries.
COBJECTS
Every COBJECT has a size of 56 bytes.
GFXM
Contains repeating SEGM and MODL sections, which appear to be track segments and models, respectively. Format (mostly) unknown. Coordinates appear to be shared between SEGM and MODLs, and referenced by index.
- char {4} - File Header (GFXM)
- uint32 {4} - ?
- uint32 {4} - ?
- uint32 {4} - Number of coords
- uint32 {4} - Number of SEGM sections
- uint32 {4} - Table of SEGM locations
- uint32 {4} - Table of MODL locations. First MODL immediately follows this table, and infers table length.
At location 0x68
- uint32 {4} - 12 bytes for each coordinate = 4 bytes each for XYZ.
Note: MODLs appear to contain sub-MODLs, as more MODL definitions appear than are given in the MODL table.
PINP
Contains a 128x128 texture, and repeating MODL sections.
- char {4} - File Header (PINP)
- uint16 {2} - ?
- uint16 {2} - Palette Location
- uint16 {2} - Location of first MODL Section (MODL_START)
- uint16 {2} - Location of Shared MODL Data
- uint16 {2} - Number of shared (12 byte) elements
- uint16 {2} - Size of all MODL Sections, includiong shared data
- Offset:16 - Palette Data (B/G/R)
- Offset:784 - Texture Data. 1 Byte per pixel.
MODL
Multiple MODLs in the same file can share data. Each MODL has its own index into the Shared Data Section - a two-byte offset to retrieve 12 bytes of Shared Data. Index values are re-used and repeated, however the Shared Data 12 byte entries are unique - so most likely this is just a simple form of compression.
The "Unknown Data Sections" are regular - they match header values, but the purpose is unclear.
- char {4} - File Header (MODL)
- uint16 {2} - Number of Vertices (VERT_NUM)
- uint16 {2} - Number of Faces (FACE_NUM)
- uint32 {4} - ?
- uint32 {4} - Offset (From current MODL) to Face Data
- uint32 {4} - Offset (From current MODL) to Unknown Data Section 1
- uint32 {4} - Offset into Face Data Index (From MODL_START)
- uint32 {4} - Offset (From current MODL) to Unknown Data Section 2
- uint16 {2} - Offset to Sub model 1?
- uint16 {2} - Offset to Sub model 2?
- char (36) - ?
- uint32 (4) - Offset (From current MODL) to Unknown Data Section 3
Face Data
- 8 bytes per Element. First four bytes seem to be Vertices as they never go above VERT_NUM.
Face Data Index
- 2 bytes index per Element of Face Data. Each index is an offset (From MODL_START) into the Shared Face Data.
Sbared Face Data
- 12 bytes per Element. This makes 20 bytes (combined) to describe each face.
- uint16 (2) - XY Texture Coord1
- uint16 (2) - ?
- uint16 (2) - XY Texture Coord2
- uint16 (2) - ?
- uint16 (2) - XY Texture Coord3
- uint16 (2) - XY Texture Coord4
Since the Textures are 128x128, it's possible that the MSB is used as a flag, since translated values ignoring the high bit still map to the Textures.
Unknown Data Section 1
- Generally small. No length indication in header found, probably delimited then by the start of Unknown Data Section 2.
Unknown Data Section 2
- Contains strange data. Some values repeat, offset by one byte. Most values repeat in reverse four-bit patterns: e.g. 89 ab cd ef fe dc ba 98
Unknown Data Section 3
- Every fourth byte is the - four-bit swapped reverse of its partner in Unknown Data Section 2.