Rollcage 2 IMG

Back to index | Edit this page

IMG + IDX

• Format type: Archive
• Endianness: Little-endian

Format Specifications

// IDX FILE

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

• Game Extractor

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

// BTP FILE

char {4}     - File Header (BTP )

uint32 {4}   - ?

uint32 {4}   - ?

uint32 {4}   - ?

uint32 {4}   - ?

uint32 {4}   - ?

uint32 {4}   - ?

uint32 {4}   - Skybox Data

uint32 {4}   - ?

uint32 {4}   - Texture Data

uint32 {4}   - COBJECTS (Collision Data?)

uint32 {4}   - ?

uint32 {4}   - ?

uint16 {4}   - Number of Textures

uint16 {4}   - Number of Palettes

uint32 {4}   - TPAGE - Texture Page Data

uint32 {4}   - Palette Data

Texture Page Data

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 texture page entry for each texture in this table.

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.

GFXM

Contains repeating SEGM and MODL sections. Format unknown.

PINP

Contains a 128x128 texture, and repeating MODL sections.

Offset:16  - Palette Data (B/G/R)

Offset:784 - Texture Data. 1 Byte per pixel.