Rollcage 2 IMG

From XentaxWiki
Jump to: navigation, search

Back to index | Edit this page


Format Specifications

// for each file
uint32 {4}   - File Offset
uint32 {4}   - Compressed File Length
uint32 {4}   - Decompressed File Length
uint32 {4}   - Unused


// 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


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


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.


Every COBJECT has a size of 56 bytes.


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

Cordinate Table
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.


Contains a 128x128 texture, and repeating MODL sections.

// PINP File
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.


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.

// MODL Section Header
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.
Textures + ?
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.


Jump to a listing by...
All Formats - Common Formats - Standard Formats - Malformed Pages
Xbox 360
PlayStation 2
PlayStation 3
PlayStation Portable
Animation - Archive - Audio - Image - Mesh - Miscellaneous - Model - Video
Little-endian - Big-endian
BMS Scripts
Pages Without a BMS Script

All Pages with Scripts:
Recently Added Scripts

Program Support
No Known Support

MultiEx Commander - Game Extractor

Format Specification Completion
Work in Progress - Almost Done - Completed
Compression and Encryption
No Compression or Encryption Used - Unknown Compression or Encryption Used

One or Both Used:
Compression Used - Both Compression and Encryption Used