ModdingWiki - User contributions [en-gb]

RES Format (Stellar 7)

2012-04-03T04:04:34Z

Zab: /* BMP: Image */ Added better information about the INF slice guides.

{{NeedMoreInfo}}

The '''RES format''' is used by [[Stellar 7]] to store much of the game data. The PC version 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.

{|class="wikitable"
!Data type!!Description
|-
|char contentType[4]||Content type (see below), not null-terminated
|-
|UINT32LE isfolder_length||Length of the data, most significant bit is folder bit
|-
|BYTE data[length]||<tt>length</tt> bytes of data
|}

If the most significant bit in <tt>isfolder_length</tt> is set, the <tt>data</tt> 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 <tt>STELART.RES</tt> while the EGA/CGA palettes are in <tt>STELARTE.RES</tt>.

{|class="wikitable"
!contentType!!Description
|-
|INF:||Slice guides for the bitmap. See below.
|}

Some BMP: entries contain an INF: tag which appears to be layout guides for the image.

{|class="wikitable"
!Data type!!Description
|-
|UINT16LE pair_count||Number of size pairs to read
|-
|UINT16LE[2 * pair_count]||Sizes; stored with the width values first followed by the height values.
|}

The sizes correspond to the image data. In <tt>LEVEL1.RES</tt> 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 <tt>STELLAR.RES</tt>. They are both uncompressed in one of two formats; hints about these formats was found at the [http://code.google.com/p/scummvm-dgds/source/browse/trunk/resources/font.cpp?r=26 ScummVM-DGDS Project]. Over there they are known as ''simple'' and ''complex''.

The structure of these fonts are:

===== Simple Font =====

Simple fonts are fixed width.

{|class="wikitable"
!Data type!!Description
|-
|BYTE width||Width of the font in bits and pixels
|-
|BYTE height||Height of the font in bits and pixels
|-
|BYTE start||First character code in the font file
|-
|BYTE count||Number of characters in the font file
|-
|BYTE[height*count]||Font data
|}

Therefore, the file size for a simple font would be:

4 + (height * count)

Typically, the first character code is 0x20 (32). A font with a full uppercase set has a count of at least 0x40 (64) while a font with an upper/lowercase set has a count of at least 0x60 (96).

To find a particular character, look at the following position in the font data:

(character_code - start) * height

The simple font included in <tt>STELLAR.RES</tt> has a size of 8x6 pixels and starts at character 0x20. For character code 0x41 (65, letter A) the position would be (0x41 - 0x20) * 0x6 = 0xC6 (196). The data in this location is:

0x 7c 82 fe 82 82 00

This font is just a basic raster bitmap using 1 bit-per-pixel:

.11111..
1.....1.
1111111.
1.....1.
1.....1.
........

===== Complex Font =====

Complex fonts have varying widths.

{|class="wikitable"
!Data type!!Description
|-
|BYTE magic||Magic value 0xff
|-
|BYTE width||Maximum width of the font in bits and pixels
|-
|BYTE height||Height of the font in bits and pixels
|-
|BYTE unknown||
|-
|BYTE start||First character code in the font file
|-
|BYTE count||Number of characters in the font file
|-
|UINT16LE size||Size of the font data
|-
|BYTE unknown||Compression algorithm? Seems to be 0x02
|-
|UINT32LE uncompressed_size||Size of the uncompressed data
|-
|BYTE[font_size-13] data||LZW compressed font data
|}

The ''size'' and ''uncompressed_size'' appear to match. The uncompressed data contains what appears to be the following layout:

{|class="wikitable"
!Data type!!Description
|-
|UINT16LE[count] offsets||Positions for the characters in the data stream
|-
|BYTE[count] widths||Bit (or pixel) width for each characters
|-
|BYTE[uncompressed_size - (3*count)] data||Character data
|}

The complex font in <tt>STELLAR.RES</tt> appears to have only two characters with widths greater than eight requiring two bytes to be read for each glyph row rather than one. These characters are 0x42 (*) and 0x64 (@).

==== PAL: Palette ====

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

{|class="wikitable"
!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. If the starting bytes of the first plane are 0xFD 0xFF and the second plane are 0x99 0x88 then the first four horizontal pixels are palette entries 0x9F 0x9D 0x8F 0x8F.

{|class="wikitable"
!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:

{|class="wikitable"
!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 <tt>STELLAR.RES</tt> 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:

{|class="wikitable"
!contentType!!Description
|-
|STD:||?
|-
|TAN:||Tandy
|-
|M32:||Roland?
|-
|ADL:||AdLib
|-
|SBL:||Sound Blaster
|-
|001:||?
|-
|002:||?
|}

== Compression ==

Some file entries are compressed using the [[LZW compression|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:

{|class="wikitable"
!Data type!!Description
|-
|BYTE unknown||Compression algorithm? Always seems to be 0x02
|-
|UINT32LE decompressedSize||Size of data after decompression
|-
|BYTE data[]||LZW-compressed data
|}

The following content types never seem to be compressed:

{|class="wikitable"
!Data type!!Description
|-
|VQT:||
|-
|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, some bytes in the input data are discarded. Why this happens is currently unknown. The number of bytes discarded seems to vary depending on the number of bytes read (perhaps it is aligning to a DWORD boundary?)

There is some [http://code.google.com/p/scummvm-dgds/source/browse/trunk/compression.cpp sample decompression code] for similar games which seems to (mostly) work.

== Credits ==

This file format was reverse engineered by [[User:Malvineous|Malvineous]], with some subformats identified by [[User:Zab|Zab]]. Hints about the compression algorithm were obtained from the ScummVM project. 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!)

[[Category:Stellar 7]]
[[Category:File Formats]]
[[Category:Group Files]]
[[Category:Group Files with embedded FAT]]

RES Format (Stellar 7)

2012-04-03T02:04:24Z

Zab: /* Complex Font */ The shifted byte may have been a bug with the decompression implementation.

{{NeedMoreInfo}}

The '''RES format''' is used by [[Stellar 7]] to store much of the game data. The PC version 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.

{|class="wikitable"
!Data type!!Description
|-
|char contentType[4]||Content type (see below), not null-terminated
|-
|UINT32LE isfolder_length||Length of the data, most significant bit is folder bit
|-
|BYTE data[length]||<tt>length</tt> bytes of data
|}

If the most significant bit in <tt>isfolder_length</tt> is set, the <tt>data</tt> 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 <tt>STELART.RES</tt> while the EGA/CGA palettes are in <tt>STELARTE.RES</tt>.

{|class="wikitable"
!contentType!!Description
|-
|INF:||Possibly a way to slice up the bitmap. See below.
|}

Some BMP: entries contain an INF: tag which appears to be layout guides for the image. The blocks start with a UINT16LE number specifying 1/4th the number of remaining bytes in the entry. These bytes look like they contain pairs of UINT16LE numbers which correspond somewhat to coordinates in the image.

==== FNT: Font ====

There are two FNT: blocks in <tt>STELLAR.RES</tt>. They are both uncompressed in one of two formats; hints about these formats was found at the [http://code.google.com/p/scummvm-dgds/source/browse/trunk/resources/font.cpp?r=26 ScummVM-DGDS Project]. Over there they are known as ''simple'' and ''complex''.

The structure of these fonts are:

===== Simple Font =====

Simple fonts are fixed width.

{|class="wikitable"
!Data type!!Description
|-
|BYTE width||Width of the font in bits and pixels
|-
|BYTE height||Height of the font in bits and pixels
|-
|BYTE start||First character code in the font file
|-
|BYTE count||Number of characters in the font file
|-
|BYTE[height*count]||Font data
|}

Therefore, the file size for a simple font would be:

4 + (height * count)

Typically, the first character code is 0x20 (32). A font with a full uppercase set has a count of at least 0x40 (64) while a font with an upper/lowercase set has a count of at least 0x60 (96).

To find a particular character, look at the following position in the font data:

(character_code - start) * height

The simple font included in <tt>STELLAR.RES</tt> has a size of 8x6 pixels and starts at character 0x20. For character code 0x41 (65, letter A) the position would be (0x41 - 0x20) * 0x6 = 0xC6 (196). The data in this location is:

0x 7c 82 fe 82 82 00

This font is just a basic raster bitmap using 1 bit-per-pixel:

.11111..
1.....1.
1111111.
1.....1.
1.....1.
........

===== Complex Font =====

Complex fonts have varying widths.

{|class="wikitable"
!Data type!!Description
|-
|BYTE magic||Magic value 0xff
|-
|BYTE width||Maximum width of the font in bits and pixels
|-
|BYTE height||Height of the font in bits and pixels
|-
|BYTE unknown||
|-
|BYTE start||First character code in the font file
|-
|BYTE count||Number of characters in the font file
|-
|UINT16LE size||Size of the font data
|-
|BYTE unknown||Compression algorithm? Seems to be 0x02
|-
|UINT32LE uncompressed_size||Size of the uncompressed data
|-
|BYTE[font_size-13] data||LZW compressed font data
|}

The ''size'' and ''uncompressed_size'' appear to match. The uncompressed data contains what appears to be the following layout:

{|class="wikitable"
!Data type!!Description
|-
|UINT16LE[count] offsets||Positions for the characters in the data stream
|-
|BYTE[count] widths||Bit (or pixel) width for each characters
|-
|BYTE[uncompressed_size - (3*count)] data||Character data
|}

The complex font in <tt>STELLAR.RES</tt> appears to have only two characters with widths greater than eight requiring two bytes to be read for each glyph row rather than one. These characters are 0x42 (*) and 0x64 (@).

==== PAL: Palette ====

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

{|class="wikitable"
!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. If the starting bytes of the first plane are 0xFD 0xFF and the second plane are 0x99 0x88 then the first four horizontal pixels are palette entries 0x9F 0x9D 0x8F 0x8F.

{|class="wikitable"
!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:

{|class="wikitable"
!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 <tt>STELLAR.RES</tt> 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:

{|class="wikitable"
!contentType!!Description
|-
|STD:||?
|-
|TAN:||Tandy
|-
|M32:||Roland?
|-
|ADL:||AdLib
|-
|SBL:||Sound Blaster
|-
|001:||?
|-
|002:||?
|}

== Compression ==

Some file entries are compressed using the [[LZW compression|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:

{|class="wikitable"
!Data type!!Description
|-
|BYTE unknown||Compression algorithm? Always seems to be 0x02
|-
|UINT32LE decompressedSize||Size of data after decompression
|-
|BYTE data[]||LZW-compressed data
|}

The following content types never seem to be compressed:

{|class="wikitable"
!Data type!!Description
|-
|VQT:||
|-
|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, some bytes in the input data are discarded. Why this happens is currently unknown. The number of bytes discarded seems to vary depending on the number of bytes read (perhaps it is aligning to a DWORD boundary?)

There is some [http://code.google.com/p/scummvm-dgds/source/browse/trunk/compression.cpp sample decompression code] for similar games which seems to (mostly) work.

== Credits ==

This file format was reverse engineered by [[User:Malvineous|Malvineous]], with some subformats identified by [[User:Zab|Zab]]. Hints about the compression algorithm were obtained from the ScummVM project. 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!)

[[Category:Stellar 7]]
[[Category:File Formats]]
[[Category:Group Files]]
[[Category:Group Files with embedded FAT]]

RES Format (Stellar 7)

2012-03-28T09:47:38Z

Zab: /* Complex Font */ Added some remaining info on the complex font. I have some more work to do on why the uncompressed font appears to be shifted a byte.

{{NeedMoreInfo}}

The '''RES format''' is used by [[Stellar 7]] to store much of the game data. The PC version 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.

{|class="wikitable"
!Data type!!Description
|-
|char contentType[4]||Content type (see below), not null-terminated
|-
|UINT32LE isfolder_length||Length of the data, most significant bit is folder bit
|-
|BYTE data[length]||<tt>length</tt> bytes of data
|}

If the most significant bit in <tt>isfolder_length</tt> is set, the <tt>data</tt> 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 <tt>STELART.RES</tt> while the EGA/CGA palettes are in <tt>STELARTE.RES</tt>.

{|class="wikitable"
!contentType!!Description
|-
|INF:||Possibly a way to slice up the bitmap. See below.
|}

Some BMP: entries contain an INF: tag which appears to be layout guides for the image. The blocks start with a UINT16LE number specifying 1/4th the number of remaining bytes in the entry. These bytes look like they contain pairs of UINT16LE numbers which correspond somewhat to coordinates in the image.

==== FNT: Font ====

There are two FNT: blocks in <tt>STELLAR.RES</tt>. They are both uncompressed in one of two formats; hints about these formats was found at the [http://code.google.com/p/scummvm-dgds/source/browse/trunk/resources/font.cpp?r=26 ScummVM-DGDS Project]. Over there they are known as ''simple'' and ''complex''.

The structure of these fonts are:

===== Simple Font =====

Simple fonts are fixed width.

{|class="wikitable"
!Data type!!Description
|-
|BYTE width||Width of the font in bits and pixels
|-
|BYTE height||Height of the font in bits and pixels
|-
|BYTE start||First character code in the font file
|-
|BYTE count||Number of characters in the font file
|-
|BYTE[height*count]||Font data
|}

Therefore, the file size for a simple font would be:

4 + (height * count)

Typically, the first character code is 0x20 (32). A font with a full uppercase set has a count of at least 0x40 (64) while a font with an upper/lowercase set has a count of at least 0x60 (96).

To find a particular character, look at the following position in the font data:

(character_code - start) * height

The simple font included in <tt>STELLAR.RES</tt> has a size of 8x6 pixels and starts at character 0x20. For character code 0x41 (65, letter A) the position would be (0x41 - 0x20) * 0x6 = 0xC6 (196). The data in this location is:

0x 7c 82 fe 82 82 00

This font is just a basic raster bitmap using 1 bit-per-pixel:

.11111..
1.....1.
1111111.
1.....1.
1.....1.
........

===== Complex Font =====

Complex fonts have varying widths.

{|class="wikitable"
!Data type!!Description
|-
|BYTE magic||Magic value 0xff
|-
|BYTE width||Maximum width of the font in bits and pixels
|-
|BYTE height||Height of the font in bits and pixels
|-
|BYTE unknown||
|-
|BYTE start||First character code in the font file
|-
|BYTE count||Number of characters in the font file
|-
|UINT16LE size||Size of the font data
|-
|BYTE unknown||Compression algorithm? Seems to be 0x02
|-
|UINT32LE uncompressed_size||Size of the uncompressed data
|-
|BYTE[font_size-13] data||LZW compressed font data
|}

The ''size'' and ''uncompressed_size'' appear to match. The uncompressed data contains what appears to be the following layout:

{|class="wikitable"
!Data type!!Description
|-
|UINT16LE[count] offsets||Positions for the characters in the data stream
|-
|BYTE[count] widths||Bit (or pixel) width for each characters
|-
|BYTE[uncompressed_size - (3*count)] data||Character data
|}

The complex font in <tt>STELLAR.RES</tt> appears to be missing the first byte, which would be 0x00 to coincide with the offsets to follow. The last may be redundant. Only two characters have widths greater than 8 requiring two bytes to be read for each glyph row rather than one. These characters are 0x42 (*) and 0x64 (@).

==== PAL: Palette ====

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

{|class="wikitable"
!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. If the starting bytes of the first plane are 0xFD 0xFF and the second plane are 0x99 0x88 then the first four horizontal pixels are palette entries 0x9F 0x9D 0x8F 0x8F.

{|class="wikitable"
!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:

{|class="wikitable"
!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 <tt>STELLAR.RES</tt> 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:

{|class="wikitable"
!contentType!!Description
|-
|STD:||?
|-
|TAN:||Tandy
|-
|M32:||Roland?
|-
|ADL:||AdLib
|-
|SBL:||Sound Blaster
|-
|001:||?
|-
|002:||?
|}

== Compression ==

Some file entries are compressed using the [[LZW compression|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:

{|class="wikitable"
!Data type!!Description
|-
|BYTE unknown||Compression algorithm? Always seems to be 0x02
|-
|UINT32LE decompressedSize||Size of data after decompression
|-
|BYTE data[]||LZW-compressed data
|}

The following content types never seem to be compressed:

{|class="wikitable"
!Data type!!Description
|-
|VQT:||
|-
|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, some bytes in the input data are discarded. Why this happens is currently unknown. The number of bytes discarded seems to vary depending on the number of bytes read (perhaps it is aligning to a DWORD boundary?)

There is some [http://code.google.com/p/scummvm-dgds/source/browse/trunk/compression.cpp sample decompression code] for similar games which seems to (mostly) work.

== Credits ==

This file format was reverse engineered by [[User:Malvineous|Malvineous]], with some subformats identified by [[User:Zab|Zab]]. Hints about the compression algorithm were obtained from the ScummVM project. 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!)

[[Category:Stellar 7]]
[[Category:File Formats]]
[[Category:Group Files]]
[[Category:Group Files with embedded FAT]]

RES Format (Stellar 7)

2012-03-28T03:17:02Z

Zab: /* Simple Font */ small wording

{{NeedMoreInfo}}

The '''RES format''' is used by [[Stellar 7]] to store much of the game data. The PC version 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.

{|class="wikitable"
!Data type!!Description
|-
|char contentType[4]||Content type (see below), not null-terminated
|-
|UINT32LE isfolder_length||Length of the data, most significant bit is folder bit
|-
|BYTE data[length]||<tt>length</tt> bytes of data
|}

If the most significant bit in <tt>isfolder_length</tt> is set, the <tt>data</tt> 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 <tt>STELART.RES</tt> while the EGA/CGA palettes are in <tt>STELARTE.RES</tt>.

{|class="wikitable"
!contentType!!Description
|-
|INF:||Possibly a way to slice up the bitmap. See below.
|}

Some BMP: entries contain an INF: tag which appears to be layout guides for the image. The blocks start with a UINT16LE number specifying 1/4th the number of remaining bytes in the entry. These bytes look like they contain pairs of UINT16LE numbers which correspond somewhat to coordinates in the image.

==== FNT: Font ====

There are two FNT: blocks in <tt>STELLAR.RES</tt>. They are both uncompressed in one of two formats; hints about these formats was found at the [http://code.google.com/p/scummvm-dgds/source/browse/trunk/resources/font.cpp?r=26 ScummVM-DGDS Project]. Over there they are known as ''simple'' and ''complex''.

The structure of these fonts are:

===== Simple Font =====

Simple fonts are fixed width.

{|class="wikitable"
!Data type!!Description
|-
|BYTE width||Width of the font in bits and pixels
|-
|BYTE height||Height of the font in bits and pixels
|-
|BYTE start||First character code in the font file
|-
|BYTE count||Number of characters in the font file
|-
|BYTE[height*count]||Font data
|}

Therefore, the file size for a simple font would be:

4 + (height * count)

Typically, the first character code is 0x20 (32). A font with a full uppercase set has a count of at least 0x40 (64) while a font with an upper/lowercase set has a count of at least 0x60 (96).

To find a particular character, look at the following position in the font data:

(character_code - start) * height

The simple font included in <tt>STELLAR.RES</tt> has a size of 8x6 pixels and starts at character 0x20. For character code 0x41 (65, letter A) the position would be (0x41 - 0x20) * 0x6 = 0xC6 (196). The data in this location is:

0x 7c 82 fe 82 82 00

This font is just a basic raster bitmap using 1 bit-per-pixel:

.11111..
1.....1.
1111111.
1.....1.
1.....1.
........

===== Complex Font =====

Complex fonts have varying widths, though the limit seems to be 8.

{|class="wikitable"
!Data type!!Description
|-
|BYTE magic||Magic value 0xff
|-
|BYTE width||Width of the font in bits and pixels
|-
|BYTE height||Height of the font in bits and pixels
|-
|BYTE unknown||
|-
|BYTE start||First character code in the font file
|-
|BYTE count||Number of characters in the font file
|-
|UINT16LE size||Size of the font data
|-
|BYTE unknown||Compression algorithm? Seems to be 0x02
|-
|UINT32LE uncompressed_size||Size of the uncompressed data
|-
|BYTE[font_size-13] data||LZW compressed font data
|}

The ''size'' and ''uncompressed_size'' appear to match.

The uncompressed data contains what appears to be the following layout:

{|class="wikitable"
!Data type!!Description
|-
|UINT16LE[count] offsets||Positions for the characters in the data stream
|-
|BYTE[count] widths||Sizes for the characters
|-
|BYTE[uncompressed_size - (3*count)] data||Character data
|}

==== PAL: Palette ====

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

{|class="wikitable"
!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. If the starting bytes of the first plane are 0xFD 0xFF and the second plane are 0x99 0x88 then the first four horizontal pixels are palette entries 0x9F 0x9D 0x8F 0x8F.

{|class="wikitable"
!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:

{|class="wikitable"
!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 <tt>STELLAR.RES</tt> 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:

{|class="wikitable"
!contentType!!Description
|-
|STD:||?
|-
|TAN:||Tandy
|-
|M32:||Roland?
|-
|ADL:||AdLib
|-
|SBL:||Sound Blaster
|-
|001:||?
|-
|002:||?
|}

== Compression ==

Some file entries are compressed using the [[LZW compression|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:

{|class="wikitable"
!Data type!!Description
|-
|BYTE unknown||Compression algorithm? Always seems to be 0x02
|-
|UINT32LE decompressedSize||Size of data after decompression
|-
|BYTE data[]||LZW-compressed data
|}

The following content types never seem to be compressed:

{|class="wikitable"
!Data type!!Description
|-
|VQT:||
|-
|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, some bytes in the input data are discarded. Why this happens is currently unknown. The number of bytes discarded seems to vary depending on the number of bytes read (perhaps it is aligning to a DWORD boundary?)

There is some [http://code.google.com/p/scummvm-dgds/source/browse/trunk/compression.cpp sample decompression code] for similar games which seems to (mostly) work.

== Credits ==

This file format was reverse engineered by [[User:Malvineous|Malvineous]], with some subformats identified by [[User:Zab|Zab]]. Hints about the compression algorithm were obtained from the ScummVM project. 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!)

[[Category:Stellar 7]]
[[Category:File Formats]]
[[Category:Group Files]]
[[Category:Group Files with embedded FAT]]

RES Format (Stellar 7)

2012-03-28T03:15:27Z

Zab: /* Simple Font */ Added a bit more on interpreting the simple fonts. Probably needs it's own Dynamix font format page

{{NeedMoreInfo}}

The '''RES format''' is used by [[Stellar 7]] to store much of the game data. The PC version 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.

{|class="wikitable"
!Data type!!Description
|-
|char contentType[4]||Content type (see below), not null-terminated
|-
|UINT32LE isfolder_length||Length of the data, most significant bit is folder bit
|-
|BYTE data[length]||<tt>length</tt> bytes of data
|}

If the most significant bit in <tt>isfolder_length</tt> is set, the <tt>data</tt> 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 <tt>STELART.RES</tt> while the EGA/CGA palettes are in <tt>STELARTE.RES</tt>.

{|class="wikitable"
!contentType!!Description
|-
|INF:||Possibly a way to slice up the bitmap. See below.
|}

Some BMP: entries contain an INF: tag which appears to be layout guides for the image. The blocks start with a UINT16LE number specifying 1/4th the number of remaining bytes in the entry. These bytes look like they contain pairs of UINT16LE numbers which correspond somewhat to coordinates in the image.

==== FNT: Font ====

There are two FNT: blocks in <tt>STELLAR.RES</tt>. They are both uncompressed in one of two formats; hints about these formats was found at the [http://code.google.com/p/scummvm-dgds/source/browse/trunk/resources/font.cpp?r=26 ScummVM-DGDS Project]. Over there they are known as ''simple'' and ''complex''.

The structure of these fonts are:

===== Simple Font =====

Simple fonts are fixed width.

{|class="wikitable"
!Data type!!Description
|-
|BYTE width||Width of the font in bits and pixels
|-
|BYTE height||Height of the font in bits and pixels
|-
|BYTE start||First character code in the font file
|-
|BYTE count||Number of characters in the font file
|-
|BYTE[height*count]||Font data
|}

Therefore, the file size for a simple font would be:

4 + (height * count)

Typically, the first character code is 0x20 (32). A font with a full uppercase set has a count of at least 0x40 (64) while a font with an upper/lowercase set has a count of at least 0x60 (96).

To find a character in the font data, look at the following position in the font data:

(character_code - start) * height

The simple font included in <tt>STELLAR.RES</tt> has a size of 8x6 pixels and starts at character 0x20. For character code 0x41 (65, letter A) the position would be (0x41 - 0x20) * 0x6 = 0xC6 (196). The data in this location is:

0x 7c 82 fe 82 82 00

This font is just a basic raster bitmap using 1 bit-per-pixel:

.11111..
1.....1.
1111111.
1.....1.
1.....1.
........

===== Complex Font =====

Complex fonts have varying widths, though the limit seems to be 8.

{|class="wikitable"
!Data type!!Description
|-
|BYTE magic||Magic value 0xff
|-
|BYTE width||Width of the font in bits and pixels
|-
|BYTE height||Height of the font in bits and pixels
|-
|BYTE unknown||
|-
|BYTE start||First character code in the font file
|-
|BYTE count||Number of characters in the font file
|-
|UINT16LE size||Size of the font data
|-
|BYTE unknown||Compression algorithm? Seems to be 0x02
|-
|UINT32LE uncompressed_size||Size of the uncompressed data
|-
|BYTE[font_size-13] data||LZW compressed font data
|}

The ''size'' and ''uncompressed_size'' appear to match.

The uncompressed data contains what appears to be the following layout:

{|class="wikitable"
!Data type!!Description
|-
|UINT16LE[count] offsets||Positions for the characters in the data stream
|-
|BYTE[count] widths||Sizes for the characters
|-
|BYTE[uncompressed_size - (3*count)] data||Character data
|}

==== PAL: Palette ====

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

{|class="wikitable"
!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. If the starting bytes of the first plane are 0xFD 0xFF and the second plane are 0x99 0x88 then the first four horizontal pixels are palette entries 0x9F 0x9D 0x8F 0x8F.

{|class="wikitable"
!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:

{|class="wikitable"
!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 <tt>STELLAR.RES</tt> 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:

{|class="wikitable"
!contentType!!Description
|-
|STD:||?
|-
|TAN:||Tandy
|-
|M32:||Roland?
|-
|ADL:||AdLib
|-
|SBL:||Sound Blaster
|-
|001:||?
|-
|002:||?
|}

== Compression ==

Some file entries are compressed using the [[LZW compression|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:

{|class="wikitable"
!Data type!!Description
|-
|BYTE unknown||Compression algorithm? Always seems to be 0x02
|-
|UINT32LE decompressedSize||Size of data after decompression
|-
|BYTE data[]||LZW-compressed data
|}

The following content types never seem to be compressed:

{|class="wikitable"
!Data type!!Description
|-
|VQT:||
|-
|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, some bytes in the input data are discarded. Why this happens is currently unknown. The number of bytes discarded seems to vary depending on the number of bytes read (perhaps it is aligning to a DWORD boundary?)

There is some [http://code.google.com/p/scummvm-dgds/source/browse/trunk/compression.cpp sample decompression code] for similar games which seems to (mostly) work.

== Credits ==

This file format was reverse engineered by [[User:Malvineous|Malvineous]], with some subformats identified by [[User:Zab|Zab]]. Hints about the compression algorithm were obtained from the ScummVM project. 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!)

[[Category:Stellar 7]]
[[Category:File Formats]]
[[Category:Group Files]]
[[Category:Group Files with embedded FAT]]

RES Format (Stellar 7)

2012-03-27T14:14:21Z

Zab: /* Content types */ Added some font info (thanks to scummvm-dgds), still working on visual representation.

{{NeedMoreInfo}}

The '''RES format''' is used by [[Stellar 7]] to store much of the game data. The PC version 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.

{|class="wikitable"
!Data type!!Description
|-
|char contentType[4]||Content type (see below), not null-terminated
|-
|UINT32LE isfolder_length||Length of the data, most significant bit is folder bit
|-
|BYTE data[length]||<tt>length</tt> bytes of data
|}

If the most significant bit in <tt>isfolder_length</tt> is set, the <tt>data</tt> 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 <tt>STELART.RES</tt> while the EGA/CGA palettes are in <tt>STELARTE.RES</tt>.

{|class="wikitable"
!contentType!!Description
|-
|INF:||Possibly a way to slice up the bitmap. See below.
|}

Some BMP: entries contain an INF: tag which appears to be layout guides for the image. The blocks start with a UINT16LE number specifying 1/4th the number of remaining bytes in the entry. These bytes look like they contain pairs of UINT16LE numbers which correspond somewhat to coordinates in the image.

==== FNT: Font ====

There are two FNT: blocks in <tt>STELLAR.RES</tt>. They are both uncompressed in one of two formats; hints about these formats was found at the [http://code.google.com/p/scummvm-dgds/source/browse/trunk/resources/font.cpp?r=26 ScummVM-DGDS Project]. Over there they are known as ''simple'' and ''complex''.

The structure of these fonts are:

===== Simple Font =====

Simple fonts are fixed width.

{|class="wikitable"
!Data type!!Description
|-
|BYTE width||Width of the font in bits and pixels
|-
|BYTE height||Height of the font in bits and pixels
|-
|BYTE start||First character code in the font file
|-
|BYTE count||Number of characters in the font file
|-
|BYTE[height*count]||Font data
|}

Therefore, the file size for a simple font would be:

4 + (height * count)

Typically, the first character code is 0x20 (32). A font with a full uppercase set has a count of at least 0x40 (64) while a font with an upper/lowercase set has a count of at least 0x60 (96).

The font data is a raster bitmap with 1 bit-per-pixel.

===== Complex Font =====

Complex fonts have varying widths, though the limit seems to be 8.

{|class="wikitable"
!Data type!!Description
|-
|BYTE magic||Magic value 0xff
|-
|BYTE width||Width of the font in bits and pixels
|-
|BYTE height||Height of the font in bits and pixels
|-
|BYTE unknown||
|-
|BYTE start||First character code in the font file
|-
|BYTE count||Number of characters in the font file
|-
|UINT16LE size||Size of the font data
|-
|BYTE unknown||Compression algorithm? Seems to be 0x02
|-
|UINT32LE uncompressed_size||Size of the uncompressed data
|-
|BYTE[font_size-13] data||LZW compressed font data
|}

The ''size'' and ''uncompressed_size'' appear to match.

The uncompressed data contains what appears to be the following layout:

{|class="wikitable"
!Data type!!Description
|-
|UINT16LE[count] offsets||Positions for the characters in the data stream
|-
|BYTE[count] widths||Sizes for the characters
|-
|BYTE[uncompressed_size - (3*count)] data||Character data
|}

==== PAL: Palette ====

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

{|class="wikitable"
!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. If the starting bytes of the first plane are 0xFD 0xFF and the second plane are 0x99 0x88 then the first four horizontal pixels are palette entries 0x9F 0x9D 0x8F 0x8F.

{|class="wikitable"
!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:

{|class="wikitable"
!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 <tt>STELLAR.RES</tt> 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:

{|class="wikitable"
!contentType!!Description
|-
|STD:||?
|-
|TAN:||Tandy
|-
|M32:||Roland?
|-
|ADL:||AdLib
|-
|SBL:||Sound Blaster
|-
|001:||?
|-
|002:||?
|}

== Compression ==

Some file entries are compressed using the [[LZW compression|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:

{|class="wikitable"
!Data type!!Description
|-
|BYTE unknown||Compression algorithm? Always seems to be 0x02
|-
|UINT32LE decompressedSize||Size of data after decompression
|-
|BYTE data[]||LZW-compressed data
|}

The following content types never seem to be compressed:

{|class="wikitable"
!Data type!!Description
|-
|VQT:||
|-
|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, some bytes in the input data are discarded. Why this happens is currently unknown. The number of bytes discarded seems to vary depending on the number of bytes read (perhaps it is aligning to a DWORD boundary?)

There is some [http://code.google.com/p/scummvm-dgds/source/browse/trunk/compression.cpp sample decompression code] for similar games which seems to (mostly) work.

== Credits ==

This file format was reverse engineered by [[User:Malvineous|Malvineous]], with some subformats identified by [[User:Zab|Zab]]. Hints about the compression algorithm were obtained from the ScummVM project. 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!)

[[Category:Stellar 7]]
[[Category:File Formats]]
[[Category:Group Files]]
[[Category:Group Files with embedded FAT]]

RES Format (Stellar 7)

2012-03-27T09:06:43Z

Zab: /* File entry */ Observation about folders

Talk:RES Format (Stellar 7)

2012-03-27T08:42:44Z

Zab: /* Compression */ Added file links for LZW help

== Compression ==
I was able to get an LZW decompressor working beautifully up until some time after code reset 0x100 is encountered. I'm using [http://cibyl.googlecode.com/svn/sarien-cibyl/trunk/src/core/lzw.c this source] with some compatibility fixes. I'm wondering how much is known about discarding bytes. Using LEVEL1.RES for example, the third compressed block has a code reset about 2/3rds of the way through the finished product. I can finish the decoding if I eat three bytes but the remaining image starts becoming corrupted. The eaten bytes don't look useless either; even the remaining 8 bits in the buffer produce what looks like the next palette number in the output. Any thoughts? [[User:Zab|Zab]] 18:31, 3 March 2012 (GMT)

: I don't know much about LZW decompression, but in my limited experience there are a bunch of different things that can happen. If 0x100 is a reset sequence, it may not reset the entire dictionary. Upon a reset, the length of the codeword may or may not be restored to its initial length (i.e. if it starts at 9-bits and grows to 12-bits, upon reset it may go back to 9-bits or stay at 12-bits.) There are other things I can't think of right now too. If you can find an already decompressed file and then compare that byte by byte to the compressed data as it is being decompressed, you will know at exactly which byte it goes wrong, and what byte it should have been instead, which could provide some hints. -- [[User:Malvineous|Malvineous]] 13:16, 6 March 2012 (GMT)

:: I've pounded my head on this plenty. I won't say I've given up but I'm going to put this up in case anyone can help out. Here is [https://gist.github.com/2213872 the decompression code] and [http://www.mediafire.com/?712b70p1u2svaf4,a8v2xwf2g5k7y5y two compressed files], both working and non-working with a decompressed size of 32,000 bytes. Any assistance is appreciated. [[User:Zab|Zab]] 08:42, 27 March 2012 (GMT)

RES Format (Stellar 7)

2012-03-06T13:55:16Z

Zab: /* BMP: Image */ Added INF: stuff

Stellar 7

2012-03-06T11:23:23Z

Zab: added some stuff about the executable and restructured.

{{GamePage}}
{{NoModdingInfo}}

Stellar 7 was released in the 1980s for various platforms ending with a PC version in 1990.

== File formats ==

This section lists the file formats used in the game.

* [[RES Format (Stellar 7)|RES Format]] - group files storing most of the game data

== Files ==

The PC version appears to have been compiled with a Microsoft C compiler. Much of the data is stored in bundled .RES files but a decent amount is also hard-coded in the packed executable. Some of the data in the external files is also compressed using an [[LZW compression|LZW algorithm]].

=== Executable ===

The PC executable is compressed using [[LZEXE]] version 0x91. [http://www.shikadi.net/files/unlzexe.c Here] is some sample code which appears to successfully decompress it.

=== RES game data ===

There are 29 files in the PC version using the RES format.

{|class="wikitable"
!Filename!!Description
|-
|STELLAR.RES||Video/Audio (drivers?), probably the game intro song, what looks like fonts, and others.
|-
|COCKPIT.RES||Cockpit graphics and sound effects, mission briefing text, and others.
|-
|DRAXON.RES||A single SNG: media entry.
|-
|VOICE.RES||Contains some SNG: media entries.
|-
|LEVEL''#''.RES||There are seven level files where ''#'' is 1-7. These files contain background images in VGA and EGA/CGA, a sound entry, and what appears to be a table of level data.
|}

The rest of the files come in two versions, a VGA version and an EGA/CGA version. The easy-to-spot difference between them is the EGA files have a letter E after them. The files are:

{|class="wikitable"
!Filename!!Description
|-
|STELART.RES / STELARTE.RES|| Art files with palette info necessary to parse images from anywhere else.
|-
|SCENE''x''.RES / SCENE''x''E.RES||Sixteen "scene" files, eight each where ''x'' is one of A, B1, B2, B3, B5, C, D, or E.
|-
|}

=== Other Files ===

* <tt>RESOURCE.CFG</tt> contains the current configuration set by <tt>INSTALL.COM</tt>. The first byte is the selected video mode (monochrome CGA up to 256-colour VGA) and the second byte is the selected sound card.

[[Category:Sierra]]
[[Category:3D]]
[[Category:First-Person Shooter]]

Stellar 7

2012-03-06T06:37:36Z

Zab: oops linkfix

{{GamePage}}
{{NoModdingInfo}}

Stellar 7 was released in the 1980s for various platforms ending with a PC version in 1990.

The PC version appears to have been compiled with a Microsoft C compiler. Much of the data is stored in bundled .RES files but a decent amount is also hard-coded in the compressed executable. Some of the data in the external files is also compressed using an [[LZW compression|LZW algorithm]].

== File formats ==

This section lists the file formats used in the game.

* [[RES Format (Stellar 7)|RES Format]] - group files storing most of the game data

There are 29 files in the PC version using the RES format.

{|class="wikitable"
!Filename!!Description
|-
|STELLAR.RES||Video/Audio (drivers?), probably the game intro song, what looks like fonts, and others.
|-
|COCKPIT.RES||Cockpit graphics and sound effects, mission briefing text, and others.
|-
|DRAXON.RES||A single SNG: media entry.
|-
|VOICE.RES||Contains some SNG: media entries.
|-
|LEVEL''#''.RES||There are seven level files where ''#'' is 1-7. These files contain background images in VGA and EGA/CGA, a sound entry, and what appears to be a table of level data.
|}

The rest of the files come in two versions, a VGA version and an EGA/CGA version. The easy-to-spot difference between them is the EGA files have a letter E after them. The files are:

{|class="wikitable"
!Filename!!Description
|-
|STELART.RES / STELARTE.RES|| Art files with palette info necessary to parse images from anywhere else.
|-
|SCENE''x''.RES / SCENE''x''E.RES||Sixteen "scene" files, eight each where ''x'' is one of A, B1, B2, B3, B5, C, D, or E.
|-
|}

== Other Files ==

The file ''RESOURCE.CFG'' is referenced by the executable, though it is unclear how it is being used.

[[Category:Sierra]]
[[Category:3D]]
[[Category:First-Person Shooter]]

Stellar 7

2012-03-06T05:38:44Z

Zab: Added files block from the format article and some other text

{{GamePage}}
{{NoModdingInfo}}

Stellar 7 was released in the 1980s for various platforms ending with a PC version in 1990.

The PC version appears to have been compiled with a Microsoft C compiler. Much of the data is stored in bundled .RES files but a decent amount is also hard-coded in the compressed executable. Some of the data in the external files is also compressed using a variant of [[LZW]].

== File formats ==

This section lists the file formats used in the game.

* [[RES Format (Stellar 7)|RES Format]] - group files storing most of the game data

There are 29 files in the PC version using the RES format.

{|class="wikitable"
!Filename!!Description
|-
|STELLAR.RES||Video/Audio (drivers?), probably the game intro song, what looks like fonts, and others.
|-
|COCKPIT.RES||Cockpit graphics and sound effects, mission briefing text, and others.
|-
|DRAXON.RES||A single SNG: media entry.
|-
|VOICE.RES||Contains some SNG: media entries.
|-
|LEVEL''#''.RES||There are seven level files where ''#'' is 1-7. These files contain background images in VGA and EGA/CGA, a sound entry, and what appears to be a table of level data.
|}

The rest of the files come in two versions, a VGA version and an EGA/CGA version. The easy-to-spot difference between them is the EGA files have a letter E after them. The files are:

{|class="wikitable"
!Filename!!Description
|-
|STELART.RES / STELARTE.RES|| Art files with palette info necessary to parse images from anywhere else.
|-
|SCENE''x''.RES / SCENE''x''E.RES||Sixteen "scene" files, eight each where ''x'' is one of A, B1, B2, B3, B5, C, D, or E.
|-
|}

== Other Files ==

The file ''RESOURCE.CFG'' is referenced by the executable, though it is unclear how it is being used.

[[Category:Sierra]]
[[Category:3D]]
[[Category:First-Person Shooter]]

RES Format (Stellar 7)

2012-03-06T05:35:46Z

Zab: Moving files to Stellar 7

Talk:RES Format (Stellar 7)

2012-03-03T18:31:39Z

Zab: Starting LZW discussion

RES Format (Stellar 7)

2012-03-02T20:45:47Z

Zab: Added a bunch of stuff. Will be working more on it.

{{NeedMoreInfo}}

The '''RES format''' is used by [[Stellar 7]] to store much of the game data. The PC version has 29 files using this format.

== Files ==

{|class="wikitable"
!Filename!!Description
|-
|STELLAR.RES||Video/Audio (drivers?), probably the game intro song, what looks like fonts, and others.
|-
|COCKPIT.RES||Cockpit graphics and sound effects, mission briefing text, and others.
|-
|DRAXON.RES||A single SNG: media entry.
|-
|VOICE.RES||Contains some SNG: media entries.
|-
|LEVEL''#''.RES||There are seven level files where ''#'' is 1-7. These files contain background images in VGA and EGA/CGA, a sound entry, and what appears to be a table of level data.
|}

The rest of the files come in two versions, a VGA version and an EGA/CGA version. The easy-to-spot difference between them is the EGA files have a letter E after them. The files are:

{|class="wikitable"
!Filename!!Description
|-
|STELART.RES / STELARTE.RES|| Art files with palette info necessary to parse images from anywhere else.
|-
|SCENE''x''.RES / SCENE''x''E.RES||Sixteen "scene" files, eight each where ''x'' is one of A, B1, B2, B3, B5, C, D, or E.
|-
|}

== 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:

[[Image:stellar_7_res_sample.png]]

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

{|class="wikitable"
!Data type!!Description
|-
|char contentType[4]||Content type (see below), not null-terminated
|-
|UINT32LE isfolder_length||Length of the data, MSB is folder bit
|-
|BYTE data[length]||<tt>length</tt> bytes of data
|}

If the most significant bit in <tt>isfolder_length</tt> is set, the <tt>data</tt> is comprised of more file entries in the same format as above (sort of like a subdirectory.) 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''.

==== PAL: Palette ====

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

{|class="wikitable"
!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. If the starting bytes of the first plane are 0xFD 0xFF and the second plane are 0x99 0x88 then the first four horizontal pixels are palette entries 0x9F 0x9D 0x8F 0x8F.

{|class="wikitable"
!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:

{|class="wikitable"
!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 what looks like various sound cards (possibly drivers). The content type tags for these are as follows:

{|class="wikitable"
!contentType!!Description
|-
|STD:||?
|-
|TAN:||Tandy
|-
|M32:||Roland?
|-
|ADL:||AdLib
|-
|SBL:||Sound Blaster
|-
|001:||?
|-
|002:||?
|}

== Compression ==

Some file entries are compressed using an [[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:

{|class="wikitable"
!Data type!!Description
|-
|BYTE unknown||Compression algorithm? Always seems to be 0x02
|-
|UINT32LE decompressedSize||Size of data after decompression
|-
|BYTE data[]||LZW-compressed data
|}

The following content types never seem to be compressed:

{|class="wikitable"
!Data type!!Description
|-
|VQT:||
|-
|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, some bytes in the input data are discarded. Why this happens is currently unknown. The number of bytes discarded seems to vary depending on the number of bytes read (perhaps it is aligning to a DWORD boundary?)

There is some [http://code.google.com/p/scummvm-dgds/source/browse/trunk/compression.cpp sample decompression code] for similar games which seems to (mostly) work.

== Credits ==

This file format was reverse engineered by [[User:Malvineous|Malvineous]]. Hints about the compression algorithm were obtained from the ScummVM project. 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!)

[[Category:Stellar 7]]
[[Category:File Formats]]
[[Category:Group Files]]
[[Category:Group Files with embedded FAT]]

User:Zab

2012-02-29T15:16:22Z

Zab: Fix link

I currently enjoy binary stuff in c++, and I have done hours of work on [[Stellar 7]]. I've gotten much help from this wiki so this is where I want to share my work.