Robot Animation

• Extension: RBT
• Company: Sierra Entertainment

Robot files are animation files used in various Sierra computer games. It is a container format that encapsulates video and possibly audio.

The details on this page were gleaned from ScummVM source code, which only covers version 5 of the format.

Container Format

All multi-byte numbers are little-endian.

The general organization of a Robot file is as follows:

<header>
<unknown block>
<palette>
<video frame size table>
<frame size table>
<unknown tables>
<padding>
<frame 1>
<frame 2>
  ...
<frame n>

A Robot file begins with the following variable-length header.

bytes 0-5    signature and probably a version (16 00 53 4f 4c 00; bytes 2-4 are 'SOL')
bytes 6-7    version
bytes 8-9    audio chunk size
bytes 10-11  silence chunk size
bytes 12-13  unknown
bytes 14-15  frame count
bytes 16-17  palette data size
bytes 18-19  unknown chunk data size
bytes 20-21  X resolution
bytes 22-23  Y resolution
byte 24      has palette
byte 25      has sound
bytes 26-27  unknown
bytes 28-29  framerate
bytes 30-31  is HiRes
bytes 32-33  max skippable packets
bytes 34-35  max cels per frame
bytes 36-39  the maximum possible size, in bytes, of the first fixed cel
bytes 40-43  the maximum possible size, in bytes, of the second fixed cel
bytes 44-47  the maximum possible size, in bytes, of the third fixed cel
bytes 48-51  the maximum possible size, in bytes, of the fourth fixed cel
bytes 52-59  unknown
bytes 60..   unknown data chunk, size defined by bytes 18-19

After the header is a palette chunk. The size of the palette chunk is defined it bytes 16-17 of the header. The first 37 or 38 bytes have the following format:

bytes 0-24   unknown
byte 25      first palette index to replace
bytes 29-30  palette count
byte 32      palette format (0 = variable, 1 = constant)
bytes 33-[36,37]  unknown
byte [37,38]..  palette components

The palette is 256 total entries, though the palette encoded in this chunk is only likely to encode a partial palette since the other colors are reserved for other parts of the game's user interface.

Replace (palette count) entries in the palette starting with the index specified by byte 25. The palette components are ordered red - green - blue - red - green - blue - etc. The palette components begin at index 37 for constant palettes and 38 for variable palettes.

Each palette component is 8 bits.

Following the palette chunk is 2 size tables: the first is the video frame size table and the second is the size table. Each table contains one 16-bit size value for each frame in the file (the frame count is defined in bytes 14-15 of the header).

Following the 2 size tables is more undefined data that has a constant size of 1536 bytes. Reverse engineering efforts indicate that this is a 1024-byte table followed by a 512-byte table.

Finally, there is padding before the frames. The first frame is aligned on a 2048-byte boundary (perhaps a CD sector boundary). Thus, after reading the previous unknown data, advance the file (0x800 - (current_offset(rbt_file) & 0x7ff)) bytes.

Then there the sequence of frames, the count of which is defined in the header. Each frame contains video and also audio, if the header indicates that the file contains sound. The size of the entire frame corresponds to the frame's entry in the frame size table. The video comes first and the size of the video portion corresponds to the frame's entry is the video frame size table. The remainder of the frame is the audio, and the value should match the audio chunk size specified in the header.

Video Format

A frame begins with a video frame and is possibly followed by audio. An individual video frame is completely intracoded (i.e., it does not depend on any other frames being decoded first). Each frame specifies its own width and height as well as an origin (x, y) coordinate that signals to the game engine where the frame should be placed on a scene.

A video frame begins with the following 24-byte header:

bytes 0-2    unknown
byte 3       frame scaling factor
bytes 4-5    frame width
bytes 6-7    frame height
bytes 8-11   unknown, often 0
bytes 12-13  frame X coordinate
bytes 14-15  frame Y coordinate
bytes 16-17  size of compressed data in bytes
bytes 18-19  number of frame fragments
bytes 20-23  unknown

The frame scaling factor is often 100, indicating 100% scaling (i.e., no scaling up or down). A scale factor of, e.g., 80 indicates that the decoded frame should be scaled to 80% of its full size.

After the header is a series of compressed fragments, the count of which is specified in the frame header. Many frames have a single fragment but some have more. Each fragment begins with the following 10-byte header:

bytes 0-3  fragment compressed size
bytes 4-7  fragment decompressed size
bytes 8-9  compression type

Only 2 types of compression are known:

• type 0: standard Lempel-Ziv-Stac (LZS) compression
• type 2: raw, uncompressed image

Audio Format

The remainder of the frame contains audio. The audio portion begins with the following 8-byte header:

bytes 0-3  unknown
bytes 4-7  length of audio payload

The audio data is compressed with Sierra DPCM.

Versions and Games

These are the known Robot format versions known to be associated with particular games and SCI engine revisions:

• Version 4: Police Quest: SWAT (demo)
• Version 5: SCI 2.1 and SCI 3, including Phantasmagoria and Rama
• Version 6: SCI 3