C93: Difference between revisions

From MultimediaWiki
Jump to navigation Jump to search
m (categorize, link BTC)
m (→‎Mode 7: mode 7 also dblbuf-affected)
 
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
C93 is a video format used in Interplay's game Cyberia. It is not seems that is has been used anywhere else (Cyberia 2 comes with a slightly modified version named [[M95]]). 93 is most likely refers to format creation year.
* Extension: c93
* Company: [[Interplay Entertainment]]
* Samples: http://samples.mplayerhq.hu/game-formats/cyberia-c93/


C93 operates in standard VGA 320x200x256 resolution and based on [[BTC]] encoding and simple block copying.
C93 is a video format used in the DOS version of the game [http://www.mobygames.com/game/dos/cyberia Cyberia]. It seems that is has not been used anywhere else ([http://www.mobygames.com/game/cyberia-2-resurrection Cyberia 2] comes with a slightly modified version named [[M95]]). The 'c93' extension most likely refers to the format creation year.


== File structure ==
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.


File begins with a 512-entries blocks table:
== File Structure ==


  word sector  - index of the frames block
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:
  byte length  - length of the block's data (in sectors)
  byte frames  - number of frames in the block


Zero length field indicates end of the table. Sector means 2048-bytes chunk of data. Thus, block with sector index 1 starts at offset 2048, 2 - 4096, etc.
  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


Each block contains variable number of actual frames (usually 11) and starts with it's own index table, holding (dword) offsets of the particular frame, relative to the block base.
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.




Frame structure:
Frame structure:
   word video_size       - size of the following video data
   2 bytes    video_size           - size of the following video data
   byte video[video_size] - compressed frame
   1 byte     video[video_size]     - compressed frame
   word palette_size     - size of the following palette
   2 bytes    palette_size         - size of the following palette
   byte palette[256 * 3] - 256 BGR triplets of the palette
   1 byte     palette[palette_size] - 256 BGR triplets of the palette if palette_size is non-zero
   word sound_size       - size of the following sound chunk
   2 bytes    sound_size           - size of the following sound chunk
   byte sound[sound_size] - sound data, stored as a complete [[VOC]] file
   1 byte     sound[sound_size]     - sound data, stored as a complete [[VOC]] file


== Video compression ==
== Video Compression ==


Video encoded as a pairs of adjacent 8x8 blocks. Each pair starts with a byte, describing block's (de)compression mode. Lower nybble used for the first (left) block, high - for the second (right) block. Compression modes, in hex:
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:


* 2
=== Mode 2 ===
Read two bytes of the offset. Copy 8x8 block at that offset from the previous frame.
Read two bytes of the offset. Copy 8x8 block at that offset (in bytes) from the previous frame.


* 6
=== Mode 6 ===
Same as method 2, but split 8x8 block on to four 4x4 block and copy each one independingly. Left to right, top to bottom.
Same as method 2, but split 8x8 block into four 4x4 blocks and copy each one independently, left to right, top to bottom.


* 7
=== Mode 7 ===
Similar to method 6, but copy blocks from the current frame.
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.


* 8
=== Mode 8 ===
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 it's bit (starting from the 0) is set or color0 if it's not.
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.


* A
=== Mode A ===
Exactly as 8, but for four 4x4 blocks, each with it's own pair of color0/color1 and mask.
Exactly as 8, but for four 4x4 blocks, each with its own pair of color0/color1 and mask.


* B
=== Mode B ===
This one similar to A, with small enhancement. For each 4x4 block read 4 color bytes. Paint pixels using following colors combinations:
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
  01 01 02 02
  01 01 02 02
Line 50: Line 54:
  31 31 32 32
  31 31 32 32


* D
=== Mode D ===
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.
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.


* E
=== Mode E ===
Draw nothing
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.


* F
=== Mode F ===
Just read 8*8 bytes from the stream and use them to draw whole block.
Just read 8*8 bytes from the stream and use them to draw the whole block.


[[Category:Video Codecs]]
[[Category:Game Formats]]
[[Category:Game Formats]]

Latest revision as of 13:27, 12 July 2006

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.

File Structure

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.


Frame structure:

 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 Compression

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:

Mode 2

Read two bytes of the offset. Copy 8x8 block at that offset (in bytes) from the previous frame.

Mode 6

Same as method 2, but split 8x8 block into four 4x4 blocks and copy each one independently, left to right, top to bottom.

Mode 7

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.

Mode 8

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.

Mode A

Exactly as 8, but for four 4x4 blocks, each with its own pair of color0/color1 and mask.

Mode B

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

Mode D

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.

Mode E

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.

Mode F

Just read 8*8 bytes from the stream and use them to draw the whole block.