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

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.