- 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.
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-24 unknown byte 25 has sound bytes 26-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.
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
The remainder of the frame contains audio. The audio portion begins with an 8-byte header of an unknown format. The audio data is uncompressed PCM.
Versions and Games
These are the known Robot format versions known to be associated with particular games and SCI engine revisions: