Ikarion MVI

• Company: Ikarion Software GmbH
• Extension: mvi
• Game: Battle Race (both MVI versions are used in it)

There are two distinct MVI formats (even if they are used in the same game): MVI1 employs LZ77 compression on paletted images, MVI2 uses vector quantisation over YUV tiles.

MVI1

File starts with "VR6MVI" tag and 16-bit version (either 0x302 or 0x310) followed by blocks of audio and video data.

Version 0x302 blocks contain interleaved audio and video data, version 0x310 blocks start with pre-buffered audio data and have individual audio frames grouped so there may be several video frames between two audio frame groups.

Block header format:

 2 bytes - number of frames
 2 bytes - number of 400-byte buffers per audio frame
 1 byte (version 0x310 only) - number of audio frames in group
 1 byte (version 0x310 only) - number of audio frames to pre-buffer
 2 bytes - frame sizes size
 N bytes - packed frame sizes

Frame sizes are stored as variable-length integers in radix-7 form: each byte has top bit signalling whether the next byte is also a part of this integer and low 7 bits containing part of the integer (LSB first). E.g. 0x2A is coded as 0x2A while 0x100 is coded as 0x80 0x02.

Each frame starts with 8-bit flags:

• bit 0 - audio present
• bit 1 - special tile-based motion compensation scheme with RLE compression (not present in known samples)
• bit 2 - frame data is LZ77-compressed
• bit 3 - LZ77-compressed palette data is present

LZ77 compression opcodes:

• 0x00 -- leave next 16-bit amount of output unchanged
• 0x01..0x7F -- leave next 1..127 bytes of output unchanged
• 0x80..0x9F -- copy next 1..32 bytes
• 0xA0..0xBF -- repeat next value 2..33 times
• 0xC0..0xFF -- read 1-2 byte offset (in the same way as frame size above), copy 2..65 bytes using that offset (relative to the current position e.g. offset 1 means repeating last byte)

MVI2

File header:

 4 bytes - "MVI2"
 2 bytes - version (should be 0x101)
 2 bytes - number of frames
 2 bytes - delay in milliseconds between frames
 1 byte  - width in tiles
 1 byte  - height in tiles
 1 byte  - Y depth (should be 5)
 1 byte  - U depth (should be 5)
 1 byte  - V depth (should be 5)
 1 byte  - index entry bits (should be 12)
 1 byte  - tile width exponent (should be 2, for 4x4 tiles)
 1 byte  - tile height exponent (should be 2, for 4x4 tiles)
 4*N bytes - frame sizes

Frame starts with 8-bit flags, IMA ADPCM compressed audio data, tile data update (prefixed by 16-bit number of tiles to update) and tile indices.

Tile data is stored as 5-bit values packed LSB first into 10 bytes for 4x4 tile. Tiles are stored in the circular buffer of 4096 tiles, so e.g. if you have first updated 4000 tiles and then 100 tiles then the second update will overwrite 4 first tiles and next update will touch fifth tile and so on.

Frame is split into 64x64 macro tiles that consist of 16x16 Y tiles of size 4x4, 8x8 U tiles and 8x8 V tiles. All tiles are coded as 12-bit indices in the common tile buffer. So e.g. for 128x64 frame first you read 256 Y tile indices for the first macro tile, then 64 U and 64 V indices for the same, and then repeat it for the second macro tile.