RES Format (Stellar 7)

Format type	Archive
Max files	Unlimited
File Allocation Table (FAT)	Embedded
Filenames?	Yes, 4 chars
Metadata?	None
Supports compression?	Yes
Supports encryption?	No
Supports subdirectories?	Yes
Hidden data?	No
Games	Stellar 7 The Incredible Machine

This article is partially complete. This means that all known information is here, but there is still more information that needs to be discovered and/or reverse engineered. If you know some of the missing information, you can help the ModdingWiki by adding this info yourself.

The RES Format is used by Stellar 7 and The Incredible Machine to store much of the game data. The PC version of Stellar 7 has 29 files using this format.

File format

It is a binary format containing any number of entries which themselves can contain other entries. Various items are stored in these files, such as compressed images and palette data, or the mission briefing text. The entries begin with a content type which can be clearly read even with a text editor.

Signature

There is no known signature, other than carefully reading the file structure and verifying it seems correct (e.g. offsets don't go past the end of the file.)

File entry

The file consists of one or more file entries, one after the other.

Data type	Name	Description
char[4]	contentType	Content type (see below), not null-terminated
UINT32LE	isFolder_length	Length of the data, most significant bit is folder bit
BYTE[length]	data	`length` bytes of data

If the most significant bit in isFolder_length is set, the data is comprised of more file entries in the same format as above, like a subdirectory. None of the game's data files appear to nest folders more than one level deep. The values can be extracted like this:

 length = isFolder_length & 0x7FFFFFFF
 if (isFolder_length & 0x80000000) then it is a folder

Content types

The following values for contentType are known. Any types that refer to sub-blocks mean "files" in the "subdirectory" as described above.

BMP: Image

The game supports VGA and earlier modes including EGA and CGA. The main palette information for VGA is located in the file STELART.RES while the EGA/CGA palettes are in STELARTE.RES.

contentType	Description
INF:	Slice guides for the bitmap. See below.

Some BMP: entries contain an INF: tag which indicates the amount of sub-images inside the file, and the dimensions for all of them.

Data type	Name	Description
UINT16LE	imgCount	Number of frames
UINT16LE[imgCount]	widths	The width values of all frames.
UINT16LE[imgCount]	heighs	The height values of all frames.

The sizes correspond to the image data. In LEVEL1.RES there are five size pairs:

(256,16) (256,16) (256,16) (256,16) (32,27)

These are combined with two images of 8,624 bytes each for a total of 17,248 bytes. If you multiply out these size pairs and add the results they should come up to the same number of bytes, as VGA palettes have a 1:1 pixel-to-byte ratio.

FNT: Font

There are two FNT: blocks in STELLAR.RES. They are both uncompressed in one of two formats; hints about these formats was found at the ScummVM-DGDS Project. Over there they are known as simple and complex. The two types are detailed on this wiki by the designations given to them in the Westwood Font Editor, which are Dynamix Font Format v3 and Dynamix Font Format v4.

PAL: Palette

The PAL: block contains palette data. It has sub-blocks for different palette types:

contentType	Description
VGA:	VGA Palette (three byte, 0-63)
EGA:
CGA:

SCR: Fullscreen image

Fullscreen images are 320x200 pixels; 32,000 bytes for EGA and 64,000 bytes for VGA.

The VGA files are split into two 32,000 byte "planes" using two pixels per byte. The second plane contains the more significant bits. For example, if the starting bytes of the first and second plane are 0xFD 0xFF and 0x99 0x88 respectively, then the first four horizontal pixels will be palette entries 0x9F 0x9D 0x8F 0x8F.

contentType	Description
BIN:	32000 byte (16-colour EGA / Least significant VGA bits)
VGA:	32000 byte (Most significant VGA bits)

VER: Version

Null terminated version string (e.g. "3.37")

SSM: Sounds and music

The SSM: block seems to contain media data in most cases. It has sub-blocks for different media types:

contentType	Description
SNG:	Song? Seems to be 8-bit unsigned 11025Hz PCM data with an unknown header
SNG:	Song - also can contain raw MIDI data (theme song is in this format)

The file STELLAR.RES contains three SSM: entries; two of them contain SNG: blocks while the third has entries for various sound cards, most likely a version of the theme song in a format suitable for that device. The content type tags for these are as follows:

contentType	Description
STD:	?
TAN:	Tandy
M32:	Roland?
ADL:	AdLib
SBL:	Sound Blaster
001:	?
002:	?

Compression

Some file entries are compressed using the LZW algorithm. The entries which are compressed cannot be identified by the 4-byte content type alone, and it is suspected that certain types are always compressed. Those entries that are compressed are in the following layout:

Data type	Name	Description
BYTE	compressionType	Compression algorithm. 0x00 for uncompressed, 0x01 for RLE, 0x02 for LZW, 0x03 for LH1.
UINT32LE	decompressedSize	Size of data after decompression
BYTE[]	data	Compressed data

Most games use only LZW as compression, though all Sierra/Dynamix games that support LZW should accept the two other compression types too.

The following content types never seem to have a compression header:

Data type	Description
VQT:	Might be its own type of compression. Format still not figured out so far. They seem to always be accompanies by an "OFF:" chunk.
FNT:
ARR:
PAG:
VGA:	Only if contained within a PAL: folder entry.

The LZW algorithm uses a dynamic bit length, from 9 bits to 12 bits. Data is split into bytes in little-endian order. The first codeword is 257, with code 256 reserved to indicate a dictionary reset.

When the dictionary is reset, if the total number of codewords read so far isn't divisible by 8, additional codewords are read (and ignored) until it is divisible.

There is some sample decompression code for similar games which seems to (mostly) work. As of now, a compression algorithm does not seem to be available, but the fact files can be re-saved with simpler RLE compression, or no compression at all, still means the compressed formats can be modded.

The LH1 algorithm is the same as the 'lh1' method in LHA files.

Credits

This file format was reverse engineered by Malvineous, with some subformats identified by Zab. Hints about the compression algorithm were obtained from the ScummVM project. Further research into the fonts was done by Nyerguds for the Westwood Font Editor. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)