- Extension: c93
- Company: Interplay Entertainment
- Samples: http://samples.mplayerhq.hu/game-formats/cyberia-c93/
C93 is a video format used in the DOS version of the game Cyberia. It seems that is has not been used anywhere else (Cyberia 2 comes with a slightly modified version named M95). The 'c93' extension most likely refers to the format creation year.
C93 operates in standard VGA 320x200x256 resolution and is based on BTC encoding and simple block copying. Video is, however, encoded in 320x192 resolution, leaving 8 bottom rows blank/black.
All multi-byte numbers are encoded in little endian format. Files begin with a 512-entry block record table. Each block record is formatted as:
2 bytes sector - index of the frames block 1 byte length - length of the block data (in sectors) 1 byte frames - number of frames in the block
A zero length field indicates the end of the table. A sector is a 2048-byte chunk of data. Thus, a block with sector index 1 starts at offset 2048, 2 at 4096, etc.
Each block contains a variable number of actual frames (usually 11) and starts with its own index table, holding (32-bit) offsets of the particular frame, relative to the block base.
2 bytes video_size - size of the following video data 1 byte video[video_size] - compressed frame 2 bytes palette_size - size of the following palette 1 byte palette[palette_size] - 256 BGR triplets of the palette if palette_size is non-zero 2 bytes sound_size - size of the following sound chunk 1 byte sound[sound_size] - sound data, stored as a complete VOC file
Video is encoded as pairs of adjacent 8x8 blocks. Each pair starts with a byte describing the block's (de)compression mode. The lower nibble is used for the first (left) block, the higher for the second (right) block. Compression modes, in hex:
Read two bytes of the offset. Copy 8x8 block at that offset (in bytes) from the previous frame.
Same as method 2, but split 8x8 block into four 4x4 blocks and copy each one independently, left to right, top to bottom.
Similar to method 6, but copy blocks from the current frame. Note, that due to doublebuffering this can reuse of blocks painted two frames ago as well as already processed blocks of the current frame.
Here comes BTC encoding. Read one byte for color0 and next one for color1. Now, for each row of pixels, read mask byte and paint pixels either with color1 if its bit (starting from the least significant bit) is set or color0 if it's not set.
Exactly as 8, but for four 4x4 blocks, each with its own pair of color0/color1 and mask.
This one is similar to A, with a small enhancement. For each 4x4 block read 4 color bytes. Paint pixels using the following color combinations:
01 01 02 02 01 01 02 02 31 31 32 32 31 31 32 32
Again, work with four 4x4 blocks. Read 4 colors from the stream. Now, for every pixel of the block, read 2 bits from the stream and use it as the index of the color you just read before.
Draw nothing. Note that, due to the double buffering scheme used in the original decoder, this has the implicit effect of rendering the 8x8 block decoded two frames ago.
Just read 8*8 bytes from the stream and use them to draw the whole block.