Robot Animation - Revision history

Sembiance: samples

2025-05-14T15:08:34Z

samples

← Older revision		Revision as of 08:08, 14 May 2025
Line 1:		Line 1:
	* Extension: RBT		* Extension: RBT
	* Company: [[Sierra Entertainment]]		* Company: [[Sierra Entertainment]]
			* Samples: {{DexvertSamples\|video/sierraRobotAnimation}}

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

Multimedia Mike: /* Audio Format */ correct the audio format

2020-02-14T06:23:05Z

Audio Format: correct the audio format

← Older revision		Revision as of 23:23, 13 February 2020
Line 106:		Line 106:
	bytes 4-7 length of audio payload		bytes 4-7 length of audio payload

	The audio data is ~~uncompressed PCM~~.		The audio data is compressed with [[Sierra DPCM]].

	== Versions and Games ==		== Versions and Games ==

Multimedia Mike: /* Container Format */ clarify the fixed cel sizes based on the ScummVM source code

2020-02-14T06:20:26Z

Container Format: clarify the fixed cel sizes based on the ScummVM source code

← Older revision		Revision as of 23:20, 13 February 2020
Line 42:		Line 42:
	bytes 32-33 max skippable packets		bytes 32-33 max skippable packets
	bytes 34-35 max cels per frame		bytes 34-35 max cels per frame
	bytes 36-39 ~~pre-allocation~~ of ~~memory for~~ fixed ~~cels~~		bytes 36-39 the maximum possible size, in bytes, of the first fixed cel
	bytes 40-43 ~~pre-allocation~~ of ~~memory for~~ fixed ~~cels~~		bytes 40-43 the maximum possible size, in bytes, of the second fixed cel
	bytes 44-47 ~~pre-allocation~~ of ~~memory for~~ fixed ~~cels~~		bytes 44-47 the maximum possible size, in bytes, of the third fixed cel
	bytes 48-51 ~~pre-allocation~~ of ~~memory for~~ fixed ~~cels~~		bytes 48-51 the maximum possible size, in bytes, of the fourth fixed cel
	bytes 52-59 unknown		bytes 52-59 unknown
	bytes 60.. unknown data chunk, size defined by bytes 18-19		bytes 60.. unknown data chunk, size defined by bytes 18-19

Multimedia Mike: /* Audio Format */ describe audio header format

2020-02-14T05:18:20Z

Audio Format: describe audio header format

← Older revision		Revision as of 22:18, 13 February 2020
Line 101:		Line 101:

	== Audio Format ==		== Audio Format ==
	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.		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 uncompressed PCM.

	== Versions and Games ==		== Versions and Games ==

Multimedia Mike: more details determined, thanks to ScummVM

2020-02-14T00:51:54Z

more details determined, thanks to ScummVM

← Older revision		Revision as of 17:51, 13 February 2020
Line 33:		Line 33:
	bytes 16-17 palette data size		bytes 16-17 palette data size
	bytes 18-19 unknown chunk data size		bytes 18-19 unknown chunk data size
	bytes 20-24 ~~unknown~~		bytes 20-21 X resolution
			bytes 22-23 Y resolution
			byte 24 has palette
	byte 25 has sound		byte 25 has sound
	bytes 26-59 unknown		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 pre-allocation of memory for fixed cels
			bytes 40-43 pre-allocation of memory for fixed cels
			bytes 44-47 pre-allocation of memory for fixed cels
			bytes 48-51 pre-allocation of memory for fixed cels
			bytes 52-59 unknown
	bytes 60.. unknown data chunk, size defined by bytes 18-19		bytes 60.. unknown data chunk, size defined by bytes 18-19

Multimedia Mike: /* Audio Format */

2016-06-02T04:08:05Z

Audio Format

← Older revision		Revision as of 21:08, 1 June 2016
Line 90:		Line 90:

	== Audio Format ==		== Audio Format ==
			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 ==		== Versions and Games ==

Multimedia Mike: /* Video Format */ describe the video format

2016-06-02T04:05:28Z

Video Format: describe the video format

← Older revision		Revision as of 21:05, 1 June 2016
Line 62:		Line 62:

	== Video Format ==		== 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: [https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Stac standard Lempel-Ziv-Stac (LZS) compression]
			* type 2: raw, uncompressed image

	== Audio Format ==		== Audio Format ==

Multimedia Mike: name specific games and credit ScummVM for reverse engineering details

2016-06-02T03:46:49Z

name specific games and credit ScummVM for reverse engineering details

← Older revision		Revision as of 20:46, 1 June 2016
Line 3:		Line 3:

	Robot files are animation files used in various Sierra computer games. It is a container format that encapsulates video and possibly audio.		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 [http://scummvm.org/ ScummVM] source code, which only covers version 5 of the format.

	== Container Format ==		== Container Format ==
Line 67:		Line 69:

	* Version 4: [http://www.mobygames.com/game/daryl-f-gates-police-quest-swat Police Quest: SWAT] (demo)		* Version 4: [http://www.mobygames.com/game/daryl-f-gates-police-quest-swat Police Quest: SWAT] (demo)
	* Version 5: SCI 2.1 and SCI 3		* Version 5: SCI 2.1 and SCI 3, including [http://www.mobygames.com/game/roberta-williams-phantasmagoria Phantasmagoria] and [http://www.mobygames.com/game/rama Rama]
	* Version 6: SCI 3		* Version 6: SCI 3

	[[Category:Game Formats]]		[[Category:Game Formats]]

Multimedia Mike: finish the container portion

2016-06-02T03:42:21Z

finish the container portion

← Older revision		Revision as of 20:42, 1 June 2016
Line 14:		Line 14:
	<video frame size table>		<video frame size table>
	<frame size table>		<frame size table>
			<unknown tables>
	<padding>		<padding>
	<frame 1>		<frame 1>
	<frame 2>		<frame 2>
	...		...
	<frame n>		<frame n>

Line 49:		Line 50:

	Each palette component is 8 bits.		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 ==		== Video Format ==

Multimedia Mike: overall organization

2016-06-02T03:28:22Z

overall organization

← Older revision		Revision as of 20:28, 1 June 2016
Line 6:		Line 6:
	== Container Format ==		== Container Format ==
	All multi-byte numbers are little-endian.		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>
			<padding>
			<frame 1>
			<frame 2>
			...
			<frame n>

	A Robot file begins with the following variable-length header.		A Robot file begins with the following variable-length header.
Line 44:		Line 57:
	These are the known Robot format versions known to be associated with particular games and SCI engine revisions:		These are the known Robot format versions known to be associated with particular games and SCI engine revisions:

	* Version 4: [http://www.mobygames.com/game/daryl-f-gates-police-quest-swat Police Quest: SWAT]		* Version 4: [http://www.mobygames.com/game/daryl-f-gates-police-quest-swat Police Quest: SWAT] (demo)
	* Version 5: SCI 2.1 and SCI 3		* Version 5: SCI 2.1 and SCI 3
	* Version 6: SCI 3		* Version 6: SCI 3

	[[Category:Game Formats]]		[[Category:Game Formats]]