ModdingWiki - User contributions [en-gb]

TED5

2023-03-16T19:56:41Z

Frenkel: /* Download */ The same version of TED5 that's in the SNES version of Super 3-D Noah's Ark is also found in the ROTT '93 prototype

{{Tool Infobox
| Image = TED5-Keen4.png
| Platform = DOS
| Download = [http://legacy.3drealms.com/downloads.html#rott 3drealms.com]
| Edit1 = Map
| Games =
{{Game|Bio Menace}}
{{Game|Catacomb 3-D}}
{{Game|Commander Keen 4-6}}
{{Game|Commander Keen Dreams}}
{{Game|Dangerous Dave 3}}
{{Game|Dangerous Dave 4}}
{{Game|Rise of the Triad}}
{{Game|Wolfenstein 3-D}}
}}

Tile Editor v5.0 (TED5) is a level editor written by [[:Category:id Software|id Software]] that has been used to create the levels for many of their games. It edits the [[GameMaps Format]] seen in many older id Software games and is also apparently able to edit the [[Commander Keen 1-3 Level format]], though how is not known.

== Files used by TED5 ==

TED5 is compatible with any ID game that has a <tt>GAMEMAPS.xxx</tt> file. However the actual <tt>GAMEMAPS.xxx</tt> file is the final product, many other supporting files are required for TED5 to function.

If the game is 'compressed', it will not have most of these files. [[Commander Keen 4-6]] is one such game. In contrast 'uncompressed' games such as [[Bio Menace]] will have the full complement of files. Sadly, most games are compressed, as this is most efficient.

=== EGAGRAPH.xxx, EGAHEAD.xxx and EGADCT.xxx ===

These are explained fully under [[EGAGraph Format]]; they are respectively the game graphics, the graphics header and the [[Huffman Compression]] dictionary for decompressing graphics. Compressed games will just have the <tt>EGAGRAPH</tt>; with the HEAD and DCT files stored internally in the executable. Uncompressed games will have an external <tt>EGAHEAD</tt> and no need for an <tt>EGADCT</tt> file.

Like all Huffman dictionaries, the <tt>EGADCT</tt> file can be located in the executable by looking for the string <tt>$FD $01 $00 $00 $00 $00</tt> which is found at the file's end. (The file will be 1024 bytes long.) The <tt>EGAHEAD</tt> file can be located by looking for a 4 (Or 3) byte string which is the <tt>EGAGRAPH</tt> file size, this is always the last entry. (If you then proceed to move backwards until you reach a zero value entry, you will have the start of the file.)

You will receive an error if these files are absent. If the DCT is missing then TED5 will assume graphics are uncompressed.


=== Gamemaps ===

The <tt>GAMEMAPS</tt> file is not used, but is produced by TED5. It contains the compressed game maps and is produced from the <tt>MAPTEMP</tt> file when the user selects 'Carmackize maps' in TED5. Carmackization is complex and takes a long time to do. Because of this it is recommended that modders use Instant Carma! (See below)

=== GFXINFOE.xxx ===

This is a 46 byte file that contains data allowing TED5 to extract the graphics used in levels.It consists of a number of numbers and locations of various tile types.

Levels can be made of 8x8, 16x16 or 32x32 tiles (Always 16 color EGA.) Levels have a foreground plane, and may also have a background and info (Sprite) plane.The structure of the <tt>GFXINFOE</tt> file is as follows:

{|class="wikitable"
!Offset!!Type!!Description
|-
|0||[[UINT16LE]]||Number of 8x8 background tiles
|-
|2||[[UINT16LE]]||Number of 8x8 foreground tiles
|-
|4||[[UINT16LE]]||Number of 16x16 background tiles
|-
|6||[[UINT16LE]]||Number of 16x16 foreground tiles
|-
|8||[[UINT16LE]]||Number of 32x32 background tiles
|-
|10||[[UINT16LE]]||Number of 32x32 foreground tiles
|-
|12||[[UINT16LE]]||8x8 back tile start
|-
|14||[[UINT16LE]]||8x8 fore tile start
|-
|16||[[UINT16LE]]||16x16 back start
|-
|18||[[UINT16LE]]||16x16 fore start
|-
|20||[[UINT16LE]]||32x32 back start
|-
|22||[[UINT16LE]]||32x32 fore start
|-
|24||[[UINT16LE]]||Number of pictures
|-
|26||[[UINT16LE]]||Number of masked pictures
|-
|28||[[UINT16LE]]||Number of sprites
|-
|30||[[UINT16LE]]||Picture start
|-
|32||[[UINT16LE]]||Mask picture start
|-
|34||[[UINT16LE]]||Sprite start
|-
|36||[[UINT16LE]]||"offpicstr"
|-
|38||[[UINT16LE]]||"offpicmstr"
|-
|40||[[UINT16LE]]||"offstrstr"
|-
|42||[[UINT16LE]]||Number of extra EGA resources
|-
|44||[[UINT16LE]]||Extra EGA resource start
|}

The location (Start) given for tiles is the entry in the <tt>EGAHEAD.xxx</tt> file, most <tt>EGAHEAD.xxx</tt> files consist of 3 byte entries so the actual location, in bytes, in the file is three times this, though older games (Such as [[Commander Keen Dreams]]) have 4 byte entries. (It is not known if or how TED5 tells the difference between these.) Each tile has its own entry in the header.

The icons used by TED5 (For sprites, etc) are calculated as follows; icons follow directly after background tiles, then foreground tiles. There will thus be some 'extra' slots between the back and fore tiles. These are used as the number of icons.

This file is found with uncompressed games, but has to be created for compressed games. It is not currently known if it can be extracted somehow from the executable or if it is hard coded for each game.

=== Maptemp and Mapthead ===

The <tt>MAPTEMP</tt> file contains the uncarmackized level maps. Carmackization is a form of compression related to [[Keen 1-3 LZW compression]] in that it employs a sliding window. <tt>MAPTEMP</tt> is however [[RLE Compression]] compressed to avoid excess size. This is easy for TED5 to edit though. This file is changed each time levels are saved in TED5 and is not used by the game. To make usable levels you must select the item 'Carmackize maps' in the file menu, which will produce the <tt>GAMEMAPS</tt> file.

<tt>MAPTHEAD</tt> is the header for the <tt>MAPTEMP</tt> file. When maps are carmackized it is used to create the <tt>MAPHEAD</tt> file. <tt>MAPTHEAD</tt> contains several variables used by TED5 and some older games. Notably it has information for IDs tileinfo program to work with. Its structure is as follows:

{|class="wikitable"
!Offset!!Type!!Description
|-
|0||[[UINT16LE]]||Bit field for level planes (+1 unmasked, +2 masked, +4 infoplane)
|-
|2||[[UINT16LE]]||Type of tile (8x8 = 1, 16x16 = 2, 32x32 = 3)
|-
|4||[[UINT16LE]]|||Number of unmasked tileinfo (TILEINFO) planes in file. Most games 2, speed and offset. Max 10
|-
|6||[[UINT16LE]]||Number of unmasked tiles
|-
|8||[[UINT32LE]][10]||Pointers to tileinfo planes in <tt>MAPTHEAD</tt> file
|-
|48||[[UINT16LE]][10]||Size of TILFINFO planes data.
|-
|68||[[char]][10][8]||TILEINFO plane names
|-
|148||[[UINT16LE]]||Number of masked tileinfo (TILEINFOM) planes in file. Usually 7. Max 10
|-
|150||[[UINT16LE]]||Number of masked tiles
|-
|152||[[UINT16LE]][10]||Pointers to TILEINFOM planes in file
|-
|192||[[UINT16LE]][10]||Size of TILFINFOM planes data.
|-
|212||[[char]][10][8]||TILFINFOM plane names
|-
|292||[[UINT16LE]]||RLEW flag, default $ABCD
|-
|294||[[UINT32LE]][100]||Pointers to level headers in <tt>MAPTEMP</tt>. 100 pointers, null values are -1 ($FFFFFFFF)
|-
|694||[[UINT32LE]][100]||Level header sizes <tt>MAPTEMP</tt>. Older games Huffman Compressed headers and used this. Older games have $26 here, the (uncompressed) header size and don't use it
|-
|1094||[[UINT16LE]]||Number of ICON rows TED5 sets aside from masked tiles to display icons. For most games this is 5
|-
|1096||[[char]][x]||Optional TILEINFOM and TILEINFO data
|}

=== Tedinfo ===

This file is used by TED5 to store various details of the level format. Important here is the number of planes in each level, and the number of icons. Icons (used for sprites) are taken from the foreground tiles. The known values are:

{|class="wikitable"
!Offset!!Type!!Description
|-
|0||[[UINT16LE]]||Level TED opens in (last edited)
|-
|2||[[UINT16LE]]||Screen view, close (1) or distant (2)
|-
|colspan=3|...
|-
|8||[[UINT16LE]]||Number of tile planes in levels (usually 2, fore and back)
|-
|colspan=3|...
|-
|35||[[BYTE]]||Planes editable/visible in TED; +1 view icon, +2 view fore, +4 view back, +16 edit icon, +32 edit fore, +64 edit back
|-
|36||[[UINT16LE]]||h loc in level
|-
|38||[[UINT16LE]]||v loc in level
|-
|colspan=3|...
|-
|119||[[char]][64]||Import map path
|}

== Backup files ==

TED5 backs up all its files when levels are saved or carmackized or TED5 is exited. The old files are saved as <tt>*.BAK</tt> files and a simple renaming will suffice to undo the latest change. Only one backup is made so it is wise to save these files occasionally.

== Setting up TED5 ==

For uncompressed games, such as [[Bio Menace]], all that is required is to copy the file <tt>TED5.EXE</tt> into the games directory. For compressed games the situation is slightly more complex.

Some games, such as [[Commander Keen 4-6]] have a Ted setup utility to either extract or create the necessary files. If this is the case then a two step process is required. The first involves copying TED5 and the setup utility and running the setup to obtain the required files. The second step involves using a patching utility (Such as [[CKPatch]]) to patch the modified files back into the executable.

Finally, some games, such as [[Catacomb 3-D]], have no utilities at present. While it is not impossible to modify the levels in these games, it takes a bit more work, since the required files must be extracted manually and the executables illegally modified. It has already been mentioned how the graphics files can be located in an executable, but other files will need to be hard coded until somebody automates the procedure.

== Modifying levels ==

If TED5 is setup correctly then it should run (Dosbox may be required for this.) and go to the first level in the game, usually a world map. There are a number of commands and actions that can be used, which will not be covered here. After the desired changes have been made the user must select 'Carmackize maps' from the file menu to produce a modified <tt>GAMEMAPS</tt> and <tt>MAPHEAD</tt> file. For compressed games such as Keen this file will then need to be patched into the executable.

A level can be completely replaced with one from another GAMEMAPS file by using the 'Import levels' command under the file menu. (You will need to specify a patch to a valid GAMEMAPS file.) This allows a person to copy levels between backups, etc.

The program Instant Carma! skips Carmack compression by doing the very minimal amount of work. It takes a fraction of the time of TED5 and can be used while TED5 is running and is thus very useful. Sadly it is only available for Commander Keen 4-6.



== Other utilities ==

* CKPatch: A set of utilities that allow Keen 4-6 executables to be modified temporarily and legally by patching a copy of the executable into memory and modifying that. This is vital for using new levels in Keen 4-6 There are several versions available, with the latest having the most features. http://www.bipship.com/CKPatch
* Fixmhead: This converts the <tt>MAPTHEAD</tt> file to <tt>MAPHEAD</tt>. It is not really required for anything, but is included with a lot of TED5 packs.
* Galaxymk: This pack contains everything needed to set Commander Keen 4-6 games up for editing with TED5, including the setups and patchers. http://keenmodding.org/search.php?search_author=The_Fosti&sid=92cde18022face91063ec52109b6c2ec
* Instant Carma!: by CK Guy externalizes the carmackization of Keen 4-6 maps, saving time and improving efficiency. http://www.keenmodding.org/viewtopic.php?t=997
* Tedsetup: A program that sets up certain games to be editable by TED5, automatically extracting or creating required files, Often comes with TED5

== Supported Games ==

See the infobox above for a list of games that have been successfully edited with TED5, although many of those games have dedicated editors that are more user friendly.

== Download ==

TED5 has been released as open source freeware. TED5 and its source code can be downloaded from [https://legacy.3drealms.com/downloads.html#rott 3D Realms]. It can be used to edit the levels of Bio Menace and to create new levels for Rise of the Triad. It is also possible to edit the levels of Commander Keen 4-6, but this is a bit harder to [http://www.keenmodding.org/viewtopic.php?t=899 set up].

Older versions can be found in [http://web.archive.org/web/20060522213934/http://www.rome.ro/downloads/ddici/ddici.zip Dangerous Dave in Copyright Infringement], in the [https://wl6.fandom.com/wiki/Rise_of_the_Triad_Betas Rise of the Triad September 1993 prototype] and in the source code of the SNES version of [https://github.com/MatthewCallis/NOAH3D/tree/master/NOAH3D/MAPS Super 3-D Noah's Ark].

[[Category:id Software]]

Microsoft BASIC MML

2022-09-03T20:14:43Z

Frenkel: added Paganitzu

{{Music Infobox
| Type = Custom
| Instruments = PC speaker
| NumChannels = 1
| NumTracks = 1
| NumPatterns = 1
| NumOrders = 0
| Tags = None
| Games =
{{Game|Castle Adventure}}
{{Game|Paganitzu}}
{{Game|The Oregon Trail}}
}}

'''Microsoft BASIC MML''' is a Music Macro Language developed by Microsoft for their version of the BASIC computer language. The format supports a fair number of traditional sheet music notation. Many games developed in Microsoft BASIC will use this format for music and sound effects. However, despite being initially developed for BASIC, libraries were written which could play the MML in other languages as well, so there are also DOS games written in languages other than BASIC which use this format.

For example, the following MML will play Yankee Doodle:

o4 l8 g g a b g b a d g g a b l4 g l8 f# d g g a b> c d l8 e. l16 f# l8 e d e f# g e d g f# a l4 g g

== External links ==
* [http://www.vgmpf.com/Wiki/index.php?title=Microsoft_BASIC_MML Video Game Music Preservation Foundation] - Detailed descriptions on the entire MML as well as the BASIC commands which use it.

TED5

2022-08-11T16:38:18Z

Frenkel: /* Download */ added older versions

{{Tool Infobox
| Image = TED5-Keen4.png
| Platform = DOS
| Download = [http://legacy.3drealms.com/downloads.html#rott 3drealms.com]
| Edit1 = Map
| Games =
{{Game|Bio Menace}}
{{Game|Catacomb 3-D}}
{{Game|Commander Keen 4-6}}
{{Game|Commander Keen Dreams}}
{{Game|Dangerous Dave 3}}
{{Game|Dangerous Dave 4}}
{{Game|Rise of the Triad}}
{{Game|Wolfenstein 3-D}}
}}

Tile Editor v5.0 (TED5) is a level editor written by [[:Category:id Software|id Software]] that has been used to create the levels for many of their games. It edits the [[GameMaps Format]] seen in many older id Software games and is also apparently able to edit the [[Commander Keen 1-3 Level format]], though how is not known.

== Files used by TED5 ==

TED5 is compatible with any ID game that has a <tt>GAMEMAPS.xxx</tt> file. However the actual <tt>GAMEMAPS.xxx</tt> file is the final product, many other supporting files are required for TED5 to function.

If the game is 'compressed', it will not have most of these files. [[Commander Keen 4-6]] is one such game. In contrast 'uncompressed' games such as [[Bio Menace]] will have the full complement of files. Sadly, most games are compressed, as this is most efficient.

=== EGAGRAPH.xxx, EGAHEAD.xxx and EGADCT.xxx ===

These are explained fully under [[EGAGraph Format]]; they are respectively the game graphics, the graphics header and the [[Huffman Compression]] dictionary for decompressing graphics. Compressed games will just have the <tt>EGAGRAPH</tt>; with the HEAD and DCT files stored internally in the executable. Uncompressed games will have an external <tt>EGAHEAD</tt> and no need for an <tt>EGADCT</tt> file.

Like all Huffman dictionaries, the <tt>EGADCT</tt> file can be located in the executable by looking for the string <tt>$FD $01 $00 $00 $00 $00</tt> which is found at the file's end. (The file will be 1024 bytes long.) The <tt>EGAHEAD</tt> file can be located by looking for a 4 (Or 3) byte string which is the <tt>EGAGRAPH</tt> file size, this is always the last entry. (If you then proceed to move backwards until you reach a zero value entry, you will have the start of the file.)

You will receive an error if these files are absent. If the DCT is missing then TED5 will assume graphics are uncompressed.


=== Gamemaps ===

The <tt>GAMEMAPS</tt> file is not used, but is produced by TED5. It contains the compressed game maps and is produced from the <tt>MAPTEMP</tt> file when the user selects 'Carmackize maps' in TED5. Carmackization is complex and takes a long time to do. Because of this it is recommended that modders use Instant Carma! (See below)

=== GFXINFOE.xxx ===

This is a 46 byte file that contains data allowing TED5 to extract the graphics used in levels.It consists of a number of numbers and locations of various tile types.

Levels can be made of 8x8, 16x16 or 32x32 tiles (Always 16 color EGA.) Levels have a foreground plane, and may also have a background and info (Sprite) plane.The structure of the <tt>GFXINFOE</tt> file is as follows:

{|class="wikitable"
!Offset!!Type!!Description
|-
|0||[[UINT16LE]]||Number of 8x8 background tiles
|-
|2||[[UINT16LE]]||Number of 8x8 foreground tiles
|-
|4||[[UINT16LE]]||Number of 16x16 background tiles
|-
|6||[[UINT16LE]]||Number of 16x16 foreground tiles
|-
|8||[[UINT16LE]]||Number of 32x32 background tiles
|-
|10||[[UINT16LE]]||Number of 32x32 foreground tiles
|-
|12||[[UINT16LE]]||8x8 back tile start
|-
|14||[[UINT16LE]]||8x8 fore tile start
|-
|16||[[UINT16LE]]||16x16 back start
|-
|18||[[UINT16LE]]||16x16 fore start
|-
|20||[[UINT16LE]]||32x32 back start
|-
|22||[[UINT16LE]]||32x32 fore start
|-
|24||[[UINT16LE]]||Number of pictures
|-
|26||[[UINT16LE]]||Number of masked pictures
|-
|28||[[UINT16LE]]||Number of sprites
|-
|30||[[UINT16LE]]||Picture start
|-
|32||[[UINT16LE]]||Mask picture start
|-
|34||[[UINT16LE]]||Sprite start
|-
|36||[[UINT16LE]]||"offpicstr"
|-
|38||[[UINT16LE]]||"offpicmstr"
|-
|40||[[UINT16LE]]||"offstrstr"
|-
|42||[[UINT16LE]]||Number of extra EGA resources
|-
|44||[[UINT16LE]]||Extra EGA resource start
|}

The location (Start) given for tiles is the entry in the <tt>EGAHEAD.xxx</tt> file, most <tt>EGAHEAD.xxx</tt> files consist of 3 byte entries so the actual location, in bytes, in the file is three times this, though older games (Such as [[Commander Keen Dreams]]) have 4 byte entries. (It is not known if or how TED5 tells the difference between these.) Each tile has its own entry in the header.

The icons used by TED5 (For sprites, etc) are calculated as follows; icons follow directly after background tiles, then foreground tiles. There will thus be some 'extra' slots between the back and fore tiles. These are used as the number of icons.

This file is found with uncompressed games, but has to be created for compressed games. It is not currently known if it can be extracted somehow from the executable or if it is hard coded for each game.

=== Maptemp and Mapthead ===

The <tt>MAPTEMP</tt> file contains the uncarmackized level maps. Carmackization is a form of compression related to [[Keen 1-3 LZW compression]] in that it employs a sliding window. <tt>MAPTEMP</tt> is however [[RLE Compression]] compressed to avoid excess size. This is easy for TED5 to edit though. This file is changed each time levels are saved in TED5 and is not used by the game. To make usable levels you must select the item 'Carmackize maps' in the file menu, which will produce the <tt>GAMEMAPS</tt> file.

<tt>MAPTHEAD</tt> is the header for the <tt>MAPTEMP</tt> file. When maps are carmackized it is used to create the <tt>MAPHEAD</tt> file. <tt>MAPTHEAD</tt> contains several variables used by TED5 and some older games. Notably it has information for IDs tileinfo program to work with. Its structure is as follows:

{|class="wikitable"
!Offset!!Type!!Description
|-
|0||[[UINT16LE]]||Bit field for level planes (+1 unmasked, +2 masked, +4 infoplane)
|-
|2||[[UINT16LE]]||Type of tile (8x8 = 1, 16x16 = 2, 32x32 = 3)
|-
|4||[[UINT16LE]]|||Number of unmasked tileinfo (TILEINFO) planes in file. Most games 2, speed and offset. Max 10
|-
|6||[[UINT16LE]]||Number of unmasked tiles
|-
|8||[[UINT32LE]][10]||Pointers to tileinfo planes in <tt>MAPTHEAD</tt> file
|-
|48||[[UINT16LE]][10]||Size of TILFINFO planes data.
|-
|68||[[char]][10][8]||TILEINFO plane names
|-
|148||[[UINT16LE]]||Number of masked tileinfo (TILEINFOM) planes in file. Usually 7. Max 10
|-
|150||[[UINT16LE]]||Number of masked tiles
|-
|152||[[UINT16LE]][10]||Pointers to TILEINFOM planes in file
|-
|192||[[UINT16LE]][10]||Size of TILFINFOM planes data.
|-
|212||[[char]][10][8]||TILFINFOM plane names
|-
|292||[[UINT16LE]]||RLEW flag, default $ABCD
|-
|294||[[UINT32LE]][100]||Pointers to level headers in <tt>MAPTEMP</tt>. 100 pointers, null values are -1 ($FFFFFFFF)
|-
|694||[[UINT32LE]][100]||Level header sizes <tt>MAPTEMP</tt>. Older games Huffman Compressed headers and used this. Older games have $26 here, the (uncompressed) header size and don't use it
|-
|1094||[[UINT16LE]]||Number of ICON rows TED5 sets aside from masked tiles to display icons. For most games this is 5
|-
|1096||[[char]][x]||Optional TILEINFOM and TILEINFO data
|}

=== Tedinfo ===

This file is used by TED5 to store various details of the level format. Important here is the number of planes in each level, and the number of icons. Icons (used for sprites) are taken from the foreground tiles. The known values are:

{|class="wikitable"
!Offset!!Type!!Description
|-
|0||[[UINT16LE]]||Level TED opens in (last edited)
|-
|2||[[UINT16LE]]||Screen view, close (1) or distant (2)
|-
|colspan=3|...
|-
|8||[[UINT16LE]]||Number of tile planes in levels (usually 2, fore and back)
|-
|colspan=3|...
|-
|35||[[BYTE]]||Planes editable/visible in TED; +1 view icon, +2 view fore, +4 view back, +16 edit icon, +32 edit fore, +64 edit back
|-
|36||[[UINT16LE]]||h loc in level
|-
|38||[[UINT16LE]]||v loc in level
|-
|colspan=3|...
|-
|119||[[char]][64]||Import map path
|}

== Backup files ==

TED5 backs up all its files when levels are saved or carmackized or TED5 is exited. The old files are saved as <tt>*.BAK</tt> files and a simple renaming will suffice to undo the latest change. Only one backup is made so it is wise to save these files occasionally.

== Setting up TED5 ==

For uncompressed games, such as [[Bio Menace]], all that is required is to copy the file <tt>TED5.EXE</tt> into the games directory. For compressed games the situation is slightly more complex.

Some games, such as [[Commander Keen 4-6]] have a Ted setup utility to either extract or create the necessary files. If this is the case then a two step process is required. The first involves copying TED5 and the setup utility and running the setup to obtain the required files. The second step involves using a patching utility (Such as [[CKPatch]]) to patch the modified files back into the executable.

Finally, some games, such as [[Catacomb 3-D]], have no utilities at present. While it is not impossible to modify the levels in these games, it takes a bit more work, since the required files must be extracted manually and the executables illegally modified. It has already been mentioned how the graphics files can be located in an executable, but other files will need to be hard coded until somebody automates the procedure.

== Modifying levels ==

If TED5 is setup correctly then it should run (Dosbox may be required for this.) and go to the first level in the game, usually a world map. There are a number of commands and actions that can be used, which will not be covered here. After the desired changes have been made the user must select 'Carmackize maps' from the file menu to produce a modified <tt>GAMEMAPS</tt> and <tt>MAPHEAD</tt> file. For compressed games such as Keen this file will then need to be patched into the executable.

A level can be completely replaced with one from another GAMEMAPS file by using the 'Import levels' command under the file menu. (You will need to specify a patch to a valid GAMEMAPS file.) This allows a person to copy levels between backups, etc.

The program Instant Carma! skips Carmack compression by doing the very minimal amount of work. It takes a fraction of the time of TED5 and can be used while TED5 is running and is thus very useful. Sadly it is only available for Commander Keen 4-6.



== Other utilities ==

* CKPatch: A set of utilities that allow Keen 4-6 executables to be modified temporarily and legally by patching a copy of the executable into memory and modifying that. This is vital for using new levels in Keen 4-6 There are several versions available, with the latest having the most features. http://www.bipship.com/CKPatch
* Fixmhead: This converts the <tt>MAPTHEAD</tt> file to <tt>MAPHEAD</tt>. It is not really required for anything, but is included with a lot of TED5 packs.
* Galaxymk: This pack contains everything needed to set Commander Keen 4-6 games up for editing with TED5, including the setups and patchers. http://keenmodding.org/search.php?search_author=The_Fosti&sid=92cde18022face91063ec52109b6c2ec
* Instant Carma!: by CK Guy externalizes the carmackization of Keen 4-6 maps, saving time and improving efficiency. http://www.keenmodding.org/viewtopic.php?t=997
* Tedsetup: A program that sets up certain games to be editable by TED5, automatically extracting or creating required files, Often comes with TED5

== Supported Games ==

See the infobox above for a list of games that have been successfully edited with TED5, although many of those games have dedicated editors that are more user friendly.

== Download ==

TED5 has been released as open source freeware. TED5 and its source code can be downloaded from [https://legacy.3drealms.com/downloads.html#rott 3D Realms]. It can be used to edit the levels of Bio Menace and to create new levels for Rise of the Triad. It is also possible to edit the levels of Commander Keen 4-6, but this is a bit harder to [http://www.keenmodding.org/viewtopic.php?t=899 set up].

Older versions can be found in [http://web.archive.org/web/20060522213934/http://www.rome.ro/downloads/ddici/ddici.zip Dangerous Dave in Copyright Infringement] and in the source code of the SNES version of [https://github.com/MatthewCallis/NOAH3D/tree/master/NOAH3D/MAPS Super 3-D Noah's Ark].

[[Category:id Software]]

Keen Dreams level Format

2022-02-05T16:31:05Z

Frenkel: /* Ted5 */ fix font

The map data for the [[Commander Keen Dreams]] series of games, (Including [[Dangerous Dave 3]] and [[Dangerous Dave 4]]) is stored in the <tt>KDREAMS.MAP</tt>(Shareware) or <tt>GAMEMAPS.MAP</tt>(Registered version) files. This stores all the maps of the levels used in the game. The file is read and decompressed using data stored in the <tt>MAPHEAD.KDR</tt> and <tt>MAPDICT.KDR</tt> files.

In the main the map format is identical to the Keen 4-6 [[GameMaps Format]] except that the map data for each level is compressed using [[Huffman Compression]] rather than carmackization. This works identically to the compression for other Keen Dreams files, such as the audio and graphics. The <tt>MAPDICT.KDR</tt> file is located at the following addresses:

Keen Dreams: $2B847
Dave 3: $2C7BD
Dave 4: $2A015

== Ted5 ==

Keen Dreams levels can be edited by the [[TED5]] utility, providing they are decompressed to the correct files, much like the usual [[GameMaps Format]] files, the difference being that TED5 cannot re-compress the altered files to a usable form, meaning the maps must be recompressed every time changes are completed.

There is also the issue of filenames; due to a programming quirk only v1.13 of Keen Dreams is moddable, and this uses filenames that are at odds with TED5, as well as the modding utilities not producing correctly named files. (Modkeen outputs <tt>EGAHEAD.Dreams</tt> instead of <tt>EGAHEAD.KDR</tt> for example.)

The simplest way to solve this is as follows:

* The creation of <tt>EGAHEAD.CK7</tt> for TED5 (Default Dreams EGAHEAD uses 4-byte, not 3-byte pointers)
* The <tt>MAPDICT.KDR</tt> file extracted and replaced with one that does not cause compression. This avoids having to compress levels each time changes are made
* The extraction of <tt>MAPTHEAD.CK7</tt> for TED5
* <tt>KDREAMS.MAP</tt> decompressed to <tt>MAPTEMP.CK7</tt>

When changes are to be saved TED5 can be edited and the following steps taken:

* <tt>MAPTEMP.CK7</tt> 'compressed' to <tt>KDREAMS.MAP</tt> with a 'nonfunctional' <tt>MAPDICT.KDR</tt> file this involves nothing more than adding a dword to the start of each plane of each level's data giving the size of the plane
* Converting <tt>MAPTHEAD.CK7</tt> to <tt>MAPHEAD.KDR</tt> (For patching and running altered levels)

== Utilities ==

There exists a utility to make Keen Dreams and Dangerous Dave levels compatible with TED5. It comes with all the required files and can be found on http://keenmodding.org/

== Notes ==

This format was reverse engineered by Lemm and Levellass (Mostly Lemm).

Talk:Inverse Frequency Sound format

2022-01-29T21:29:30Z

Frenkel: the official source code might answer questions

How does this sound format handle sounds who's period is zero (frequency is infinite)? This causes a divide-by-zero error when actually computed.
[[User:Videogamer555|Videogamer555]] ([[User talk:Videogamer555|talk]]) 13:27, 29 January 2022 (GMT)

:Does the official source code answer your question? https://github.com/CatacombGames/Catacomb/blob/master/SOUNDLIB.ASM#L288 https://github.com/CatacombGames/TheCatacomb/blob/master/PCRLIB_A.ASM#L514 https://github.com/FlatRockSoft/Hovertank3D/blob/master/IDASM.ASM#L654 [[User:Frenkel|Frenkel]] ([[User talk:Frenkel|talk]]) 21:29, 29 January 2022 (GMT)

== There appears to be a discrepency here. ==

In the Sound Definitions section, in the table it says "UINT8 rate Defines the update rate of the timer generating the sound interrupt. Usually set to 8. "

However in the paragraph right after that table, it says "The PC Speaker is updated at a rate of usually 140 Hz". So which is it? Is it 8Hz or 140Hz update rate? Or does the 8 mean something else? Does it scale the update rate, where 140Hz is represented by that field containing the number 8, so each increment of 1 in that field changes the PC speaker's update rate by 17.5Hz, with 0 meaning never update the PC speaker?

[[User:Videogamer555|Videogamer555]] ([[User talk:Videogamer555|talk]]) 14:07, 29 January 2022 (GMT)

Bio Menace

2022-01-16T15:33:28Z

Frenkel: /* Music */ Biomenace -> Bio Menace, Keen -> Bio Menace

{{Game Infobox
| Levels = Edit
| Tiles = Edit
| Sprites = Edit
| Fullscreen = Edit
| Sound = Edit
| Music = Edit
| Text = Edit
| Story = Edit
| Interface = Edit
}}
'''Bio Menace''' (working title: '''Bio Hazard''') is a series of three games known simply as Bio Menace 1, 2 and 3. They use a slightly altered version of the [[Commander Keen 4-6]] engine, so the file formats used are almost identical.

The game follows the adventures of Snake Logan, a top secret operative at the CIA, who takes on missions others would see as suicidal, as he battles hordes of strange mutant monsters that have suddenly appeared and are taking over cities. The goals of the game vary, from rescuing trapped prisoners to destroying an evil computer. Notably, in the second game, if you do not get the portable nuclear device in one of the levels, the game becomes unwinnable and you are treated to the story of Snake's eventual death.

{{BeginFileFormatTools|Type=game}}
{{FileFormatTool
| Name = [[keenwiki:Abiathar|Abiathar]]
| Platform = Windows
| grp = N/A
| map = Edit
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
| notes = Offers templates for Bio Menace projects
}}
{{FileFormatTool
| Name = [[TED5]]
| Platform = DOS GUI
| grp = N/A
| map = Edit
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
| notes = Must be [http://people.inf.elte.hu/szgrahi/bmenace_mod.zip configured to work with Bio Menace]
}}
{{FileFormatTool
| Name = [[Wombat]]
| Platform = Windows
| grp = N/A
| map = Read
| gfx = Read
| mus = Read
| sfx = Read
| txt = No
| sav = No
| exe = No
| notes =
}}
{{EndFileFormatTools}}

 
== File formats ==

{|class="wikitable"
! File name !! Description
|-
| <tt>audiohed.bm* audiot.bm*</tt>
| style="background: #CCFFCC;" | Sound effects and music in [[AudioT Format]] (and within that, music in [[IMF Format]])
|-
| <tt>bmenace[123].exe</tt>
| style="background: #FFFFCC;" | Exit text screens in [[B800 Text]] format
|-
| <tt>egadict.bm* egahead.bm* egagraph.bm*</tt>
| style="background: #CCFFCC;" | Graphics, text and miscellaneous data in [[EGAGraph Format]]
|-
| <tt>gamemaps.bm* maphead.bm* maptemp.bm* mapthead.bm*</tt>
| style="background: #CCFFCC;" | Levels in [[GameMaps Format]]
|}

* Sprite behaviours are governed by data structures in the .exe, arranged in [[Keen 4-6 Action Format]]

== Music ==

=== AudioT Format Details ===
Bio Menace uses the uncompressed version of the [[AudioT Format]] to store music and sound. The main audio file for each game, the AUDIOT.xxx file, is called AUDIOT.BMx, where x is the number of the game (1, 2 or 3). For example, the file for Bio Menace 2 is AUDIO.BM2. The secondary files needed for this format, the AUDIOHED.BMx are external.

=== Levels Songs Assignment ===
There is a place inside the executables too, where each level in the game is assigned a song from the AUDIOT.BMx file. From that addresses, the following bytes indicate the song for each level. Every 2 bytes is a value corresponding to a level. The first 2 bytes correspond to level 0; the next 2 bytes correspond to level 1; and so on. Each 2-byte value is an integer corresponding to the song number used in that level, starting from $00 $00, and going up to $00 $01, and so on. This numbers refer to the order the songs are in the AUDIO.BMx file; $00 $00 is the first one, $00 $01 is the second one, and so on.

It is notable that Bio Menace has many more songs in it than the Keen 4-6 games upon which it was based.

== Obtaining the game ==

The full version of this game [http://www.3drealms.com/news/2005/12/bio_menace_released_as_freewar.html has been released as freeware].

* Three different versions are available from [http://www.classicdosgames.com/apogee.html Classic DOS Games]

[[Category:Apogee]]
[[Category:Sidescroller]]
[[Category:Freeware]]

Talk:Huffman Compression

2021-09-17T10:42:23Z

Frenkel: Huffman is easy

== Constructing an optimal tree ==

Wikipedia documents a different way to construct an optimal tree:
Sort the list of elements by frequency. Remove the two elements with the lowest frequency from the list. Create a new tree for these two elements, add the frequencies together and put the tree back in the sorted list of elements. Repeat until you have 1 element in the list.
Following this algorithm, I've constructed the following tree for the "She sells seashells by the sea shore." example:
<pre>
__[Root]_____
/ \
___|__ ___|___
/ \ __/_ \
/ \ / \ / \ s
e _ / \ h l / \
/ \ a / \ / \
/ \ S y . r t
b o
</pre>
's' takes 2 bits to store, 'e', '_', 'h' an 'l' take 3 bits, 'a' 4 bits, 'S', 'y', '.', 'r' and 't' 5 bits, and 'b' and 'o' take 6 bits. "She sells seashells by the sea shore." takes 122 bits to store. Using the tree on this page it takes 124 bits. So my tree is more "optimal" or is there something wrong with my calculations? [[User:Frenkel|Frenkel]] ([[User talk:Frenkel|talk]]) 11:13, 10 September 2021 (GMT)
: That honestly seems more like a question for a place like StackOverflow or Xentax. Not sure we got many lzw/huffman experts here. I personally never managed to wrap my head around it. -[[User:Nyerguds|Nyerguds]] ([[User talk:Nyerguds|talk]]) 11:23, 15 September 2021 (GMT)
:: Huffman is actually pretty easy, once you've written your own decompressor and compressor. :) [[User:Frenkel|Frenkel]] ([[User talk:Frenkel|talk]]) 10:42, 17 September 2021 (GMT)

Talk:Huffman Compression

2021-09-10T11:13:38Z

Frenkel: /* Constructing an optimal tree */ new section

EGAGraph Format

2021-08-27T18:55:13Z

Frenkel: /* Sprite table */ shifts added: 8 words -> 9 words

{{Tileset Infobox
| ImageNativeWidth = Y
| Hardware1 = VGA
| Palette = External
| Names = N
| HasTransparency = Y
| Metadata = None
| Subtilesets = N
| Compressed = Y
| Hidden = N
| Games =
{{Game|Catacomb 3-D}}
{{Game|Catacomb Abyss}}
{{Game|Commander Keen 4-6}}
{{Game|Commander Keen Dreams}}
{{Game|Dangerous Dave 3}}
}}

'''EGAGraph''', short for 'EGA graphics library' is the format used to store graphics, demos, fonts, game texts and more in many early [[:Category:Id Software|id Software]] games.

The basic format is that of a number of [[Huffman Compression]] compressed sub-files (Chunks) stored in a similar manner to the [[AudioT Format]]. Like this format it has three main files, <tt>EGAGRAPH</tt>, <tt>EGAHEAD</tt>and <tt>EGADICT</tt>.

It is notable that while the <tt>EGAHEAD</tt> and <tt>EGADICT</tt> are stored in the game executable, they need to be extracted for [[TED5]] to edit levels.

This article may contain errors as some formats have not been worked out completely.

== EGA Head (EGAHEAD.xxx) ==

There are two versions of this format. The first version, used in [[Commander Keen Dreams]], [[Dangerous Dave 3]] and [[Dangerous Dave 4]], is an array of 4-byte little-endian values. The second version, used in all later EGA games, is an array of 3-byte unsigned little-endian values.

This header file may be present as an external file (eg. [[Bio Menace]]), or it may be included in the EXE file (eg. [[Catacomb 3-D]]). The last entry in the header is always the size of the EGAGRAPH.xxx file, and the first entry in the header is always 00 00 00. To find the end, you can search for filesize(EGAGRAPH.xxx) as a 3-byte (little-endian) value in the EXE. Then to find the start, go back 3 bytes at a time until you get to 00 000 00. Or use the fact that entries always get smaller as you go back, unless the entry is $FFFFFF.

In [[Catacomb 3-D]] v1.00 <tt>EGAHEAD.C3D</tt> is at $1BFD0 from the start of the decompressed ([[unlzexe]]) EXE file, and is 1437 bytes long, or 479 3-byte entries (for 478 chunks). It is then followed by 3 zero bytes (padding to multiple of 16?) 00 00 00, then the <tt>MAPHEAD.C3D</tt>.

In [[Catacomb Abyss]] v1.13 <tt>EGAHEAD.ABS</tt> is at $1BDB0 from the start of the decompressed ([[unlzexe]]) EXE file, and 1881 bytes long and has 626 chunks.

In [[Catacomb Apocalypse]] v1.00b <tt>EGAHEAD.APC</tt> is at $1E270 from the start of the decompressed ([[unlzexe]]) EXE file, and 2049 bytes long and has 682 chunks.

This header file stores the offsets (relative to the start of the <tt>EGAGRAPH</tt> file) for each sub file. The format is trivial, in that the header file is simply an array of 3 or 4 byte variables. (Each variable is a "slot", as the game refers to files by index.) Most games use the more compact 3-byte variables, since the <tt>EGAGRAPH</tt> file is never larger than $FFFFFF. However games based on older engines, notably [[Commander Keen Dreams]], [[Dangerous Dave 3]] and [[Dangerous Dave 4]], use 4-byte vales as these are easier to deal with.

It is important to note that not every 'slot' will be in use. Tiles especially if blank (All black) will be considered 'empty' and not worth adding to the file. (A blank 16x16 tile takes up 12 bytes of space if compressed, and there can be hundreds.) There are two ways of dealing with this; by default the games set all empty slot headers to -1, but many programs compress the graphics anyway and use a normal header value for them.

The last offset in the file will be an offset to the end of the main <tt>EGAGRAPH</tt> file. (So this should be ignored when reading the file to prevent a zero-byte file appearing last.) The total size of the <tt>EGAHEAD</tt> divided by 3 (Or 4) will also give the number of 'slots' the game uses. This varies, but is usually about 10,000.

Unlike [[AudioT Format]] files, <tt>EGAGRAPH</tt> is always compressed. However the header and dictionary may be external (E.g [[Bio Menace]])

== Dictionary (EGADICT.xxx) ==

The same [[Huffman Compression]] scheme used elsewhere in the [[Commander Keen]] series is used. When reading compressed chunks out of the <tt>EGAGRAPH</tt> file, the first four bytes located at the <tt>EGAHEAD</tt> offset are a UINT32LE specifying the file's decompressed size (which is required for the decompression algorithm.) The compressed data then follows, EXCEPT for 16x16 masked and unmasked tiles. Since these all have a similar decompressed size (128 bytes for unmasked, 256 bytes for masked) it is a waste of space to include these (Since tiles make up the bulk of graphics slots.) The decompressed size is hard coded, as are the start and finish of the unmasked and masked tile slots.

Note that the <tt>EGADICT</tt> file is not often obvious, usually being embedded in the main exe file. It is possible to locate it by looking for the string <tt>$FD $01 $00 $00 $00 $00</tt>, which appears at the end of nearly all Huffman dictionaries. They are the last 6 bytes out of 1024 (256*2*2), so add 6 and subtract 1024 to get the start (pointer to the head node).

Executables usually contain two or more dictionaries, but the <tt>EGADICT</tt> is usually '''the second one''', except in the case of early games like Keen Dreams, where it is the first of THREE. (A simple check of whether it decompresses the data sensibly works.)

In [[Catacomb 3-D]] <tt>EGADICT.C3D</tt> is at offset $24464 from the start of the decompressed CAT3D.EXE, which is the second Huffman dictionary and comes immediately after the first Huffman Dictionary.

In [[Catacomb Abyss]] v1.13 <tt>EGADICT.ABS</tt> is at offset $2734C from the start of the decompressed CATABYSS.EXE, which is the second Huffman dictionary.

In [[Catacomb Apocalypse]] v1.00b <tt>EGADICT.APC</tt> is at offset $26B24 from the start of the decompressed CATAPOC.EXE, which is the second Huffman dictionary.

== Main file (EGAGRAPH.xxx) ==

This file is simply an array of data files. Each file starts at the offset specified in the <tt>EGAHEAD</tt> file, and as there are no filenames each file is referred to by its index/slot number. Slots containing dummy values in the header are treated as if they don't exist in the <tt>EGAGRAPH</tt> file. Each file within the <tt>EGAGRAPH</tt> file is individually compressed. A file can be read by opening the <tt>EGAGRAPH</tt> file, seeking to the offset specified in the <tt>EGAHEAD</tt> file, reading a UINT32LE for the decompressed file size, and then decompressing the data from that point onwards using standard Huffman decompression techniques.

Note that in early games such as Keen Dreams, the <tt>EGAGRAPH</tt> file may have another name. (Such as <tt>KDREAM.EGA</tt> in that case.) in which case it is always the largest non-executable file.

=== Chunks ===

Each sub file or chunk is a separate graphic, ordered in the <tt>EGAGRAPH</tt> file in a specific way, much again like the [[AudioT Format]]. Chunks are labeled starting at 0. The game executable is hard coded for the start and finish of various chunk types. For example, Keen 4 has chunks 124-520 as sprites and will treat any chunk between these two numbers as a sprite. (Note that the game refers to chunk number, not sprite number.) The usual order of chunks is:

Picture table
Masked picture table
Sprite table
Fonts
Pictures (Unmasked bitmaps)
Masked pictures
8x8 unmasked tiles (Single chunk)
8x8 masked tiles (Single chunk)
16x16 unmasked tiles
16x16 masked tiles
32x32 unmasked tiles (Optional)
32x32 masked tiles (Optional)
Misc graphics (Optional)
Game texts
Demo files (Optional)
Misc data (Optional)

== Chunk formats ==

When compressed each chunk consists of a dword giving the decompressed size followed by the compressed data.

=== Picture table ===

Always present and always the first chunk, the picture table is 4 * numpics bytes long, consisting of two words for each picture (Width\8, Height) used when displaying picture chunks.

Divide the decompressed size by 4 to get numpics.

=== Masked picture table ===

Always present and always the second chunk, the picture table is 4 * numpics bytes long, consisting of two words for each picture (Width\8, Height) used when displaying masked picture chunks. This table is often quite small.

=== Sprite table ===

Always present and always the third chunk, the sprite table is 18 * numspr bytes long, consisting of nine words for each sprite image (width\8, height, x offset, y offset, clipping rectangle left, top, right and bottom, and shifts; all in that order.) used when displaying sprite chunks. This is what Modkeen exports as its notoriously hard to use xSPRITES.txt file.

=== Fonts ===

Always present and always starting at the fourth chunk. (Chunk 3!) Each chunk is a single monochrome font, containing all the entries from 0-255 for that font. Each 'letter' is stored separately and consecutively. A game will have at least one, and usually 3 fonts. The format is version two of [[EGA Font format]]

Fonts are used in the game for game texts. They can be stretched or colored and are always transparent, meaning they look strange when not over a single-color background.

=== Pictures (Bitmaps) ===

These follow game fonts. You need to know how many fonts there are before it to know how what chunk number the first picture is (3+NumFonts).

Bitmaps are stored as standard [[Raw EGA data]], the size of each plane being the decompressed chunk size \ 4. In order to be displayed properly these need information from chunk 0, the picture table. Note that unlike fonts, data does not wrap, so a 4x4 sprite will consist of four planes of four bytes in size, the same as an 8x4 sprite.

Pictures are used for things such as title screens or pictures in game texts. Most of the main menu will consist of pictures. They are also used for the wall textures and sprites in EGA FPS games like [[Catacomb 3-D]], in which case the wall textures usually come near the end of the picture list.

The number of picture chunks is given in chunk 0, the picture table.

=== Masked pictures (Masked bitmaps) ===

These follow Pictures. You need to know how many fonts there are, to know how what chunk number the first Masked picture is (3+NumFonts+numpics).

These are identical to the picture chunks in every respect, except being masked, they consist of five EGA planes, not four. Most games have only one or two of them. They need information from chunk 1, the masked picture table, to be displayed correctly.

The number of Masked pictures is given in Chunk 1.

=== Sprites ===

The first Sprite chunk is at 3+numfonts+numpics+numMaskedPics.

Sprites are exactly identical to masked pictures in format except the game cannot stretch or warp them. Most games use these for enemy, player or item graphics during gameplay. They need information from chunk 2, the sprite table, both to display correctly and to interact correctly, something more complex than masked pictures.

There are usually several hundred sprite chunks, although that's not always the case, as [[Catacomb 3-D]] only has 3 sprite chunks (used for the PaddleWar game), and [[Catacomb Abyss]] has only one (used for the in-game radar). The number of sprite chunks is given in chunk 2.

=== 8x8 tiles ===

8x8 tiles are used by most games in status windows or foe the borders of message windows in-game. (And occasionally by TED5 to display levels.) There are thus not many of them. ALL the masked or unmasked tiles are one single chunk stored as four and five plane [[Raw EGA data]] respectively. The number of 8x8 unmasked and masked tiles is hard-coded into the executable, but can be worked out by dividing the decompressed chunk size by 32 and 40 (The size of one tile's data) respectively.

=== 16x16 and 32x32 tiles ===

32x32 tiles are optional and rarely used. 16x16 tiles are only occasionally absent and for most games make up the bulk of graphics. There are usually several thousand entries. Both come in masked and unmasked kinds, just like 8x8 tiles.

These chunks have notable differences. Each tile is an individual chunk and stored as four or five plane [[Raw EGA data]] with a plane size of 128 (16x16) or 512 (32x32). These chunks do NOT have a dword specifying their decompressed size as this is hard-coded into the executable as a space saving measure. (As is the start and finish of unmasked and masked tile chunks.) This can cause problems for editing programs.

Tiles make up the bulk of 2D game levels but are seldom seen elsewhere.

=== Misc graphics ===

Sometimes following tile graphics are miscellaneous graphics, that cannot be handled by the other chunk types. For example, Keen 4-6 has two misc graphics files used for the 'COMMANDER KEEN terminator text' intro. These graphics usually have unique formats that fit their function and few have been investigated.

==== Keen 4-6 Intro Bitmaps ====

This is the text that displays after the 'Ready, press any key' screen at Keen startup. It is composed of a monochrome bitmap that is scrolled across the screen and distorted for special effects. When displayed it is transparent, with a special palette so it is not black-and-white. It consists of a header followed by RLE compressed monochrome data.

HEADER:
0 2 Img height Height of the image in pixels
2 2 Img width Width of the image in pixels
4 2x Line point Pointers to line 1,2,3..etc of data. There will be [Img height] of
these, each 2 bytes long. The first pointer will have the value
(2 * [Img height] + 4)
+2 ? RLE data RLE-WM compressed data

DATA:
0 2 Black run Number of black pixels to write
2 2 Not-blk run Number of not-black pixels to write
4 2 Black run....
...
..
.
? 2 End $FFFF; end of row.

=== Game texts ===

Also known as ANSII chunks, these are used by the game for things like help screens, and have their own format. In the main they are simply text documents, interspersed with various commands to make things happen. Each file is divided up into a number of 'pages' which are moved between by pressing the up/down arrows. Pages can also have action sequences (Repeated each time the page is moved to, you cannot leave a page until the sequence finishes.)

^P First command in every file. Defines a page start
^E Ends the file
^Cx Change font color to $x until next page or ^C command
^Gx,y,z Display (unmasked) picture chunk z at location x,y (in pixels)
^Tx,y,z,t Display picture chunk z at x,y for z clicks of time
^Bx,y,z,t,b Fill a width-by-height-pixel rectangle at pixel location x,y (for z clicks of time?) with color $x
^Lx,y Start text alignment at pixel location x,y.

=== Demo files ===

These files, which can be recorded in several games using the 'demo cheat' consist of a series of commands that are played back when a demo is run ingame. (The game is also 'derandomized' during recording so all demo playbacks will be predictable.)

The format is quite simple; consisting of two words and a number of byte pairs. The first two bytes store the number of the level to load for the demo, the next two store the length of data to load\play (After this limit is reached the demo will end, whether or not there is any more data to read.) The remaining byte pairs each encode a time and a keypress. The following values are known:

01 Left
04 Up
05 Nothing
06 Down
09 Right
15 Ctrl
25 Alt

=== Misc files ===

The last few chunks are demo files and occasionally miscellaneous data. Demo file formats are currently unknown but can be recorded using the demo cheat. They contain the level number and difficulty followed by a series of key commands.

== Utilities ==

* [[KeenWiki:ModKeen|ModKeen]] (DOS) and [[KeenWiki:LModKeen|LModKeen]] (Linux/Windows) can be used to modify graphics and text stored in EGAGRAPH.CKx for the Commander Keen [[KeenWiki:Goodbye Galaxy|Goodbye Galaxy]] trilogy.
* WDC (Windows) can be used to view or modify the graphics in most EGAGRAPH games, including [[Catacomb 3-D]], [[Catacomb Abyss]] and [[Commander Keen 4-6]].

ProGraphx Toolbox tileset format

2021-07-03T20:08:51Z

Frenkel: added Operation: Airlift

{{Tileset Infobox
| ImageNativeWidth = Y
| Hardware1 = EGA
| MaxTiles = 255 per subtileset, unlimited subtilesets
| Palette = Default EGA
| Names = N
| TileMinSize = 0×0
| TileMaxSize = 2040×255
| NumPlanes = 5
| PlaneArrangement = [[Byte-planar EGA]]
| HasTransparency = Y
| HasHitmap = N
| Metadata = None
| Subtilesets = Y
| Compressed = N
| Hidden = N
| Games =
{{Game|Operation: Airlift}}
{{Game|Dark Ages}}
{{Game|Duke Nukem}}
{{Game|Crystal Caves}}
{{Game|FBI Fred}}
{{Game|Secret Agent}}
}}
This file format is used by the ProGraphx Toolbox to store images used for map tiles in a game.
__TOC__
The ProGraphx Toolbox, written by Peder Jungck, is used by the following games:

* [[Operation: Airlift]] - <tt>AIRLIFT.EXE</tt> contains the string ''Version 1.0 EGA/VGAProGraphx EGA/VGA Toolbox''
* [[Dark Ages]] - <tt>DA3.EXE</tt> contains the string ''Version 1.0 EGA/VGAProGraphx EGA/VGA Toolbox'' (DA1.EXE and DA2.EXE contain gibberish)
* [[Duke Nukem]] - <tt>DN1.EXE</tt> contains the string ''Version 1.0 EGA/VGAProGraphx EGA/VGA Toolbox''
* [[Crystal Caves]] - <tt>CC1.EXE</tt> contains the string ''Version 1.5 320x200 PAN EGA/VGAProGraphx EGA/VGA Toolbox''
* [[FBI Fred]] - <tt>FBIFRED.EXE</tt> contains the string ''Version 1.5 EGA/VGAProGraphx EGA/VGA Toolbox (c) 1990''
* [[Secret Agent]] - <tt>SAM1.EXE</tt> contains the string ''ProGraphx EGA/VGA Toolbox Version 2.0 320x200 EGA/VGA Copyright 1991 by Peder Jungck''

== File format ==

The file consists of a number of tilesets one after the other. Each tileset is made up of a collection of small images (usually 8×8 or 16×16, but the format supports up to 2040×255.)

In '''Secret Agent''' the files are encrypted with [[Secret Agent encryption]]. In the other games there is no encryption.

=== Signature ===

There is no signature, however careful processing of the header can be used to check whether the last tileset ends at exactly the end of the file (allowing for padding in some versions of the format.) If not, it is unlikely to be in this format. Be careful that files with zero values don't cause an endless loop when calculating offsets.

=== Header ===

Each tileset begins with the following header.

{|class="wikitable"
!Data type!!Description
|-
|[[BYTE]] count||Number of sprites in this chunk (50 in most cases)
|-
|[[BYTE]] width||Sprite width, in bytes (not in pixels)
|-
|[[BYTE]] height||Sprite height, in pixels
|}

The image data for the tileset follows the header. After the image data either the next header begins, or the file ends.

'''Operation: Airlift:''' Each tileset is padded up to the nearest multiple of 128 bytes.

'''Dark Ages:''' Each tileset is padded up to 8064 bytes, except for the last tileset which contains 2 sprites and is padded up to 384 bytes.

'''Duke Nukem:''' Each tileset is padded up to 8064 bytes, except for <tt>NUMBERS.DN?</tt> (7186 bytes) and the backdrop files (<tt>DROP*.DN?</tt>) which have no padding. The backdrop files also have all three header bytes set to zero. For these files, the number of sprites is always 130, the width is always 2 (bytes) and the height is always 16.

'''Crystal Caves:''' The file ends after the last tile's image data, there is no padding.

'''FBI Fred:''' Each tileset is padded up to 8064 bytes, except for the last tileset which contains 23 sprites and is padded up to 3712 bytes.

'''Secret Agent:''' Each tileset is padded up to 8064 bytes for 16×16 sprite files (<tt>SAM?01.GFX</tt>), and 2048 bytes for 8×8 sprite files (<tt>SAM?02.GFX</tt>).

For those files with padding at the end, be careful not to interpret the padding as the presence of more tiles.

=== Image data ===

The image data is in [[Byte-planar EGA]] format with five planes, so reading <tt>width × height × 5</tt> bytes will read in enough data for a single image (one tile.) This value multiplied by the number of tiles (<tt>count</tt>) will yield the number of bytes in the entire tileset, which can be used to skip directly to the next tileset in the file (if any.)

The first byte in each tile's data is the transparency plane (1 == opaque, 0 == transparent), and the following four bytes/planes are blue, green, red and intensity. The MSB in each byte (10000000) is the first/left-most pixel, and the eighth pixel is the LSB (00000001). This means if the bits are processed in a loop, as the X direction increases to the right (0, 1, 2) the bit value decreases (0x80, 0x40, 0x20.)

== Notes ==

* For at least '''Duke Nukem''', the game seems to ignore the header of ''all'' files in this format. You can set the entire header of any tileset file to zero values and the game will still load them properly. This also means that you cannot use larger tilesets without modifying the executable.

== Credits ==

This file format has been reverse engineered by many people over the years. [[User:K1n9_Duk3|K1n9_Duk3]] discovered that Duke Nukem uses this format. [[User:Frenkel|Frenkel]] identified the similarities amongst all the games using the file format, and realised they all use the ProGraphx Toolbox. 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!)

Talk:God of Thunder/Cheats

2020-04-11T19:25:10Z

Frenkel: God of Thunder source code is available

Now that the [https://github.com/SheridanR/god-of-thunder source code of God of Thunder is released], we can finally find out what the K button does. [[User:Frenkel|Frenkel]] ([[User talk:Frenkel|talk]]) 19:25, 11 April 2020 (UTC)

Commander Keen 1-3 Level format

2020-03-27T20:29:44Z

Frenkel: ID Software -> id Software

{{Map Infobox
| Type = 2D tile-based
| Layers = 2
| Viewport = 320×200
| Games =
{{Game|Commander Keen 1-3}}
{{Game|Dangerous Dave in Copyright Infringement}}
{{Game|Dangerous Dave 2}}
{{Game|Shadow Knights}}
{{Game|Slordax}}
}}

The [[Commander Keen 1-3]] level format was widely used in early [[:Category:id Software|id Software]] games, usually stored in the files <tt>LEVELxx.*</tt> (Usually with 8 or 16 levels.) The level files are usually compressed with [[RLEW compression]], though earlier games omit this. The file is composed of three sections, the header, and the tile and sprite planes.

== Compressed ==

The compressed levels start with a dword giving the size of the decompressed level in bytes (always divisible by four) followed by the standard level data in RLEW compressed form. The rest of this page assumes decompressed data and uses offsets relative to the start of Level Data.

{|class=wikitable
! Offset !! Length !! Name !! Note
|-
|0 || 4||Decompressed Size||always divisible by four
|-
|4 || ||Level Data ||(see below)
|}

== Header ==

The level header is 32 bytes long in total. Most of the header is (or was) used by TED v1.5 to load the level and its associated graphics and is not used by games per se. These fields can be left blank and nobody will care, since the original TED is long gone.

The plane size is interesting, since it has to be divisible by 16 because of how some game engines work. It is how many tiles are in each plane.

{|class=wikitable
! Offset !! Length !! Name !! Note
|-
| 0|| 2||Level Width ||
|-
| 2|| 2||Level Height ||
|-
| 4|| 2||Number of Planes ||always 2
|-
| 6|| 4||Blank ||appears to always be zero
|-
|10|| 4||TED Variables ||ignored
|-
|14|| 2||Plane Size ||2(h * w) rounded to the next highest multiple of 16
|-
|16||16||Unknown ||ignored
|}

== Sprite and tile planes ==

Each plane is an array of words, padded to plane size bytes with nulls. Each word is a tile, running from left to right, top to bottom. THe first plane is tiles, the second is sprites.

{|class=wikitable
! Offset !! Length !! Name
|-
|32 ||Plane Size||Tiles
|-
|32 + Plane Size||Plane Size||Sprites
|}

==Notes==

This format has been reverse engineered several times, always by the [[Commander Keen 1-3]] modding community.

Dangerous Dave in Copyright Infringement appears to be the first game to use this format and has it uncompressed.

Dangerous Dave in Copyright Infringement

2020-03-27T20:25:55Z

Frenkel: ID Software -> id Software

{{Stub}}

{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}

Dangerous Dave in Copyright Infringement (DDiCI) is a small and incomplete game that led to the development of the [[Commander Keen 1-3]] series. The game displays the at-the-time revolutionary smooth scrolling EGA graphics and is named after the fact that it involved the protagonist's graphics from [[Dangerous Dave]] with the tiles from Mario.

DDiCI was never completed or released as [[:Category:id Software|id Software]] developed Keen instead. However John Romero released the game, complete with TED 1.0 on his website several years later. The game is interesting to study from a historical viewpoint as it can clearly be seen how later games were based on it. The game features two playable (But not completable.) levels and the aforementioned level editor.

== File formats ==

This section lists the major file formats used in the game.

* [[Commander Keen 1-3 Level format]] - <tt>LEVELxx.DD2</tt> are game levels, slightly modified in that they are not [[RLEW compression|RLEW compressed]].
* [[DDiCI Graphics format]] a combined file containing all the game's graphics.
* [[Dave Score format]] - Scores are stored in <tt>SCORES.DD2</tt>, but not actually used.
* [[Keen 1-3 Tileinfo format]] - information about the properties of tiles are stored internally in the executable.
* [[Inverse Frequency Sound format]] - the sound file is stored internally and uses Apogees 'inverse frequency' sound format
* [[Raw EGA data#Planar|Full-screen planar EGA]] All the graphics are in this format, stored in a single file.

* Text is contained in the executable, the executable is compressed with LZ compression, and can be uncompressed with [[UNLZEXE]].

==Notes==

Although the file extension, <tt>.DD2</tt> suggests that this game would be the sequel to Dangerous Dave, the actual sequel [[Dangerous Dave 2]] was completed several years later, ironically based on the Keen 1-3 engine.

[[Category:Apogee]]
[[Category:Sidescroller]]

Wombat

2019-06-17T14:07:03Z

Frenkel: updated to version 1.0.9

{{Tool Infobox
| Platform = Windows
| Release = 24/04/2019 (1.0.9)
| Homepage = [http://szevvy.com szevvy.com]
| Download = [http://szevvy.com/download Windows x64]
| Edit1 = Extraction
}}
'''Wombat Game Tools''' (also known as '''Wombat File Tools''') is an extraction tool written by Szevvy. It allows the files, images, sounds, etc. to be examined and exported from a number of classic games.

[[User:Szevvy|Szevvy]]'s website is [http://szevvy.com/ szevvy.com], it went offline for a while, but it's working again as of 15/10/2018.

Wombat's latest version is 1.0.9 (24 April 2019)

 
== Supported games ==

<table class="wikitable" style="text-align:center">
<tr>
<td width='30%'></td>
<td>Archives</td>
<td>Graphics</td>
<td>Levels</td>
<td>Sounds</td>
<td>Music</td>
<td>Other</td>

</tr>
<tr>
<td>7 Cities of Gold ('93)</td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>Alien Carnage</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>Ancients I: Deathwatch</td>
<td></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td bgcolor='#FFF0AA'></td>
</tr>
<tr>
<td>Baron Baldric</td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>Battlechess 4000</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td bgcolor='#B0E57C'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Biomenace</td>
<td></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>Cannon Fodder</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>Captain Comic I</td>
<td></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Captain Comic II</td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Clyde's Adventure</td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Clyde's Revenge</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Commander Keen 1-3</td>
<td></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Commander Keen 4-6</td>
<td></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Commander Keen Dreams</td>
<td></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Cosmo's Cosmic Adventure</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td></td>
</tr>
<tr>
<td>Crystal Caves</td>
<td></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#B0E57C'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Dangerous Dave</td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Dangerous Dave 2</td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Dark Ages</td>
<td></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Desert Strike</td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#B0E57C'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Dig It!</td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Donald Duck's Playground</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td bgcolor='#B0E57C'></td>
</tr>
<tr>
<td>DOOM</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>Duke Nukem</td>
<td></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Duke Nukem 2</td>
<td></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td></td>
</tr>
<tr>
<td>Duke Nukem 3D</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>Dune 2</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFF0AA'></td>
</tr>
<tr>
<td>Electranoid</td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Fuzzy's World of Miniature Space Golf</td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Gateworld</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>God of Thunder</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Gold Rush!</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td bgcolor='#B0E57C'></td>
</tr>
<tr>
<td>Halloween Harry</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>Heroes of Might and Magic I</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>Heroes of Might and Magic II</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>Hocus Pocus</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>Jazz Jackrabbit</td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>Jill of the Jungle</td>
<td></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Jump 'n' Bump</td>
<td></td>
<td bgcolor='#B0E57C'></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Jungle Strike</td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#B0E57C'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>King's Quest</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td bgcolor='#B0E57C'></td>
</tr>
<tr>
<td>King's Quest II: Romancing the Throne</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td bgcolor='#B0E57C'></td>
</tr>
<tr>
<td>King's Quest III: To Heir Is Human</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td bgcolor='#B0E57C'></td>
</tr>
<tr>
<td>King's Quest IV: The Perils of Rosella</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td bgcolor='#B0E57C'></td>
</tr>
<tr>
<td>Laser Light</td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Leisure Suite Larry</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td bgcolor='#B0E57C'></td>
</tr>
<tr>
<td>Major Stryker</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td></td>
</tr>
<tr>
<td>Manhunter</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td bgcolor='#B0E57C'></td>
</tr>
<tr>
<td>Manhunter 2: San Francisco</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td bgcolor='#B0E57C'></td>
</tr>
<tr>
<td>Math Rescue</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>Mixed-Up Mother Goose</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td bgcolor='#B0E57C'></td>
</tr>
<tr>
<td>Monster Bash</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td></td>
</tr>
<tr>
<td>Mystic Towers</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>Nitemare 3D (Windows)</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>One Must Fall 2097</td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>Oregon Trail</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Police Quest: In Pursuit of the Death Angel</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td bgcolor='#B0E57C'></td>
</tr>
<tr>
<td>Prehistorik</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Secret Agent</td>
<td></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#B0E57C'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Shadow Knights</td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Simcity 2000</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>Sink or Swim</td>
<td></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Smurfs</td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Space Quest: The Sarien Encounter</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td bgcolor='#B0E57C'></td>
</tr>
<tr>
<td>Space Quest II: Vohaul's Revenge</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td bgcolor='#B0E57C'></td>
</tr>
<tr>
<td>Star Goose</td>
<td></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Stargunner</td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>Syndicate</td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>The Black Cauldron</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td></td>
<td bgcolor='#B0E57C'></td>
</tr>
<tr>
<td>The Lion King</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>Traffic Dept 2192</td>
<td></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Tyrian</td>
<td></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>Wacky Wheels</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>Wolfenstein 3D</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>Word Rescue</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
</tr>
<tr>
<td>Xargon</td>
<td></td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Xatax</td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Zombie Wars</td>
<td bgcolor='#B0E57C'></td>
<td bgcolor='#FFF0AA'></td>
<td bgcolor='#FFAEAE'></td>
<td bgcolor='#FFAEAE'></td>
<td></td>
<td></td>
</tr>

</table>

Inverse Frequency Sound format

2017-11-22T20:07:01Z

Frenkel: Added Space Pizza (and Catacomb II)

{{Sound Infobox
| Type = PC Speaker
| Count = 65,535
| Rate = 18 - 144 Hz
| NumChannels = 1
| BitsPerSample = 16
| Compressed = N
| Tags = Names
| Games =
{{Game|Catacomb}}
{{Game|Catacomb II}}
{{Game|Commander Keen 1-3}}
{{Game|Cosmo's Cosmic Adventures}}
{{Game|Dangerous Dave}}
{{Game|Dangerous Dave in Copyright Infringement}}
{{Game|Dangerous Dave 2}}
{{Game|Duke Nukem}}
{{Game|Duke Nukem II}}
{{Game|Hovertank 3-D}}
{{Game|Math Rescue}}
{{Game|Major Stryker}}
{{Game|Monster Bash}}
{{Game|Paragon}} 
{{Game|Pickle Wars}}
{{Game|Realms of Chaos}} 
{{Game|Rescue Rover}}
{{Game|Shadow Knights}}
{{Game|Slordax}}
{{Game|Space Chase}}
{{Game|Space Pizza}}
{{Game|Word Rescue}}
{{Game|Xenopods}}
}}

The '''Inverse Frequency Sound format''' is the format used by Apogee/id Software in many of their games for the PC sounds. It is named because the bulk of the data is stored as 'inverse frequency' values (the higher the value, the lower the tone it produces.) Most commonly this is stored in a <tt>SOUNDS.xxx</tt> file, though it may also be stored internally in the game executable.

Later games, such as [[Wolfenstein 3-D]] use a modified form of this for their (less important) PC speaker and Adlib sounds.

== File format ==

The file is divided into three sections, 16 bytes of header, a list of sound names and the actual sound data. The start of the sound data should thus be <code>(count + 1) * 16</code> bytes from the file start.

=== Header ===

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[char]][4] || signature || "SND" + terminating null. Indicates the start of a sound file, whereas "SPK" + $00 indicates the start of the older 'speaker' format, which has very few differences. "SSE" + terminating null in [[Space Pizza]].
|-
| [[UINT16LE]] || size || Size of file
|-
| [[UINT16LE]] || unknown || Usually 0x003C, but doesn't appear to do anything.
|-
| [[UINT16LE]] || count || Number of sounds. For SPK files this is blank as the number of sounds is always 63.
|-
| [[BYTE]][6] || pad || Nulls to pad structure up to 16 bytes.
|}

=== Sound definitions ===

This structure is repeated once per sound.

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT16LE]] || offset || Offset of the sound from the beginning of the file.
|-
| [[UINT8]] || priority || Whether or not sound will be interrupted by another sound if said sound starts playing while the first is. Sounds can only be interrupted by sounds that have an equal or higher value of this. 255 is max, 0 is inadvisable.
|-
| [[UINT8]] || rate || Defines the update rate of the timer generating the sound interrupt. Usually set to 8.
|-
| [[char]][12] || name || Null-padded sound name
|}

=== Sound data ===

Sound data is divided into words (UINT16LE), with the word value being inversely proportional to the sound frequency. The sound frequency in Hz can be calculated as follows:

frequency = 1193181 / value

These word values are written directly to PIT Channel 2. The PC Speaker is updated at a rate of usually 140 Hz, so each word value is around 1/140th of a second of tone. Most files contain a few seconds of sound. The value $FFFF signals the end of a sound and most values are between the range $0100-$5000. $0000 is silence and will cause the PC Speaker to be turned off.

Depending on the implementation, the update rate might differ. [[Catacomb]] will set the speed for each sound according to the sound's rate value (rates 0 and 1 are about 18.18 Hz, rate = 8 is 140 Hz). [[Hovertank 3-D]] is hard-coded to use a fixed rate of 140 Hz and ignore each sound's rate value. [[Duke Nukem]] uses a fixed rate of 144 Hz.

Later games use a similar format for PC sounds, where the sound data is in bytes with values of 0-255. Multiplying those byte values by 60 basically converts them to word values that can be written directly to PIT Channel 2. The loss of fine-tuning can probably be attributed to the lesser role of PC sounds in the [[AudioT Format]], which has a totally different way of reading the sounds, and also contains AdLib sound effects and music.

== Notes ==

Most games load the entire file into memory and ignore all values in the header. The sound names are ignored, too. Since the games use hard-coded sound numbers (usually a 1-based index), seeking to <tt>16*soundnumber</tt> will get the sound data offset, priority and rate.

Due to a bug in the implementation, [[Duke Nukem]] uses the low byte of the sound's offset value as the priority for the sounds read from <tt>DUKE1-B.DN?</tt>.

== Credits ==

This format has been reverse engineered many times, most often in the [[Commander Keen 1-3]] fan community. Probably first by [http://web.archive.org/web/20000815235203/http://www.dd.chalmers.se/~f98anga/projects/keen/ Anders Gavare]. 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!)

Zool/Cheats

2017-11-14T20:18:00Z

Frenkel: holding down Ctrl in the demo versions allows you to fly trough walls (after entering streetlamp)

To enable cheats, press the <tt>Spacebar</tt> on the main menu to access the options screen. Then type the word <tt>stretlamp</tt> (<tt>streetlamp</tt> in the two demo versions) and press <tt>Enter</tt>.

At the copy protection screen press <tt>Spacebar</tt> to skip this screen.

The the following keys will become available during gameplay:

{|class="wikitable"
! Key !! Action
|-
| <tt>1</tt> || Enable invincibility
|-
| <tt>2</tt> || Set time to 1 (unavailable in the demo versions)
|-
| <tt>4</tt> || Lose a life
|-
| <tt>Keypad +</tt> || Skip to next level
|-
| <tt>Keypad -</tt> || Skip to previous level
|-
| <tt>Ctrl</tt> || fly/no clip mode (only available in the demo versions)
|}

=== Other keys ===

These keys are available without enabling cheats.

{|class="wikitable"
! Key !! Action
|-
| <tt>P</tt> then <tt>Q</tt> || Return to main menu
|-
| <tt>F10</tt> || Exit to DOS
|}

[[Category:Cheat Codes]]
[[Category:Zool]]

Zool

2017-11-13T21:24:34Z

Frenkel: In the 2 demo versions the game data is uncompressed in individual files, so it's easier to reverse engineer.

{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}
{{NoModdingInfo}}

[[Zool]] is a Chupa-Chups sponsored platform game.

== Tools ==

{{BeginFileFormatTools|Type=game}}
{{FileFormatTool
| Name = [[Camoto]]
| Platform = Linux/Windows
| grp = Edit
| map = No
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{EndFileFormatTools}}

{{BeginGameFileList}}
{{GameFile
| Name = zool.dat
| Format = [[DAT Format (Zool)]]
| KnownFormat = Partial
| Desc = Archive containing game data
}}
{{GameFile
| Name = settings
| Format = [[Zool Configuration Format]]
| KnownFormat = No
| Desc = Key mapping, high scores, etc.
}}
{{EndGameFileList}}

Notice that in the full version the game data is in <tt>zool.dat</tt>, but in the two demo versions the game data is uncompressed in individual files.

== Preliminary info. ==

Currently this is about the Amiga CD32 files, it is put here as a reference for attempts on deciphering the PC version.

On the CD32 version of the game, all files are crunched using the FUNGUS cruncher; use '''xfdmaster''' to uncrunch them.

Use [http://eab.abime.net/showthread.php?t=52769 UAE XFD wrapper (beta)] to decrunch files from command line.

'''Formats'''

{|class="wikitable"
!Filename!!Description
|-
|*.CHM||Character map
|-
|}

'''CHM'''

{|class="wikitable"
!Data type!!Description
|-
|[[UINT32BE]] iHeights||Offset to image heights
|-
|[[UINT32BE]] iWidths||Offset to image widths (0 = 16 px, 1 = 32 px)
|-
|[[UINT32BE]] iUnknowns||Offset to image unknowns (seems to be tile orientation)
|-
|[[UINT32BE]] iOffsets||Offset to image pixels (4-bit graphic planar, see [[Raw_EGA_data]])
|-
| Above infos || count = iWidths - iHeights
|-
| Characters data || ...
|-
|}

Some of the files are mal-formed, or not even that format, though.

'''CHM palette'''

Their palette comes from an uncompressed WinUAE memory dump taken at the right level, offset 1264, 64 colors in [[UINT16BE]] format, 12-bit RGB; each channel nibble is duplicated (OR-ed with itself with a 4 bits left-shifted version).

Pseudo C# example:

<code>
public static IEnumerable<byte[]> FromStream(Stream stream, long position, int colors)
{
var reader = new BinaryReader(stream);
reader.BaseStream.Position = position;
var bytes = new byte[colors][];
for (int j = 0; j < colors; j++)
{
// 12-bit color : 0RGB
ushort u = reader.ReadUInt16();
ushort color = u.ToBigEndian();
int r = (color & 0x0F00) >> 8;
int g = (color & 0x00F0) >> 4;
int b = (color & 0x000F) >> 0;

// Each channel byte is formed by duplicating the nibble
var r1 = (byte)(r | (r << 4));
var g1 = (byte)(g | (g << 4));
var b1 = (byte)(b | (b << 4));

bytes[j] = new[] { r1, g1, b1 };
}
return bytes;
}
</code>

== Credits ==

Amiga stuff by [[User:Aybe|Aybe]].

Raw EGA data

2017-11-13T21:14:44Z

Frenkel: /* Examples of games that use each type */ added Linear examples: Street Fighter II and Zool

{{Image Infobox
| Hardware1 = EGA
| Depth = 4-bit (EGA)
| MinSize = 0×0
| MaxSize = Unlimited
| Palette = External
| NumPlanes = 1 or 4
| HasTransparency = N
| HasHitmap = No
| Games = ''See below''
}}

This page describes a number of generic arrangements for storing EGA graphics data. The graphics in many EGA games are stored based on one of these formats.

To avoid confusion, the term ''graphic'' refers to a single large image (such as a full-screen picture, or the entire contents of an image file) while the term ''tile'' refers to a much smaller image, which could either exist on its own or be one of many tiles that make up a large ''graphic''. In this use, all ''tiles'' in a single ''graphic'' need not be of the same dimensions.

== Introduction ==

Unlike conventional image formats, EGA data is made up of a number of '''planes'''. Each plane is like a black-and-white image that stores information about a single colour - for example if a bit is set in the blue plane as well as the red plane, that pixel will appear purple on-screen. The reason the image data is stored like this is because it mirrors the way the data must be loaded into memory for display on the EGA.

There are four standard colour planes (red, green, blue and intensity) with many games adding a fifth plane for transparency, and some even a sixth plane for 'hitmapping' (to detect when two sprites touch.) If an image is stored in planar format and it has four planes, it will be stored like four black-and-white images, one after the other (e.g. all the blue pixels first, then all the green pixels, and so on.)

The actual order of the planes depends on the implementation. It is almost always B-G-R-I, but may be the reverse, I-R-G-B, or indeed any combination at all. You can usually expect to see a masking plane with sprite graphics (for transparent parts of the image), unless the game uses a separate black and white image as the mask (as is done in many older games.)

There are several ways in which the data may be stored, depending on how graphics are divided into planes. The simplest, and most widely used, is to divide the file itself into four or more planes. When this happens, usually all the graphics are loaded at once. The next most common is for each individual graphic to be divided into four planes. Usually this happens when each individual graphic may or may not be loaded in a level. Finally each byte may be divided across the planes, providing one or two full-colour pixels per byte (this is the "conventional" linear format, where each byte is a colour number, or in the case of 4-bit EGA graphics, a single 8-bit byte contains colour numbers for two pixels.) These arrangements are described in more detail below.

== Graphic-planar EGA data ==

<table class="wikitable" style="float: right; margin: 1em;">
<caption align="bottom">Offsets into file data</caption>
<tr>
<th rowspan="2">Pixels</th>
<th colspan="4">Plane</th>
</tr>
<tr>
<th>0</th>
<th>1</th>
<th>2</th>
<th>3</th>
</tr>
<tr>
<td>(0,0) to (7,0)</td>
<td style="background-color: #0000AA; color: white;">00</td>
<td style="background-color: #00AA00; color: white;">10</td>
<td style="background-color: #AA0000; color: white;">20</td>
<td style="background-color: #555555; color: white;">30</td>
</tr>
<tr>
<td>(8,0) to (15,0)</td>
<td style="background-color: #0000AA; color: white;">01</td>
<td style="background-color: #00AA00; color: white;">11</td>
<td style="background-color: #AA0000; color: white;">21</td>
<td style="background-color: #555555; color: white;">31</td>
</tr>
<tr>
<td>(0,1) to (7,1)</td>
<td style="background-color: #0000AA; color: white;">02</td>
<td style="background-color: #00AA00; color: white;">12</td>
<td style="background-color: #AA0000; color: white;">22</td>
<td style="background-color: #555555; color: white;">32</td>
</tr>
<tr>
<td>(8,1) to (15,1)</td>
<td style="background-color: #0000AA; color: white;">03</td>
<td style="background-color: #00AA00; color: white;">13</td>
<td style="background-color: #AA0000; color: white;">23</td>
<td style="background-color: #555555; color: white;">33</td>
</tr>
<tr>
<td>(0,2) to (7,2)</td>
<td style="background-color: #0000AA; color: white;">04</td>
<td style="background-color: #00AA00; color: white;">14</td>
<td style="background-color: #AA0000; color: white;">24</td>
<td style="background-color: #555555; color: white;">34</td>
</tr>
<tr>
<td>(8,2) to (15,2)</td>
<td style="background-color: #0000AA; color: white;">05</td>
<td style="background-color: #00AA00; color: white;">15</td>
<td style="background-color: #AA0000; color: white;">25</td>
<td style="background-color: #555555; color: white;">35</td>
</tr>
<tr>
<td>(0,3) to (7,3)</td>
<td style="background-color: #0000AA; color: white;">06</td>
<td style="background-color: #00AA00; color: white;">16</td>
<td style="background-color: #AA0000; color: white;">26</td>
<td style="background-color: #555555; color: white;">36</td>
</tr>
<tr>
<td>(8,3) to (15,3)</td>
<td style="background-color: #0000AA; color: white;">07</td>
<td style="background-color: #00AA00; color: white;">17</td>
<td style="background-color: #AA0000; color: white;">27</td>
<td style="background-color: #555555; color: white;">37</td>
</tr>
<tr>
<td>(0,4) to (7,4)</td>
<td style="background-color: #0000AA; color: white;">08</td>
<td style="background-color: #00AA00; color: white;">18</td>
<td style="background-color: #AA0000; color: white;">28</td>
<td style="background-color: #555555; color: white;">38</td>
</tr>
<tr>
<td>(8,4) to (15,4)</td>
<td style="background-color: #0000AA; color: white;">09</td>
<td style="background-color: #00AA00; color: white;">19</td>
<td style="background-color: #AA0000; color: white;">29</td>
<td style="background-color: #555555; color: white;">39</td>
</tr>
<tr>
<td>(0,5) to (7,5)</td>
<td style="background-color: #0000AA; color: white;">0A</td>
<td style="background-color: #00AA00; color: white;">1A</td>
<td style="background-color: #AA0000; color: white;">2A</td>
<td style="background-color: #555555; color: white;">3A</td>
</tr>
<tr>
<td>(8,5) to (15,5)</td>
<td style="background-color: #0000AA; color: white;">0B</td>
<td style="background-color: #00AA00; color: white;">1B</td>
<td style="background-color: #AA0000; color: white;">2B</td>
<td style="background-color: #555555; color: white;">3B</td>
</tr>
<tr>
<td>(0,6) to (7,6)</td>
<td style="background-color: #0000AA; color: white;">0C</td>
<td style="background-color: #00AA00; color: white;">1C</td>
<td style="background-color: #AA0000; color: white;">2C</td>
<td style="background-color: #555555; color: white;">3C</td>
</tr>
<tr>
<td>(8,6) to (15,6)</td>
<td style="background-color: #0000AA; color: white;">0D</td>
<td style="background-color: #00AA00; color: white;">1D</td>
<td style="background-color: #AA0000; color: white;">2D</td>
<td style="background-color: #555555; color: white;">3D</td>
</tr>
<tr>
<td>(0,7) to (7,7)</td>
<td style="background-color: #0000AA; color: white;">0E</td>
<td style="background-color: #00AA00; color: white;">1E</td>
<td style="background-color: #AA0000; color: white;">2E</td>
<td style="background-color: #555555; color: white;">3E</td>
</tr>
<tr>
<td>(8,7) to (15,7)</td>
<td style="background-color: #0000AA; color: white;">0F</td>
<td style="background-color: #00AA00; color: white;">1F</td>
<td style="background-color: #AA0000; color: white;">2F</td>
<td style="background-color: #555555; color: white;">3F</td>
</tr>
</table>

This arrangement stores complete planes one after the other, where each plane contains data for the entire image.

A game that loads all its tiles at startup (such as Commander Keen 1) will tend to have all its tiles stored as a single planar graphic. Tiles will consist of areas "cropped" out of the main graphic. As such the program will usually need to know the size of the tile and its location in the planar data. This may be stored in the file before EGA data or in a separate data file.

This arrangement is also used for single graphic files loaded all at once, such as a 320×200 full-screen image.

An 16×8 image in this arrangement is described in the table on the right. The byte at index <tt>00</tt> is for the first eight blue pixels on the first line, and the byte at index <tt>12</tt> is for the first eight green pixels on the second line.

Some tilesets are comprised of multiple images in this arrangement, concatenated together. This allows each sub-image (tile) to be self-contained with data for all planes required, but only for that specific tile. This avoids decoding more data than is necessary for display.

In this case the game will usually store the size of each tile somewhere, from which the location and plane size can be calculated in the cases where each tile is of different dimensions. Often tiles are the same size, which saves a lot of trouble since the location of any particular tile (as well as the number of tiles in the file), can be easily calculated.

This arrangement is efficient enough that many games will have separate files in this format separate from all other graphics (e.g. [[Dangerous Dave 2]]).

 
== Row-planar EGA data ==

<table class="wikitable" style="float: right; margin: 1em;">
<caption align="bottom">Offsets into file data</caption>
<tr>
<th rowspan="2">Pixels</th>
<th colspan="4">Plane</th>
</tr>
<tr>
<th>0</th>
<th>1</th>
<th>2</th>
<th>3</th>
</tr>
<tr>
<td>(0,0) to (7,0)</td>
<td style="background-color: #0000AA; color: white;">00</td>
<td style="background-color: #00AA00; color: white;">02</td>
<td style="background-color: #AA0000; color: white;">04</td>
<td style="background-color: #555555; color: white;">06</td>
</tr>
<tr>
<td>(8,0) to (15,0)</td>
<td style="background-color: #0000AA; color: white;">01</td>
<td style="background-color: #00AA00; color: white;">03</td>
<td style="background-color: #AA0000; color: white;">05</td>
<td style="background-color: #555555; color: white;">07</td>
</tr>
<tr>
<td>(0,1) to (7,1)</td>
<td style="background-color: #0000AA; color: white;">08</td>
<td style="background-color: #00AA00; color: white;">0A</td>
<td style="background-color: #AA0000; color: white;">0C</td>
<td style="background-color: #555555; color: white;">0E</td>
</tr>
<tr>
<td>(8,1) to (15,1)</td>
<td style="background-color: #0000AA; color: white;">09</td>
<td style="background-color: #00AA00; color: white;">0B</td>
<td style="background-color: #AA0000; color: white;">0D</td>
<td style="background-color: #555555; color: white;">0F</td>
</tr>
<tr>
<td>(0,2) to (7,2)</td>
<td style="background-color: #0000AA; color: white;">10</td>
<td style="background-color: #00AA00; color: white;">12</td>
<td style="background-color: #AA0000; color: white;">14</td>
<td style="background-color: #555555; color: white;">16</td>
</tr>
<tr>
<td>(8,2) to (15,2)</td>
<td style="background-color: #0000AA; color: white;">11</td>
<td style="background-color: #00AA00; color: white;">13</td>
<td style="background-color: #AA0000; color: white;">15</td>
<td style="background-color: #555555; color: white;">17</td>
</tr>
<tr>
<td>(0,3) to (7,3)</td>
<td style="background-color: #0000AA; color: white;">18</td>
<td style="background-color: #00AA00; color: white;">1A</td>
<td style="background-color: #AA0000; color: white;">1C</td>
<td style="background-color: #555555; color: white;">1E</td>
</tr>
<tr>
<td>(8,3) to (15,3)</td>
<td style="background-color: #0000AA; color: white;">19</td>
<td style="background-color: #00AA00; color: white;">1B</td>
<td style="background-color: #AA0000; color: white;">1D</td>
<td style="background-color: #555555; color: white;">1F</td>
</tr>
<tr>
<td>(0,4) to (7,4)</td>
<td style="background-color: #0000AA; color: white;">20</td>
<td style="background-color: #00AA00; color: white;">22</td>
<td style="background-color: #AA0000; color: white;">24</td>
<td style="background-color: #555555; color: white;">26</td>
</tr>
<tr>
<td>(8,4) to (15,4)</td>
<td style="background-color: #0000AA; color: white;">21</td>
<td style="background-color: #00AA00; color: white;">23</td>
<td style="background-color: #AA0000; color: white;">25</td>
<td style="background-color: #555555; color: white;">27</td>
</tr>
<tr>
<td>(0,5) to (7,5)</td>
<td style="background-color: #0000AA; color: white;">28</td>
<td style="background-color: #00AA00; color: white;">2A</td>
<td style="background-color: #AA0000; color: white;">2C</td>
<td style="background-color: #555555; color: white;">2E</td>
</tr>
<tr>
<td>(8,5) to (15,5)</td>
<td style="background-color: #0000AA; color: white;">29</td>
<td style="background-color: #00AA00; color: white;">2B</td>
<td style="background-color: #AA0000; color: white;">2D</td>
<td style="background-color: #555555; color: white;">2F</td>
</tr>
<tr>
<td>(0,6) to (7,6)</td>
<td style="background-color: #0000AA; color: white;">30</td>
<td style="background-color: #00AA00; color: white;">32</td>
<td style="background-color: #AA0000; color: white;">34</td>
<td style="background-color: #555555; color: white;">36</td>
</tr>
<tr>
<td>(8,6) to (15,6)</td>
<td style="background-color: #0000AA; color: white;">31</td>
<td style="background-color: #00AA00; color: white;">33</td>
<td style="background-color: #AA0000; color: white;">35</td>
<td style="background-color: #555555; color: white;">37</td>
</tr>
<tr>
<td>(0,7) to (7,7)</td>
<td style="background-color: #0000AA; color: white;">38</td>
<td style="background-color: #00AA00; color: white;">3A</td>
<td style="background-color: #AA0000; color: white;">3C</td>
<td style="background-color: #555555; color: white;">3E</td>
</tr>
<tr>
<td>(8,7) to (15,7)</td>
<td style="background-color: #0000AA; color: white;">39</td>
<td style="background-color: #00AA00; color: white;">3B</td>
<td style="background-color: #AA0000; color: white;">3D</td>
<td style="background-color: #555555; color: white;">3F</td>
</tr>
</table>

This arrangement has more to do with how graphics are loaded rather than whether or not all graphics are loaded at once. Like ''graphic-planar'' above, each image is separate, however instead of storing each plane in its entirety, the planes are split up by row. This means once all the pixel data has been read in for a given row, the data following refers to the next plane on the same row. Only once all the planes have been read in does the data advance to the next row.

An example 16×8 image in this arrangement is shown on the right. Here the width of a row is 16 pixels, or 2 bytes of EGA data. Again, graphics in this format are often grouped together and the game will need to store the graphic's size and location.

 

== Byte-planar EGA data ==

<table class="wikitable" style="float: right; margin: 1em;">
<caption align="bottom">Offsets into file data</caption>
<tr>
<th rowspan="2">Pixels</th>
<th colspan="4">Plane</th>
</tr>
<tr>
<th>0</th>
<th>1</th>
<th>2</th>
<th>3</th>
</tr>
<tr>
<td>(0,0) to (7,0)</td>
<td style="background-color: #0000AA; color: white;">00</td>
<td style="background-color: #00AA00; color: white;">01</td>
<td style="background-color: #AA0000; color: white;">02</td>
<td style="background-color: #555555; color: white;">03</td>
</tr>
<tr>
<td>(8,0) to (15,0)</td>
<td style="background-color: #0000AA; color: white;">04</td>
<td style="background-color: #00AA00; color: white;">05</td>
<td style="background-color: #AA0000; color: white;">06</td>
<td style="background-color: #555555; color: white;">07</td>
</tr>
<tr>
<td>(0,1) to (7,1)</td>
<td style="background-color: #0000AA; color: white;">08</td>
<td style="background-color: #00AA00; color: white;">09</td>
<td style="background-color: #AA0000; color: white;">0A</td>
<td style="background-color: #555555; color: white;">0B</td>
</tr>
<tr>
<td>(8,1) to (15,1)</td>
<td style="background-color: #0000AA; color: white;">0C</td>
<td style="background-color: #00AA00; color: white;">0D</td>
<td style="background-color: #AA0000; color: white;">0E</td>
<td style="background-color: #555555; color: white;">0F</td>
</tr>
<tr>
<td>(0,2) to (7,2)</td>
<td style="background-color: #0000AA; color: white;">10</td>
<td style="background-color: #00AA00; color: white;">11</td>
<td style="background-color: #AA0000; color: white;">12</td>
<td style="background-color: #555555; color: white;">13</td>
</tr>
<tr>
<td>(8,2) to (15,2)</td>
<td style="background-color: #0000AA; color: white;">14</td>
<td style="background-color: #00AA00; color: white;">15</td>
<td style="background-color: #AA0000; color: white;">16</td>
<td style="background-color: #555555; color: white;">17</td>
</tr>
<tr>
<td>(0,3) to (7,3)</td>
<td style="background-color: #0000AA; color: white;">18</td>
<td style="background-color: #00AA00; color: white;">19</td>
<td style="background-color: #AA0000; color: white;">1A</td>
<td style="background-color: #555555; color: white;">1B</td>
</tr>
<tr>
<td>(8,3) to (15,3)</td>
<td style="background-color: #0000AA; color: white;">1C</td>
<td style="background-color: #00AA00; color: white;">1D</td>
<td style="background-color: #AA0000; color: white;">1E</td>
<td style="background-color: #555555; color: white;">1F</td>
</tr>
<tr>
<td>(0,4) to (7,4)</td>
<td style="background-color: #0000AA; color: white;">20</td>
<td style="background-color: #00AA00; color: white;">21</td>
<td style="background-color: #AA0000; color: white;">22</td>
<td style="background-color: #555555; color: white;">23</td>
</tr>
<tr>
<td>(8,4) to (15,4)</td>
<td style="background-color: #0000AA; color: white;">24</td>
<td style="background-color: #00AA00; color: white;">25</td>
<td style="background-color: #AA0000; color: white;">26</td>
<td style="background-color: #555555; color: white;">27</td>
</tr>
<tr>
<td>(0,5) to (7,5)</td>
<td style="background-color: #0000AA; color: white;">28</td>
<td style="background-color: #00AA00; color: white;">29</td>
<td style="background-color: #AA0000; color: white;">2A</td>
<td style="background-color: #555555; color: white;">2B</td>
</tr>
<tr>
<td>(8,5) to (15,5)</td>
<td style="background-color: #0000AA; color: white;">2C</td>
<td style="background-color: #00AA00; color: white;">2D</td>
<td style="background-color: #AA0000; color: white;">2E</td>
<td style="background-color: #555555; color: white;">2F</td>
</tr>
<tr>
<td>(0,6) to (7,6)</td>
<td style="background-color: #0000AA; color: white;">30</td>
<td style="background-color: #00AA00; color: white;">31</td>
<td style="background-color: #AA0000; color: white;">32</td>
<td style="background-color: #555555; color: white;">33</td>
</tr>
<tr>
<td>(8,6) to (15,6)</td>
<td style="background-color: #0000AA; color: white;">34</td>
<td style="background-color: #00AA00; color: white;">35</td>
<td style="background-color: #AA0000; color: white;">36</td>
<td style="background-color: #555555; color: white;">37</td>
</tr>
<tr>
<td>(0,7) to (7,7)</td>
<td style="background-color: #0000AA; color: white;">38</td>
<td style="background-color: #00AA00; color: white;">39</td>
<td style="background-color: #AA0000; color: white;">3A</td>
<td style="background-color: #555555; color: white;">3B</td>
</tr>
<tr>
<td>(8,7) to (15,7)</td>
<td style="background-color: #0000AA; color: white;">3C</td>
<td style="background-color: #00AA00; color: white;">3D</td>
<td style="background-color: #AA0000; color: white;">3E</td>
<td style="background-color: #555555; color: white;">3F</td>
</tr>
</table>

This arrangement has more to do with how graphics are loaded rather than whether or not all graphics are loaded at once. Like ''graphic-planar'' above, each image is separate, however instead of storing each plane in its entirety, the planes are split up at the byte level. This means each byte contains data for one plane of eight pixels, with the following byte containing data for the next plane of the same eight pixels. After four bytes have been read, all four planes will have been read for a group of eight pixels.

An example 16×8 image in this format is shown on the right. Here the width of a row is 16 pixels, or 8 bytes of EGA data. Again, graphics in this format are often grouped together and the game will need to store the graphic's size and location. (Unless it is a list of tiles which are all of the same, known, dimensions.)

 

== Linear EGA data ==

<table class="wikitable" style="float: right; margin: 1em;">
<caption align="bottom">Offsets into file data</caption>
<tr>
<th rowspan="2">Line (Y)</th>
<th colspan="8">Column (X)</th>
</tr>
<tr>
<th>0-1</th>
<th>2-3</th>
<th>4-5</th>
<th>6-7</th>
<th>8-9</th>
<th>A-B</th>
<th>C-D</th>
<th>E-F</th>
</tr>
<tr>
<td>0</td>
<td style="background-color: #000000; color: white;">00</td>
<td style="background-color: #000000; color: white;">01</td>
<td style="background-color: #000000; color: white;">02</td>
<td style="background-color: #000000; color: white;">03</td>
<td style="background-color: #000000; color: white;">04</td>
<td style="background-color: #000000; color: white;">05</td>
<td style="background-color: #000000; color: white;">06</td>
<td style="background-color: #000000; color: white;">07</td>
</tr>
<tr>
<td>1</td>
<td style="background-color: #000000; color: white;">08</td>
<td style="background-color: #000000; color: white;">09</td>
<td style="background-color: #000000; color: white;">0A</td>
<td style="background-color: #000000; color: white;">0B</td>
<td style="background-color: #000000; color: white;">0C</td>
<td style="background-color: #000000; color: white;">0D</td>
<td style="background-color: #000000; color: white;">0E</td>
<td style="background-color: #000000; color: white;">0F</td>
</tr>
<tr>
<td>2</td>
<td style="background-color: #000000; color: white;">10</td>
<td style="background-color: #000000; color: white;">11</td>
<td style="background-color: #000000; color: white;">12</td>
<td style="background-color: #000000; color: white;">13</td>
<td style="background-color: #000000; color: white;">14</td>
<td style="background-color: #000000; color: white;">15</td>
<td style="background-color: #000000; color: white;">16</td>
<td style="background-color: #000000; color: white;">17</td>
</tr>
<tr>
<td>3</td>
<td style="background-color: #000000; color: white;">18</td>
<td style="background-color: #000000; color: white;">19</td>
<td style="background-color: #000000; color: white;">1A</td>
<td style="background-color: #000000; color: white;">1B</td>
<td style="background-color: #000000; color: white;">1C</td>
<td style="background-color: #000000; color: white;">1D</td>
<td style="background-color: #000000; color: white;">1E</td>
<td style="background-color: #000000; color: white;">1F</td>
</tr>
<tr>
<td>4</td>
<td style="background-color: #000000; color: white;">20</td>
<td style="background-color: #000000; color: white;">21</td>
<td style="background-color: #000000; color: white;">22</td>
<td style="background-color: #000000; color: white;">23</td>
<td style="background-color: #000000; color: white;">24</td>
<td style="background-color: #000000; color: white;">25</td>
<td style="background-color: #000000; color: white;">26</td>
<td style="background-color: #000000; color: white;">27</td>
</tr>
<tr>
<td>5</td>
<td style="background-color: #000000; color: white;">28</td>
<td style="background-color: #000000; color: white;">29</td>
<td style="background-color: #000000; color: white;">2A</td>
<td style="background-color: #000000; color: white;">2B</td>
<td style="background-color: #000000; color: white;">2C</td>
<td style="background-color: #000000; color: white;">2D</td>
<td style="background-color: #000000; color: white;">2E</td>
<td style="background-color: #000000; color: white;">2F</td>
</tr>
<tr>
<td>6</td>
<td style="background-color: #000000; color: white;">30</td>
<td style="background-color: #000000; color: white;">31</td>
<td style="background-color: #000000; color: white;">32</td>
<td style="background-color: #000000; color: white;">33</td>
<td style="background-color: #000000; color: white;">34</td>
<td style="background-color: #000000; color: white;">35</td>
<td style="background-color: #000000; color: white;">36</td>
<td style="background-color: #000000; color: white;">37</td>
</tr>
<tr>
<td>7</td>
<td style="background-color: #000000; color: white;">38</td>
<td style="background-color: #000000; color: white;">39</td>
<td style="background-color: #000000; color: white;">3A</td>
<td style="background-color: #000000; color: white;">3B</td>
<td style="background-color: #000000; color: white;">3C</td>
<td style="background-color: #000000; color: white;">3D</td>
<td style="background-color: #000000; color: white;">3E</td>
<td style="background-color: #000000; color: white;">3F</td>
</tr>
</table>

This arrangement is the opposite of planar. Instead of the data being split up into planes, it is combined into a collection of pixels. Each nybble (half a byte - four bits) contains data for all four planes for a single pixel. This is otherwise known as 4bpp (four bits-per-pixel) linear data.

When reading a byte, the upper four bits contain data for one pixel, and the lower four bits contain data for a second pixel.

Very few games store data in this format, on account of the extra processing required to load the data into EGA display memory. It is listed here for completeness.

 
== Converting planes into palette indices ==

Once it is known how the planes are arranged, converting the data into colours is done by combining the bits in each plane together using binary arithmetic. This will return a value between 0 and 15 inclusive, which is an index into the EGA palette.

<table border="0" cellspacing="2" cellpadding="2" class="wikitable">
<tr>
<th>Plane</th>
<th>Value (hex)</th>
<th>Value (binary)</th>
<th colspan="16">Value (pixels/flipped binary)</th>
</tr>
<tr>
<td>Blue</td>
<td>AA AA</td>
<td>10101010 10101010</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #0000AA; color: white;">1</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #0000AA; color: white;">1</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #0000AA; color: white;">1</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #0000AA; color: white;">1</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #0000AA; color: white;">1</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #0000AA; color: white;">1</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #0000AA; color: white;">1</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #0000AA; color: white;">1</td>
</tr>
<tr>
<td>Green</td>
<td>CC CC</td>
<td>11001100 11001100</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #00AA00; color: white;">1</td>
<td style="background-color: #00AA00; color: white;">1</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #00AA00; color: white;">1</td>
<td style="background-color: #00AA00; color: white;">1</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #00AA00; color: white;">1</td>
<td style="background-color: #00AA00; color: white;">1</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #00AA00; color: white;">1</td>
<td style="background-color: #00AA00; color: white;">1</td>
</tr>
<tr>
<td>Red</td>
<td>F0 F0</td>
<td>11110000 11110000</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #AA0000; color: white;">1</td>
<td style="background-color: #AA0000; color: white;">1</td>
<td style="background-color: #AA0000; color: white;">1</td>
<td style="background-color: #AA0000; color: white;">1</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #AA0000; color: white;">1</td>
<td style="background-color: #AA0000; color: white;">1</td>
<td style="background-color: #AA0000; color: white;">1</td>
<td style="background-color: #AA0000; color: white;">1</td>
</tr>
<tr>
<td>Intensity</td>
<td>FF 00</td>
<td>11111111 00000000</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #555555; color: white;">1</td>
<td style="background-color: #555555; color: white;">1</td>
<td style="background-color: #555555; color: white;">1</td>
<td style="background-color: #555555; color: white;">1</td>
<td style="background-color: #555555; color: white;">1</td>
<td style="background-color: #555555; color: white;">1</td>
<td style="background-color: #555555; color: white;">1</td>
<td style="background-color: #555555; color: white;">1</td>
</tr>
<tr>
<td>Result</td>
<td></td>
<td></td>
<td style="background-color: #000000; color: white;">0</td>
<td style="background-color: #0000AA; color: white;">1</td>
<td style="background-color: #00AA00; color: white;">2</td>
<td style="background-color: #00AAAA; color: white;">3</td>
<td style="background-color: #AA0000; color: white;">4</td>
<td style="background-color: #AA00AA; color: white;">5</td>
<td style="background-color: #AAAA00; color: white;">6</td>
<td style="background-color: #AAAAAA; color: white;">7</td>
<td style="background-color: #555555; color: white;">8</td>
<td style="background-color: #5555FF; color: white;">9</td>
<td style="background-color: #55FF55; color: black;">A</td>
<td style="background-color: #55FFFF; color: black;">B</td>
<td style="background-color: #FF5555; color: black;">C</td>
<td style="background-color: #FF55FF; color: black;">D</td>
<td style="background-color: #FFFF55; color: black;">E</td>
<td style="background-color: #FFFFFF; color: black;">F</td>
</tr>
</table>

== Examples of games that use each type ==

* '''Single image graphic-planar:''' [[Commander Keen 1-3]], [[Cosmo's Cosmic Adventures]], [[Dangerous Dave in the Haunted Mansion]], [[Shadow Knights]] (all use a fifth masking plane in some of their files.)
* '''Graphic-planar:''' [[Dangerous Dave]], [[Dangerous Dave in the Haunted Mansion]], [[Shadow Knights]] (the first uses offsets combined with X and Y dimensions to calculate plane size, the second two have their regularly-sized 16x16 tiles stored this way.)
* '''Row-planar:''' [[Cosmo's Cosmic Adventures]] tiles and sprites
* '''Byte-planar:''' [[ProGraphx Toolbox tileset format]]
* '''Linear:''' [[Street Fighter II]], [[Zool]]

[[Category:Articles]]

Zool/Cheats

2017-11-12T20:48:11Z

Frenkel: added cheats of the 2 demo versions

To enable cheats, press the <tt>Spacebar</tt> on the main menu to access the options screen. Then type the word <tt>stretlamp</tt> (<tt>streetlamp</tt> in the two demo versions) and press <tt>Enter</tt>.

At the copy protection screen press <tt>Spacebar</tt> to skip this screen.

The the following keys will become available during gameplay:

{|class="wikitable"
! Key !! Action
|-
| <tt>1</tt> || Enable invincibility
|-
| <tt>2</tt> || Set time to 1 (unavailable in the demo versions)
|-
| <tt>4</tt> || Lose a life
|-
| <tt>Keypad +</tt> || Skip to next level
|-
| <tt>Keypad -</tt> || Skip to previous level
|}

=== Other keys ===

These keys are available without enabling cheats.

{|class="wikitable"
! Key !! Action
|-
| <tt>P</tt> then <tt>Q</tt> || Return to main menu
|-
| <tt>F10</tt> || Exit to DOS
|}

[[Category:Cheat Codes]]
[[Category:Zool]]

Inverse Frequency Sound format

2017-11-11T23:47:39Z

Frenkel: added Space Chase

{{Sound Infobox
| Type = PC Speaker
| Count = 65,535
| Rate = 18 - 144 Hz
| NumChannels = 1
| BitsPerSample = 16
| Compressed = N
| Tags = Names
| Games =
{{Game|Catacomb}}
{{Game|Commander Keen 1-3}}
{{Game|Cosmo's Cosmic Adventures}}
{{Game|Dangerous Dave}}
{{Game|Dangerous Dave in Copyright Infringement}}
{{Game|Dangerous Dave 2}}
{{Game|Duke Nukem}}
{{Game|Duke Nukem II}}
{{Game|Hovertank 3-D}}
{{Game|Math Rescue}}
{{Game|Major Stryker}}
{{Game|Monster Bash}}
{{Game|Paragon}} 
{{Game|Pickle Wars}}
{{Game|Realms of Chaos}} 
{{Game|Rescue Rover}}
{{Game|Shadow Knights}}
{{Game|Slordax}}
{{Game|Space Chase}}
{{Game|Word Rescue}}
{{Game|Xenopods}}
}}

The '''Inverse Frequency Sound format''' is the format used by Apogee/id Software in many of their games for the PC sounds. It is named because the bulk of the data is stored as 'inverse frequency' values (the higher the value, the lower the tone it produces.) Most commonly this is stored in a <tt>SOUNDS.xxx</tt> file, though it may also be stored internally in the game executable.

Later games, such as [[Wolfenstein 3-D]] use a modified form of this for their (less important) PC speaker and Adlib sounds.

== File format ==

The file is divided into three sections, 16 bytes of header, a list of sound names and the actual sound data. The start of the sound data should thus be <code>(count + 1) * 16</code> bytes from the file start.

=== Header ===

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[char]][4] || signature || "SND" + terminating null. Indicates the start of a sound file, whereas "SPK" + $00 indicates the start of the older 'speaker' format, which has very few differences.
|-
| [[UINT16LE]] || size || Size of file
|-
| [[UINT16LE]] || unknown || Usually 0x003C, but doesn't appear to do anything.
|-
| [[UINT16LE]] || count || Number of sounds. For SPK files this is blank as the number of sounds is always 63.
|-
| [[BYTE]][6] || pad || Nulls to pad structure up to 16 bytes.
|}

=== Sound definitions ===

This structure is repeated once per sound.

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT16LE]] || offset || Offset of the sound from the beginning of the file.
|-
| [[UINT8]] || priority || Whether or not sound will be interrupted by another sound if said sound starts playing while the first is. Sounds can only be interrupted by sounds that have an equal or higher value of this. 255 is max, 0 is inadvisable.
|-
| [[UINT8]] || rate || Defines the update rate of the timer generating the sound interrupt. Usually set to 8.
|-
| [[char]][12] || name || Null-padded sound name
|}

=== Sound data ===

Sound data is divided into words (UINT16LE), with the word value being inversely proportional to the sound frequency. The sound frequency in Hz can be calculated as follows:

frequency = 1193181 / value

These word values are written directly to PIT Channel 2. The PC Speaker is updated at a rate of usually 140 Hz, so each word value is around 1/140th of a second of tone. Most files contain a few seconds of sound. The value $FFFF signals the end of a sound and most values are between the range $0100-$5000. $0000 is silence and will cause the PC Speaker to be turned off.

Depending on the implementation, the update rate might differ. [[Catacomb]] will set the speed for each sound according to the sound's rate value (rates 0 and 1 are about 18.18 Hz, rate = 8 is 140 Hz). [[Hovertank 3-D]] is hard-coded to use a fixed rate of 140 Hz and ignore each sound's rate value. [[Duke Nukem]] uses a fixed rate of 144 Hz.

Later games use a similar format for PC sounds, where the sound data is in bytes with values of 0-255. Multiplying those byte values by 60 basically converts them to word values that can be written directly to PIT Channel 2. The loss of fine-tuning can probably be attributed to the lesser role of PC sounds in the [[AudioT Format]], which has a totally different way of reading the sounds, and also contains AdLib sound effects and music.

== Notes ==

Most games load the entire file into memory and ignore all values in the header. The sound names are ignored, too. Since the games use hard-coded sound numbers (usually a 1-based index), seeking to <tt>16*soundnumber</tt> will get the sound data offset, priority and rate.

Due to a bug in the implementation, [[Duke Nukem]] uses the low byte of the sound's offset value as the priority for the sounds read from <tt>DUKE1-B.DN?</tt>.

== Credits ==

This format has been reverse engineered many times, most often in the [[Commander Keen 1-3]] fan community. Probably first by [http://web.archive.org/web/20000815235203/http://www.dd.chalmers.se/~f98anga/projects/keen/ Anders Gavare]. 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!)

DAT Format (Zool)

2017-11-11T23:26:21Z

Frenkel: Lotus III also uses this file format

{{Archive Infobox
| MaxFiles = Unlimited
| FAT = Beginning
| Names = Yes, 8
| Metadata = None
| Subdirectories = N
| Compressed = Y
| Encrypted = N
| Hidden = N
| Games =
{{Game|Lotus: The Ultimate Challenge}}
{{Game|Zool}}
}}
The '''Zool DAT Format''' is used by [[Lotus: The Ultimate Challenge]] and [[Zool]] for storing game data. Data is stored in chunks of 512 bytes.

As the offset of the last chunk is stored in a UINT16LE field, its maximum value is 65,535. Multiplied by the 512-byte chunk length, this yields a maximum DAT size of 33,553,920 bytes (512 bytes less than 32MB.)

== File format ==

=== Signature ===

There is no signature, and the fields must be checked to correctly detect files. Since the first two bytes multiplied by 512 must equal the size of the DAT file, this is one good check.

=== Header ===

The header is very simple.

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT16LE]] || len || Length of DAT file, in units of 512 bytes.
|}

This value is multiplied by 512 to give the size of the DAT file, which is also used as the offset of the end of the last file in the archive.

=== File entry ===

The header is followed by one or more file entries in the following structure.

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[char]][8] || filename || Filename, padded with spaces (char 0x20), not null-terminated.
|-
| [[UINT16LE]] || len || Offset of file, in units of 512 bytes.
|}

The list of file entries takes up a minimum of 512 bytes, and if more files are needed, space is allocated in chunks of 512 bytes.

The file's size must be calculated from the offset of the following file.

This structure is repeated until the first byte in <tt>filename</tt> is 0. This immediately terminates the structure and the rest of the filename and the length are not present. (However as the FAT is padded to chunks of 512 bytes, there will always be enough bytes available in the padding data to read the full field.)

In the event that 51 files are present, the last valid file entry will end exactly on a 512 byte boundary. This will cause the FAT to be extended by 512 bytes, simply to store the terminating null (with 511 bytes of padding.) This does not require any special handling when reading the archive, but is mentioned to illustrate the importance of the terminating null byte.

=== Extra data ===

Since both the FAT and each file are padded to occupy a multiple of 512 bytes, there is unused data at the end of most files. This is especially noticeable in the FAT itself, which seems to contain old high score data leftover from the game's development.

The padding data found in later files does not seem to be compressed, suggesting that decompression happens outside the archive format.

== Tools ==

{{BeginFileFormatTools|Type=group}}
{{FileFormatTool
| Name = [[Camoto]]
| Platform = Linux/Windows
| canExtract = Yes
| canDecompress = No
| canCreate = Yes
| canModify = Yes
| canCompress = No
| editHidden = N/A
| editMetadata = N/A
}}
{{EndFileFormatTools}}

== Credits ==

This file format was reverse engineered by [[User:Malvineous|Malvineous]]. 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!)

Zool/Cheats

2017-11-11T23:09:25Z

Frenkel: cheat lets you skip copy protection screen and 2 sets the time to 1 and 4 lets you loose a life

To enable cheats, press the <tt>Spacebar</tt> on the main menu to access the options screen. Then type the word <tt>stretlamp</tt> and press <tt>Enter</tt>.

At the copy protection screen press <tt>Spacebar</tt> to skip this screen.

The the following keys will become available during gameplay:

{|class="wikitable"
! Key !! Action
|-
| <tt>1</tt> || Enable invincibility
|-
| <tt>2</tt> || Set time to 1
|-
| <tt>4</tt> || Lose a life
|-
| <tt>Keypad +</tt> || Skip to next level
|-
| <tt>Keypad -</tt> || Skip to previous level
|}

=== Other keys ===

These keys are available without enabling cheats.

{|class="wikitable"
! Key !! Action
|-
| <tt>P</tt> then <tt>Q</tt> || Return to main menu
|-
| <tt>F10</tt> || Exit to DOS
|}

[[Category:Cheat Codes]]
[[Category:Zool]]

Cosmo's Cosmic Adventure/Cheats

2017-08-02T19:52:08Z

Frenkel: add F10+P to pause without showing 'Game Paused'

== Full-Inventory Cheat ==

* Hold down '''C''', '''0''' (zero), and '''F10''' to fill up your health, and bomb inventory.

== Debug Cheats ==

Hold down '''Tab''', '''F12''', and '''Delete''' to activate debug mode. The following keys will then work:

* '''F10 + G''' will activate God Mode. This means that Cosmo cannot be harmed by enemies or hazards. He can, however, die by falling off the bottom of the screen.
* '''F10 + W''' will bring up a window where you can type in which level you would like to go to.
* '''F10 + M''' will bring up a status window showing how much memory (in kB) is free, how much total memory is being used, how large the level is, and how many actors (Cosmo, enemies, objects, and obstacles) are in the level.
* '''F10 + P''' will pause the game without showing 'Game Paused'
* '''F10 + E + N + D''' will skip to the end-of-episode cutscenes.
* '''F11''' Pressing F11 twice on the main title screen will cause the game to go into demo recording mode. The recorded demo will be saved into the file '''PREVDEMO.MNI'''

[[Category:Cheat Codes]]
[[Category:Cosmo's Cosmic Adventures]]

Monster Bash/Cheats

2017-01-30T20:16:08Z

Frenkel: There's no jump cheat in the unmodified version of Monster Bash, right?

== Gameplay ==

For these, the key must be held first then F10 pressed. If F10 is pressed first, the level hints window will open, preventing the cheat from working.

; M + F10
: Show memory statistics
; P + F10
: Pause game without showing a popup window
; Z + F10
: Five extra lives

The game also includes a warp cheat, however the activation key has been disabled. It can be re-enabled via hex editing<ref>http://sfprod.shikadi.net/old/games/monsterbash.htm</ref> or by running a trainer<ref>http://forums.3drealms.com/vb/showthread.php?t=2584</ref>. The trainer also adds a jump cheat.

== References ==
<references/>

[[Category:Cheat Codes]]
[[Category:Monster Bash]]

Talk:EPF Format

2016-09-28T19:25:54Z

Frenkel: oops, forgot to sign my message

This file format is also used by some Windows games:
* Aladdin
* Pressure Drop
* Under Pressure
* VR Sports Powerboat Racing
Should this be mentioned somewhere?
[[User:Frenkel|Frenkel]] ([[User talk:Frenkel|talk]]) 19:25, 28 September 2016 (UTC)

Talk:EPF Format

2016-09-22T23:05:58Z

Frenkel: What about Windows games?

This file format is also used by some Windows games:
* Aladdin
* Pressure Drop
* Under Pressure
* VR Sports Powerboat Racing
Should this be mentioned somewhere?

EPF Format

2016-09-22T22:59:07Z

Frenkel: Kingpin: Arcade Sports Bowling added

{{Archive Infobox
| MaxFiles = 65,535
| FAT = End
| Names = Yes, 8.3
| Metadata = None
| Subdirectories = N
| Compressed = Y
| Encrypted = N
| Hidden = Y
| Games =
{{Game|Alien Breed Tower Assault}}
{{Game|Arcade Pool}}
{{Game|Kingpin: Arcade Sports Bowling}}
{{Game|Mr Blobby}}
{{Game|Overdrive}}
{{Game|Project X}}
{{Game|Sensible Golf}}
{{Game|Speed Demons}}
{{Game|Spirou}}
{{Game|The Adventures of Tintin: Prisoners of the Sun}}
{{Game|The Jungle Book}}
{{Game|The Lion King}}
{{Game|The Smurfs}}
{{Game|Tin Tin in Tibet}}
{{Game|Universe}}
}}
The EPF file format is used in many games, like:

Some (all?) of these games are made by East Point Software, so EPF (a shortened version of "EPFS" from the file header) probably stands for East Point File System or something similar.

== File format ==

=== Signature ===

The first four bytes in the file are "EPFS", followed by a [[UINT32LE]] offset (so that value must be smaller than the total file size.)

=== Header ===

{|class="wikitable"
!Data type!!Description
|-
|[[BYTE]] signature[4]||"EPFS"
|-
|[[UINT32LE]] fatOffset||Offset of the FAT
|-
|[[UINT8]] unknown||{{TODO|Unknown, always zero - flags?}}
|-
|[[UINT16LE]] numFiles||Number of files
|}

The data for the first file starts immediately after the header (i.e. file offset 11.)

=== File entry ===

At offset <tt>fatOffset</tt> sits a list of file entries. The following structure is repeated until the end of the file.

{|class="wikitable"
!Data type!!Description
|-
|[[BYTE]] filename[13]||Filename (NULL-terminated)
|-
|[[UINT8]] compressionFlag||0 for "file is not compressed", 1 for "file is compressed"
|-
|[[UINT32LE]] compressedSize||size of the compressed file
|-
|[[UINT32LE]] decompressedSize||size of the file after decompression
|}

In order to calculate the offset of each file, a running total is required. It should start at offset 11 (just after the header), then the <tt>compressedSize</tt> should be added to reveal the offset of the next file.

=== Compression ===

The compression scheme is [[LZW compression|LZW]], with a dynamic bit length from 9 to 14.

The bits are stored in big-endian byte order, in contrast to e.g. Apogee/id LZW. For example:

12 34 56 // bytes in compressed data file
00010010 00110100 01010110 // converted to 8-bit binary
000100100 011010001 010110 // bits read in big-endian order (Lion King)
000010010 100011010 010101 // bits read in little-endian order (id/Apogee)
^...go here ^bits from here...

Although it uses a "normal" LZW algorithm, there are a few differences:

* There are no reserved codewords at the beginning of the dictionary, so the first valid (9-bit) codeword is 0x100.
* When the dictionary is reset, the bit length is unchanged.
* The two largest possible codewords (at the current bit length) are reserved. The largest codeword is used to signify the end of the data, and the second largest codeword is used to reset the dictionary.
* Once the third-largest codeword is encountered and processed (this is the largest valid/non-reserved codeword - 1021 for 10-bit codes) the bit length is incremented.

The reserved codewords deserve a little extra explanation. For a 10-bit codeword length, the largest possible value that can fit in ten bits is (1<<10)-1 == 1023, so a codeword of 1023 signifies the end of the data. A codeword of 1022 (one less than the maximum) will reset the dictionary, but leave the codeword length unchanged (10-bits in this example), although in reality it would not make sense to encounter a dictionary-reset codeword until the dictionary has reached its maximum size, i.e. 14-bit codewords are in use.

Keep in mind that these reserved codewords must be processed before the LZW decoder sees them, otherwise it will treat them as lookups into the dictionary, resulting in out of range accesses. Also remember that once the bit length increases, the two reserved codewords will change, as the maximum codeword value has increased. This frees up the "old" reserved codewords which are then used as normal codewords.

At least one EPF file (OVER.EPF from the game "Overdrive") contains corrupted files (4X43.MAP and 4X44.MAP), apparently due to a bug in the original compression algorithm when the files were created. No tools are able to extract these files, and the levels are unplayable in the game (which crashes with an error.)

=== Hidden data ===

Nothing requires the FAT to sit directly after the last file, and because the offset is specified in the header, it is possible to store the FAT much further past the end of the last file. This can be done to provide a block of data between the end of the last file and the start of the FAT which is effectively hidden, as it does not belong to any file in the archive.

While none of the official files seem to do this, it is nonetheless an interesting possibility. The Camoto tool makes this space available as a "comment" field.

== Tools ==

{{BeginFileFormatTools|Type=group}}
{{FileFormatTool
| Name = [[Camoto]]
| Platform = Linux/Windows
| canExtract = Yes
| canDecompress = Yes
| canCreate = Yes
| canModify = Yes
| canCompress = No
| editHidden = Yes
| editMetadata = N/A
}}
{{EndFileFormatTools}}

ProGraphx Toolbox tileset format

2014-09-13T14:08:43Z

Frenkel: /* Header */ FBI Fred padding info added

{{Tileset Infobox
| Hardware1 = EGA
| MaxTiles = 255 per subtileset, unlimited subtilesets
| Palette = Default EGA
| Names = N
| TileMinSize = 0×0
| TileMaxSize = 2040×255
| NumPlanes = 5
| PlaneArrangement = [[Byte-planar EGA]]
| HasTransparency = Y
| HasHitmap = N
| Metadata = None
| Subtilesets = Y
| Compressed = N
| Hidden = N
| Game1 = Dark Ages
| Game2 = Duke Nukem
| Game3 = Crystal Caves
| Game4 = FBI Fred
| Game5 = Secret Agent
}}
This file format is used by the ProGraphx Toolbox to store images used for map tiles in a game.
__TOC__
The ProGraphx Toolbox, written by Peder Jungck, is used by the following games:

* [[Dark Ages]] - <tt>DA3.EXE</tt> contains the string ''Version 1.0 EGA/VGAProGraphx EGA/VGA Toolbox (DA1.EXE and DA2.exe contain gibberish)''
* [[Duke Nukem]] - <tt>DN1.EXE</tt> contains the string ''Version 1.0 EGA/VGAProGraphx EGA/VGA Toolbox''
* [[Crystal Caves]] - <tt>CC1.EXE</tt> contains the string ''Version 1.5 320x200 PAN EGA/VGAProGraphx EGA/VGA Toolbox''
* [[FBI Fred]] - <tt>FBIFRED.EXE</tt> contains the string ''Version 1.5 EGA/VGAProGraphx EGA/VGA Toolbox (c) 1990''
* [[Secret Agent]] - <tt>SAM1.EXE</tt> contains the string ''ProGraphx EGA/VGA Toolbox Version 2.0 320x200 EGA/VGA Copyright 1991 by Peder Jungck''

== File format ==

The file consists of a number of tilesets one after the other. Each tileset is made up of a collection of small images (usually 8×8 or 16×16, but the format supports up to 2040×255.)

In '''Secret Agent''' the files are encrypted with [[Secret Agent encryption]]. In the other games there is no encryption.

=== Signature ===

There is no signature, however careful processing of the header can be used to check whether the last tileset ends at exactly the end of the file (allowing for padding in some versions of the format.) If not, it is unlikely to be in this format. Be careful that files with zero values don't cause an endless loop when calculating offsets.

=== Header ===

Each tileset begins with the following header.

{|class="wikitable"
!Data type!!Description
|-
|[[BYTE]] count||Number of sprites in this chunk (50 in most cases)
|-
|[[BYTE]] width||Sprite width, in bytes (not in pixels)
|-
|[[BYTE]] height||Sprite height, in pixels
|}

The image data for the tileset follows the header. After the image data either the next header begins, or the file ends.

'''Dark Ages:''' Each tileset is padded up to 8064 bytes, except for the last tileset which contains 2 sprites and is padded up to 384 bytes.

'''Duke Nukem:''' Each tileset is padded up to 8064 bytes, except for <tt>NUMBERS.DN?</tt> (7186 bytes) and the backdrop files (<tt>DROP*.DN?</tt>) which have no padding. The backdrop files also have all three header bytes set to zero. For these files, the number of sprites is always 130, the width is always 2 (bytes) and the height is always 16.

'''Crystal Caves:''' The file ends after the last tile's image data, there is no padding.

'''FBI Fred:''' Each tileset is padded up to 8064 bytes, except for the last tileset which contains 23 sprites and is padded up to 3712 bytes.

'''Secret Agent:''' Each tileset is padded up to 8064 bytes for 16×16 sprite files (<tt>SAM?01.GFX</tt>), and 2048 bytes for 8×8 sprite files (<tt>SAM?02.GFX</tt>).

For those files with padding at the end, be careful not to interpret the padding as the presence of more tiles.

=== Image data ===

The image data is in [[Byte-planar EGA]] format with five planes, so reading <tt>width × height × 5</tt> bytes will read in enough data for a single image (one tile.) This value multiplied by the number of tiles (<tt>count</tt>) will yield the number of bytes in the entire tileset, which can be used to skip directly to the next tileset in the file (if any.)

The first byte in each tile's data is the transparency plane (1 == opaque, 0 == transparent), and the following four bytes/planes are blue, green, red and intensity. The MSB in each byte (10000000) is the first/left-most pixel, and the eighth pixel is the LSB (00000001). This means if the bits are processed in a loop, as the X direction increases to the right (0, 1, 2) the bit value decreases (0x80, 0x40, 0x20.)

== Notes ==

* For at least '''Duke Nukem''', the game seems to ignore the header of ''all'' files in this format. You can set the entire header of any tileset file to zero values and the game will still load them properly. This also means that you cannot use larger tilesets without modifying the executable.

== Credits ==

This file format has been reverse engineered by many people over the years. [[User:K1n9_Duk3|K1n9_Duk3]] discovered that Duke Nukem uses this format. [[User:Frenkel|Frenkel]] identified the similarities amongst all the games using the file format, and realised they all use the ProGraphx Toolbox. 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!)

ProGraphx Toolbox tileset format

2014-09-05T22:14:54Z

Frenkel: FBI Fred added, padding info not yet added

{{Tileset Infobox
| Hardware1 = EGA
| MaxTiles = 255 per subtileset, unlimited subtilesets
| Palette = Default EGA
| Names = N
| TileMinSize = 0×0
| TileMaxSize = 2040×255
| NumPlanes = 5
| PlaneArrangement = [[Byte-planar EGA]]
| HasTransparency = Y
| HasHitmap = N
| Metadata = None
| Subtilesets = Y
| Compressed = N
| Hidden = N
| Game1 = Dark Ages
| Game2 = Duke Nukem
| Game3 = Crystal Caves
| Game4 = FBI Fred
| Game5 = Secret Agent
}}
This file format is used by the ProGraphx Toolbox to store images used for map tiles in a game.
__TOC__
The ProGraphx Toolbox, written by Peder Jungck, is used by the following games:

* [[Dark Ages]] - <tt>DA3.EXE</tt> contains the string ''Version 1.0 EGA/VGAProGraphx EGA/VGA Toolbox (DA1.EXE and DA2.exe contain gibberish)''
* [[Duke Nukem]] - <tt>DN1.EXE</tt> contains the string ''Version 1.0 EGA/VGAProGraphx EGA/VGA Toolbox''
* [[Crystal Caves]] - <tt>CC1.EXE</tt> contains the string ''Version 1.5 320x200 PAN EGA/VGAProGraphx EGA/VGA Toolbox''
* [[FBI Fred]] - <tt>FBIFRED.EXE</tt> contains the string ''Version 1.5 EGA/VGAProGraphx EGA/VGA Toolbox (c) 1990''
* [[Secret Agent]] - <tt>SAM1.EXE</tt> contains the string ''ProGraphx EGA/VGA Toolbox Version 2.0 320x200 EGA/VGA Copyright 1991 by Peder Jungck''

== File format ==

The file consists of a number of tilesets one after the other. Each tileset is made up of a collection of small images (usually 8×8 or 16×16, but the format supports up to 2040×255.)

In '''Secret Agent''' the files are encrypted with [[Secret Agent encryption]]. In the other games there is no encryption.

=== Signature ===

There is no signature, however careful processing of the header can be used to check whether the last tileset ends at exactly the end of the file (allowing for padding in some versions of the format.) If not, it is unlikely to be in this format. Be careful that files with zero values don't cause an endless loop when calculating offsets.

=== Header ===

Each tileset begins with the following header.

{|class="wikitable"
!Data type!!Description
|-
|[[BYTE]] count||Number of sprites in this chunk (50 in most cases)
|-
|[[BYTE]] width||Sprite width, in bytes (not in pixels)
|-
|[[BYTE]] height||Sprite height, in pixels
|}

The image data for the tileset follows the header. After the image data either the next header begins, or the file ends.

'''Dark Ages:''' Each tileset is padded up to 8064 bytes, except for the last tileset which contains 2 sprites and is padded up to 384 bytes.

'''Duke Nukem:''' Each tileset is padded up to 8064 bytes, except for <tt>NUMBERS.DN?</tt> (7186 bytes) and the backdrop files (<tt>DROP*.DN?</tt>) which have no padding. The backdrop files also have all three header bytes set to zero. For these files, the number of sprites is always 130, the width is always 2 (bytes) and the height is always 16.

'''Crystal Caves:''' The file ends after the last tile's image data, there is no padding.

'''Secret Agent:''' Each tileset is padded up to 8064 bytes for 16×16 sprite files (<tt>SAM?01.GFX</tt>), and 2048 bytes for 8×8 sprite files (<tt>SAM?02.GFX</tt>).

For those files with padding at the end, be careful not to interpret the padding as the presence of more tiles.

=== Image data ===

The image data is in [[Byte-planar EGA]] format with five planes, so reading <tt>width × height × 5</tt> bytes will read in enough data for a single image (one tile.) This value multiplied by the number of tiles (<tt>count</tt>) will yield the number of bytes in the entire tileset, which can be used to skip directly to the next tileset in the file (if any.)

The first byte in each tile's data is the transparency plane (1 == opaque, 0 == transparent), and the following four bytes/planes are blue, green, red and intensity. The MSB in each byte (10000000) is the first/left-most pixel, and the eighth pixel is the LSB (00000001). This means if the bits are processed in a loop, as the X direction increases to the right (0, 1, 2) the bit value decreases (0x80, 0x40, 0x20.)

== Notes ==

* For at least '''Duke Nukem''', the game seems to ignore the header of ''all'' files in this format. You can set the entire header of any tileset file to zero values and the game will still load them properly. This also means that you cannot use larger tilesets without modifying the executable.

== Credits ==

This file format has been reverse engineered by many people over the years. [[User:K1n9_Duk3|K1n9_Duk3]] discovered that Duke Nukem uses this format. [[User:Frenkel|Frenkel]] identified the similarities amongst all the games using the file format, and realised they all use the ProGraphx Toolbox. 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 talk:Sparse archives

2014-06-29T20:04:47Z

Frenkel: question about location of hidden data

The description of this category starts with

''This category lists all archive formats that can have data hidden in between consecutive files, without affecting use of the archive.''

Should [[Legend of Seven Paladins 3D Archive Format]] be in this category? It can't store hidden data between consecutive files, but it can store hidden data between the header and the actual archived files, I think. [[User:Frenkel|Frenkel]] ([[User talk:Frenkel|talk]]) 20:04, 29 June 2014 (GMT)

Legend of Seven Paladins 3D Archive Format

2014-06-29T19:57:30Z

Frenkel: Created page with "{{Archive Infobox | MaxFiles = less than 4,294,967,296 | FAT = Beginning | Names = N | Metadata = None | Subdirectories = N | Compressed = N | Encrypted = N | Hidden =..."

{{Archive Infobox
| MaxFiles = less than 4,294,967,296
| FAT = Beginning
| Names = N
| Metadata = None
| Subdirectories = N
| Compressed = N
| Encrypted = N
| Hidden = Y
| Game1 = Legend of Seven Paladins 3D
}}

The '''Legend of Seven Paladins 3D Archive Format''' is one of the more efficient archives in that it only stores file offsets in the headers, and the file sizes must be calculated from these. It doesn't store filenames.

== File format ==

The file starts with a [[UINT32LE]] representing the offset of the first file in the archive. Then comes a [[UINT32LE]] representing the offset of the second file, etc. Until a [[UINT32LE]] comes along who's value is the same as the file size of the archive.
Between these offsets and the actual data of the first file, there is room for hidden data.

The size of a file must be calculated from the offset of the next file minus its own offset.

This archive doesn't store filenames, so it's impossible to determine the file formats of the archived files by looking at the filename extension. Luckily, all file formats of the files in the officially released archives can be determined by looking at the first byte of each file:

{|class="wikitable"
! First byte !! File format
|-
| 0x00 0x1f
| 6-bit [[VGA Palette]]
|-
| 0x04
| [[Build-engine Map Format]]
|-
| 0x0a
| [[PCX Format]]
|-
| 0x43
| [[VOC Format]]
|-
| 0x4d
| [[MID Format]]
|}

== Tools ==

{{BeginFileFormatTools|Type=group}}
{{FileFormatTool
| Name = [http://sfprod.shikadi.net/old/games/lotsp.htm#extractor Lotspe]
| Platform = DOS
| canExtract = Yes
| canDecompress = N/A
| canCreate = No
| canModify = No
| canCompress = N/A
| editHidden = No
| editMetadata = N/A
}}
{{EndFileFormatTools}}

== Credits ==

This file format was reverse engineered by [[User:Frenkel|Frenkel]]. 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!)

Legend of Seven Paladins 3D

2014-06-29T16:45:17Z

Frenkel: Use new file format list template

{{Stub}}

{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}

[[Legend of Seven Paladins 3D]] is a first-person shooter and it's the first commercially released game that uses the [[:Category:Build engine|Build engine]].

== Tools ==

{{BeginFileFormatTools|Type=game}}
{{FileFormatTool
| Name = [http://sfprod.shikadi.net/old/games/lotsp.htm#extractor Lotspe]
| Platform = DOS
| grp = Read
| map = No
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{EndFileFormatTools}}

{{BeginGameFileList}}
{{GameFile
| Name = 75m.exe 75t.exe laart000.dat ltart000.dat
| Format = [[EXE format]]
| KnownFormat = Yes
| Desc = Executables
}}
{{GameFile
| Name = l0art000.dat l1art000.dat
| Format = [[ART Format (Build)]]
| KnownFormat = Yes
| Desc = Level textures and sprites
}}
{{GameFile
| Name = lcart000.dat lfart000.dat lgart000.dat
| Format = [[FLIC Format]]
| KnownFormat = Yes
| Desc = Animations
}}
{{GameFile
| Name = lmart000.dat lvart000.dat
| Format = [[Legend of Seven Paladins 3D Archive Format]]
| KnownFormat = Yes
| Desc = Archive storing most of the game's data files
}}
{{GameFile
| Name = palette.dat
| Format = [[Palette Format (Build)]]
| KnownFormat = Yes
| Desc = Palettes, palettes swaps, shade and translucency (blending) tables
}}
{{GameFile
| Name = setup.dat
| Format = [[Legend of Seven Paladins 3D Settings Format]]
| KnownFormat = No
| Desc = Game settings
}}
{{GameFile
| Name = tables.dat
| Format = [[Tables Format (Build)]]
| KnownFormat = Yes
| Desc = Tables for sin, atn, large font, small font, gamma correction
}}
{{GameFile
| Name = *.map
| Format = [[Build-engine Map Format]]
| KnownFormat = Yes
| Desc = Game levels
}}
{{GameFile
| Name = *.mid
| Format = [[MID Format]]
| KnownFormat = Yes
| Desc = Background music
}}
{{GameFile
| Name = *.pal
| Format = [[VGA Palette]]
| KnownFormat = Yes
| Desc = 6-bit VGA Palette
}}
{{GameFile
| Name = *.pcx
| Format = [[PCX Format]]
| KnownFormat = Yes
| Desc = Full-screen images
}}
{{GameFile
| Name = *.voc
| Format = [[VOC Format]]
| KnownFormat = Yes
| Desc = Sound effects
}}
{{EndGameFileList}}

[[Category:3D]]
[[Category:First-Person Shooter]]
[[Category:Build engine]]

File:Legend of Seven Paladins 3D.png

2014-06-15T15:45:37Z

Frenkel:

[[Legend of Seven Paladins 3D]] title screen

[[Category:Game Title Screens]]

Category:Legend of Seven Paladins 3D

2014-06-15T09:27:16Z

Frenkel: Created page with "{{GameCategory}}"

File:Legend of Seven Paladins 3D.png

2014-06-15T09:25:27Z

Frenkel: Legend of Seven Paladins 3D title screen

[[Legend of Seven Paladins 3D]] title screen

Legend of Seven Paladins 3D

2014-06-15T09:18:53Z

Frenkel: Created new page for Legend of Seven Paladins 3D

{{Stub}}

{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}

[[Legend of Seven Paladins 3D]] is a first-person shooter and it's the first commercially released game that uses the [[:Category:Build engine|Build engine]].

== Tools ==

{{BeginFileFormatTools|Type=game}}
{{FileFormatTool
| Name = [http://sfprod.shikadi.net/old/games/lotsp.htm#extractor Lotspe]
| Platform = DOS
| grp = Read
| map = No
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{EndFileFormatTools}}

== File formats ==

This section lists the files and its formats used in the game.

=== Standalone files ===

{|class="wikitable"
! File name !! Description
|-
| <tt>75m.exe</tt> <tt>75t.exe</tt> <tt>laart000.dat</tt> <tt>ltart000.dat</tt>
| style="background: #FFCCCC;" | [[EXE Format]].
|-
| <tt>l0art000.dat</tt> <tt>l1art000.dat</tt>
| style="background: #CCFFCC;" | Game graphics in [[ART Format (Build)|ART Format]].
|-
| <tt>lcart000.dat</tt> <tt>lfart000.dat</tt> <tt>lgart000.dat</tt>
| style="background: #CCFFCC;" | Animations in [[Duke Nukem II Animation Format]].
|-
| <tt>lmart000.dat</tt> <tt>lvart000.dat</tt>
| style="background: #FFFFCC;" | Group file storing most of the game data in [[Legend of Seven Paladins 3D Group Format]].
|-
| <tt>palette.dat</tt>
| style="background: #FFCCCC;" | Palettes, palettes swaps, shade and translucency (blending) tables.
|-
| <tt>setup.dat</tt>
| style="background: #FFCCCC;" | Game settings.
|-
| <tt>tables.dat</tt>
| style="background: #FFCCCC;" | Tables for sin, atn, large font, small font, gamma correction.
|}

=== Files inside lmart000.dat ===

{|class="wikitable"
! File name !! Description
|-
| <tt>*.map</tt>
| style="background: #FFFFCC;" | Game levels in [[Map Format (Build)|Map Format]].
|}

=== Files inside lvart000.dat ===

{|class="wikitable"
! File name !! Description
|-
| <tt>*.mid</tt>
| style="background: #CCFFCC;" | Game music in [[MID Format]].
|-
| <tt>*.pal</tt>
| style="background: #CCFFCC;" | 6-bit [[VGA Palette]].
|-
| <tt>*.pcx</tt>
| style="background: #CCFFCC;" | Full-screen images in [[PCX Format]].
|-
| <tt>*.voc</tt>
| style="background: #CCFFCC;" | Game sounds in [[VOC Format]].
|}

[[Category:3D]]
[[Category:First-Person Shooter]]
[[Category:Build engine]]

Catacomb 3-D

2014-06-06T21:06:34Z

Frenkel: Source code released

{{Stub}}
{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}

Catacomb 3D is one of [[ID Software]]'s earliest attempts at a 3D game. It utilizes the [[Commander Keen 4-6]] engine, though with radically altered graphics.

The game is severely cut down, with limited sound effects, one music track and few graphics. The game has no storyline as such, the player wanders through various interconnected levels acquiring scrolls that further the story and provide hints. The relation of this game to others in the Catacomb series is not known.

== File formats ==

* [[AudioT Format]] - used for storing sound and music data
* [[EGAGraph Format]] - used for storing graphics, text and miscellaneous data
* [[GameMaps Format]] - used for storing level maps
* [[IMF Format]] - actual music is in IMF
* [[B800 Text]] - there are a couple of text screens in the main .EXE file (including the text displayed on the screen when you quit)

In addition the .EXE is compressed with [[LZEXE]], graphics and sounds are compressed using [[Huffman Compression]], and levels using [[RLE compression]] and Carmackization.

== Map Format ==

The maps use the [[GameMaps Format]]. Plane 0 defines the structure of the map and also certain specials, while Plane 2 is used for items, monsters and other interactive objects. Values over 255 are never used in either plane. Catacomb Abyss, Armageddon and Apocalypse are sometimes similar, but use a slightly more complicated system for locked doors, exploding walls and the like, so they must be treated separately. The map sizes can vary, but 40x28 is quite common.

Plane 0 Walls:
* 0x00 01: Rough Grey Block Wall
* 0x00 02: Slimy Brick Wall
* 0x00 03: Plain Light Brick Wall
* 0x00 04: Slimy Brick Wall + Blood
* 0x00 05: Tar Wall
* 0x00 06: Gold Brick Wall
* 0x00 07: Hellish Wall
* 0x00 08: Rough Grey Block Wall (Explodable)
* 0x00 09: Slimy Brick Wall (Explodable)
* 0x00 0A: Plain Light Brick Wall (Explodable)
* 0x00 0B: Slimy Brick Wall + Blood (Explodable)
* 0x00 0C: Tar Wall (Explodable)
* 0x00 0D: Gold Brick Wall (Explodable)
* 0x00 0E: Hellish Wall (Explodable)

Plane 0 Doors:
* 0x00 14: Red Door
* 0x00 18: Yellow Door
* 0x00 1C: Green Door
* 0x00 20: Blue Door

Plane 0 Floors:
Different floors have two uses: to define which area text to use, and, when placed under a plane 2 portal tile, to tell the game what level the portal should go to, starting at "Floor A" for level 1. "Floor I" under a portal, for instance, makes that portal take the player to level 9. A "No Text" floor under a portal makes that portal go to the next level in sequence. Floors can presumably go up to Z, but no stock map uses that many area messages nor are there that many levels in the stock game.
* 0x00 B4: Floor (No text)
* 0x00 B5: Floor A
* 0x00 B6: Floor B
* 0x00 B7: Floor C
* 0x00 B8: Floor D
* 0x00 B9: Floor E
* 0x00 BA: Floor F
* 0x00 BB: Floor G
* 0x00 BC: Floor H
* 0x00 BD: Floor I
* 0x00 BE: Floor J
* 0x00 BF: Floor K
* 0x00 C0: Floor L
* 0x00 C1: Floor M
* 0x00 C2: Floor N
* 0x00 C3: Floor O
* 0x00 C4: Floor P
* 0x00 C5: Floor Q

Plane 2 Player start positions:
* 0x00 01: Player Start (North)
* 0x00 02: Player Start (East)
* 0x00 03: Player Start (South)
* 0x00 04: Player Start (West)

Plane 2 Items:
* 0x00 05: Bolt
* 0x00 06: Nuke
* 0x00 07: Healing potion
* 0x00 08: Red Key
* 0x00 09: Yellow Key
* 0x00 0A: Green Key
* 0x00 0B: Blue Key
* 0x00 0C: Scroll #1
* 0x00 0D: Scroll #2
* 0x00 0E: Scroll #3
* 0x00 0F: Scroll #4
* 0x00 10: Scroll #5
* 0x00 11: Scroll #6
* 0x00 12: Scroll #7
* 0x00 13: Scroll #8
* 0x00 14: Grelminar (Ends game when "taken")
* 0x00 15: Treasure Chest (Bonus points)

Plane 2 monsters and other stuff:
These monster tiles appear on all skill levels.
* 0x00 16: Troll
* 0x00 17: Orc
* 0x00 18: Portal to another level (See notes in Plane 0 Floors section)
* 0x00 19: Bat
* 0x00 1A: Demon
* 0x00 1B: Mage
* 0x00 1C: Nemesis
* 0x00 1D: Bouncy Fireball (North-South)
* 0x00 1E: Bouncy Fireball (East-West)

Plane 2 teleports:
Teleports swap player between one and the other of the same type within one level. For instance, entering a Teleport A object sends the player to another Teleport A. They need open space around them, or the player can get stuck!
* 0x00 1F: Teleport A
* 0x00 20: Teleport B
* 0x00 21: Teleport C

Plane 2 monsters:
These appear only on certain skill levels.
* 0x00 24: Troll (Normal/Hard)
* 0x00 25: Orc (Normal/Hard)
* 0x00 26: Bat (Normal/Hard)
* 0x00 27: Demon (Normal/Hard)
* 0x00 28: Mage (Normal/Hard)
* 0x00 29: Troll (Hard mode only)
* 0x00 2A: Orc (Hard mode only)
* 0x00 2B: Bat (Hard mode only)
* 0x00 2C: Demon (Hard mode only)
* 0x00 2D: Mage (Hard mode only)

== Source code ==
The source code of this game was released by Flat Rock Software on June 6, 2014. It can be downloaded from [http://github.com/FlatRockSoft/Catacomb3D GitHub].

[[Category:id Software]]
[[Category:Softdisk]]

Hovertank 3-D

2014-06-06T21:03:55Z

Frenkel: Source code released

{{NeedMoreInfo}}
{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}

'''Hovertank 3-D''' is one of the first FPS games and the direct ancestor of most FPS games. It has EGA graphics with no textures, but with scaled sprites. Like the later [[Wolfenstein 3D]], this game includes different brightnesses of the same tile when viewed from the N/S or E/W.

It was followed by [[Catacomb 3D]], which added textures.

== File formats ==

{|class="wikitable"
!File name!!Description
|-
| <tt>levelXX.hov</tt>
| style="background: #CCFFCC;" | Game levels in [[Commander Keen 1-3 Level format]]. They use [[RLEW compression]] with the tag $FEFE.
|-
| <tt>sounds.hov</tt>
| style="background: #CCFFCC;" | PC speaker sounds in [[Inverse Frequency Sound format]]
|-
| <tt>dsound.hov</tt>
| style="background: #FFFFCC;" | Digitised sounds (see below)
|}

== Digitised sounds ==

<tt>dsound.hov</tt> begins with the following structure repeated once for each sound in the file.

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT32LE]] || offset || Offset of sound data from start of file
|-
| [[UINT32LE]] || length || Length of sound data in bytes
|-
| [[UINT32LE]] || samplerate? || Possibly the sample rate of the sound
|-
| [[UINT16LE]] || flags || See [[Inverse Frequency Sound format]]
|}

The sound data immediately follows. The offset of the first file can be used to discover the number of sounds in the file (either by reading the header up until this point, or dividing the first file's offset by 14.)

== Source code ==
The source code of this game was released by Flat Rock Software on June 4, 2014. It can be downloaded from [http://github.com/FlatRockSoft/Hovertank3D GitHub].

Catacomb II

2014-06-06T21:01:18Z

Frenkel: Source code released

{{Stub}}
{{Game Infobox
| Levels = No
| Tiles = Edit
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = None
| Text = No
| Story = None
| Interface = No
}}

'''Catacomb II''' is a top-down Gauntlet-style shooter, following on from [[Catacomb]]. It was later renamed to ''The Catacomb''.

== Tools ==

{{BeginFileFormatTools|Type=game}}
{{FileFormatTool
| Name = [[Camoto]]
| Platform = Linux/Windows
| grp = N/A
| map = No
| gfx = Tileset
| mus = N/A
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{EndFileFormatTools}}

 
== File formats ==

{|class="wikitable"
!File name!!Description
|-
| <tt>LEVEL#.CA2</tt>
| style="background: #CCFFCC;" | Game levels in [[Catacomb Map Format]]
|-
| <tt>SCORES.CA2</tt>
| style="background: #CCFFCC;" | High scores in [[Catacomb Highscore Format]]
|-
| <tt>GAME#.CA2</tt>
| style="background: #FFFFCC;" | Saved games in [[Catacomb Savegame Format]]
|-
| <tt>SOUNDS.CA2</tt>
| style="background: #CCFFCC;" | PC speaker sounds in [[Inverse Frequency Sound format]]
|-
|<tt>EGACHARS.CA2</tt> <tt>CGACHARS.CA2</tt>
| style="background: #CCFFCC;" | Tile graphics for levels in [[xGAChars Format]]
|-
|<tt>EGAPICS.CA2</tt> <tt>CGAPICS.CA2</tt>
| style="background: #CCFFCC;" | Other graphics in [[DDiCI_Graphics_format|xGAPics Format]]
|}

== Source code ==
The source code of this game was released by Flat Rock Software on June 6, 2014. It can be downloaded from [http://github.com/FlatRockSoft/TheCatacomb GitHub].

== See also ==

* More detail at [[Catacomb]], which shares the same engine.

[[Category:Softdisk]]

Catacomb

2014-06-06T20:59:50Z

Frenkel: Source code released

{{Game Infobox
| Levels = No
| Tiles = Edit
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = None
| Text = No
| Story = None
| Interface = No
}}

'''Catacomb''' and [[Catacomb II]] are top-down Gauntlet-style shooters. They are two of ID software's earliest games.
They are the direct ancestors of most First Person Shooters. They introduced strafing.

Catacomb was distributed on the same Gamer's Edge disk as [[Dangerous Dave]].

They are part of series of 6 games, in two trilogies:
* Catacomb I
* [[Catacomb II]]
* [[Catacomb 3-D]]
* [[Catacomb Abyss]]
* [[Catacomb Armageddon]]
* [[Catacomb Apocalypse]]

It evolved like this: [[Catacomb]] + [[Hovertank]] -> [[Catacomb 3-D]] -> [[Catacomb Abyss]] -> [[Wolfenstein 3-D]] -> [[Doom]] -> [[Quake]]

== Tools ==

{{BeginFileFormatTools|Type=game}}
{{FileFormatTool
| Name = [[Camoto]]
| Platform = Linux/Windows
| grp = N/A
| map = No
| gfx = Tileset
| mus = N/A
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{EndFileFormatTools}}

 
== File formats ==

{|class="wikitable"
!File name!!Description
|-
| <tt>LEVEL#.CAT</tt>
| style="background: #CCFFCC;" | Game levels in [[Catacomb Map Format]]
|-
| <tt>TOPSCORS.CAT</tt>
| style="background: #CCFFCC;" | High scores in [[Catacomb Highscore Format]]
|-
| <tt>SOUNDS.CAT</tt>
| style="background: #CCFFCC;" | PC speaker sounds in [[Inverse Frequency Sound format]]
|-
|<tt>CGACHARS.CAT</tt> <tt>EGACHARS.CAT</tt>
| style="background: #CCFFCC;" | Tile graphics for levels in [[Catacomb Tileset Format]], stored in the main .exe file
|-
|<tt>TITLE.PIC</tt> <tt>END.PIC</tt>
| style="background: #CCFFCC;" | Other graphics in [[PIC Format]], stored in the main .exe file
|}

All graphics files are stored in the EXE. Their location in the ''decompressed'' executable is as follows:

{|class="wikitable"
! Location !! Size !! Description
|-
| 0x00006100 || 0xB6C0 || EGACHARS.CAT
|-
| 0x000117D0 || 0x5B60 || CGACHARS.CAT
|-
| 0x00017997 || 0x4000 || TITLE.PIC
|-
| 0x0001B997 || 0x4000 || END.PIC
|}

Note that these offsets only apply when using [[UNLZEXE]] (other programs will produce different offsets.)

== Source code ==
The source code of this game was released by Flat Rock Software on June 5, 2014. It can be downloaded from [http://github.com/FlatRockSoft/Catacomb GitHub].

[[Category:Softdisk]]

EPF Format

2013-11-22T16:38:46Z

Frenkel: Added game Speed Demons

{{Archive Infobox
| MaxFiles = 65,535
| FAT = End
| Names = Yes, 8.3
| Metadata = None
| Subdirectories = N
| Compressed = Y
| Encrypted = N
| Hidden = N
| Game1 = Alien Breed Tower Assault
| Game2 = Arcade Pool
| Game3 = Mr Blobby
| Game4 = Overdrive
| Game5 = Project X
| Game6 = Sensible Golf
| Game7 = Speed Demons
| Game8 = Spirou
| Game9 = The Adventures of Tintin: Prisoners of the Sun
| Game10 = The Jungle Book
| Game11 = The Lion King
| Game12 = The Smurfs
| Game13 = Tin Tin in Tibet
| Game14 = Universe
}}
The EPF file format is used in many games, like:

Some (all?) of these games are made by East Point Software, so EPF (a shortened version of "EPFS" from the file header) probably stands for East Point File System or something similar.

== File format ==

=== Signature ===

The first four bytes in the file are "EPFS", followed by a UINT32LE offset (so that value must be smaller than the total file size.)

=== Header ===

{|class="wikitable"
!Data type!!Description
|-
|BYTE signature[4]||"EPFS"
|-
|UINT32LE fatOffset||Offset of the FAT
|-
|UINT8 unknown||{{TODO|Unknown, always zero - flags?}}
|-
|UINT16LE numFiles||Number of files
|}

The data for the first file starts immediately after the header (i.e. file offset 11.)

=== File entry ===

At offset <tt>fatOffset</tt> sits a list of file entries. The following structure is repeated until the end of the file.

{|class="wikitable"
!Data type!!Description
|-
|BYTE filename[13]||Filename (NULL-terminated)
|-
|UINT8 compressionFlag||0 for "file is not compressed", 1 for "file is compressed"
|-
|UINT32LE compressedSize||size of the compressed file
|-
|UINT32LE decompressedSize||size of the file after decompression
|}

In order to calculate the offset of each file, a running total is required. It should start at offset 11 (just after the header), then the <tt>compressedSize</tt> should be added to reveal the offset of the next file.

=== Compression ===

The compression scheme is [[LZW compression|LZW]], with a dynamic bit length from 9 to 14.

The bits are stored in big-endian byte order, in contrast to e.g. Apogee/id LZW. For example:

12 34 56 // bytes in compressed data file
00010010 00110100 01010110 // converted to 8-bit binary
000100100 011010001 010110 // bits read in big-endian order (Lion King)
000010010 100011010 010101 // bits read in little-endian order (id/Apogee)
^...go here ^bits from here...

Although it uses a "normal" LZW algorithm, there are a few differences:

* There are no reserved codewords at the beginning of the dictionary, so the first valid (9-bit) codeword is 0x100.
* When the dictionary is reset, the bit length is unchanged.
* The two largest possible codewords (at the current bit length) are reserved. The largest codeword is used to signify the end of the data, and the second largest codeword is used to reset the dictionary.
* Once the third-largest codeword is encountered and processed (this is the largest valid/non-reserved codeword - 1021 for 10-bit codes) the bit length is incremented.

The reserved codewords deserve a little extra explanation. For a 10-bit codeword length, the largest possible value that can fit in ten bits is (1<<10)-1 == 1023, so a codeword of 1023 signifies the end of the data. A codeword of 1022 (one less than the maximum) will reset the dictionary, but leave the codeword length unchanged (10-bits in this example), although in reality it would not make sense to encounter a dictionary-reset codeword until the dictionary has reached its maximum size, i.e. 14-bit codewords are in use.

Keep in mind that these reserved codewords must be processed before the LZW decoder sees them, otherwise it will treat them as lookups into the dictionary, resulting in out of range accesses. Also remember that once the bit length increases, the two reserved codewords will change, as the maximum codeword value has increased. This frees up the "old" reserved codewords which are then used as normal codewords.

At least one EPF file (OVER.EPF from the game "Overdrive") contains corrupted files (4X43.MAP and 4X44.MAP), apparently due to a bug in the original compression algorithm when the files were created. No tools are able to extract these files, and the levels are unplayable in the game (which crashes with an error.)

== Tools ==

{{BeginFileFormatTools|Type=group}}
{{FileFormatTool
| Name = [[Camoto]]
| Platform = Linux/Windows
| canExtract = Yes
| canDecompress = Yes
| canCreate = Yes
| canModify = Yes
| canCompress = No
| editHidden = Yes
| editMetadata = N/A
}}
{{EndFileFormatTools}}

EPF Format

2013-11-22T16:17:10Z

Frenkel: Added game The Adventures of Tintin: Prisoners of the Sun

{{Archive Infobox
| MaxFiles = 65,535
| FAT = End
| Names = Yes, 8.3
| Metadata = None
| Subdirectories = N
| Compressed = Y
| Encrypted = N
| Hidden = N
| Game1 = Alien Breed Tower Assault
| Game2 = Arcade Pool
| Game3 = Mr Blobby
| Game4 = Overdrive
| Game5 = Project X
| Game6 = Sensible Golf
| Game7 = Spirou
| Game8 = The Adventures of Tintin: Prisoners of the Sun
| Game9 = The Jungle Book
| Game10 = The Lion King
| Game11 = The Smurfs
| Game12 = Tin Tin in Tibet
| Game13 = Universe
}}
The EPF file format is used in many games, like:

Some (all?) of these games are made by East Point Software, so EPF (a shortened version of "EPFS" from the file header) probably stands for East Point File System or something similar.

== File format ==

=== Signature ===

The first four bytes in the file are "EPFS", followed by a UINT32LE offset (so that value must be smaller than the total file size.)

=== Header ===

{|class="wikitable"
!Data type!!Description
|-
|BYTE signature[4]||"EPFS"
|-
|UINT32LE fatOffset||Offset of the FAT
|-
|UINT8 unknown||{{TODO|Unknown, always zero - flags?}}
|-
|UINT16LE numFiles||Number of files
|}

The data for the first file starts immediately after the header (i.e. file offset 11.)

=== File entry ===

At offset <tt>fatOffset</tt> sits a list of file entries. The following structure is repeated until the end of the file.

{|class="wikitable"
!Data type!!Description
|-
|BYTE filename[13]||Filename (NULL-terminated)
|-
|UINT8 compressionFlag||0 for "file is not compressed", 1 for "file is compressed"
|-
|UINT32LE compressedSize||size of the compressed file
|-
|UINT32LE decompressedSize||size of the file after decompression
|}

In order to calculate the offset of each file, a running total is required. It should start at offset 11 (just after the header), then the <tt>compressedSize</tt> should be added to reveal the offset of the next file.

=== Compression ===

The compression scheme is [[LZW compression|LZW]], with a dynamic bit length from 9 to 14.

The bits are stored in big-endian byte order, in contrast to e.g. Apogee/id LZW. For example:

12 34 56 // bytes in compressed data file
00010010 00110100 01010110 // converted to 8-bit binary
000100100 011010001 010110 // bits read in big-endian order (Lion King)
000010010 100011010 010101 // bits read in little-endian order (id/Apogee)
^...go here ^bits from here...

Although it uses a "normal" LZW algorithm, there are a few differences:

* There are no reserved codewords at the beginning of the dictionary, so the first valid (9-bit) codeword is 0x100.
* When the dictionary is reset, the bit length is unchanged.
* The two largest possible codewords (at the current bit length) are reserved. The largest codeword is used to signify the end of the data, and the second largest codeword is used to reset the dictionary.
* Once the third-largest codeword is encountered and processed (this is the largest valid/non-reserved codeword - 1021 for 10-bit codes) the bit length is incremented.

The reserved codewords deserve a little extra explanation. For a 10-bit codeword length, the largest possible value that can fit in ten bits is (1<<10)-1 == 1023, so a codeword of 1023 signifies the end of the data. A codeword of 1022 (one less than the maximum) will reset the dictionary, but leave the codeword length unchanged (10-bits in this example), although in reality it would not make sense to encounter a dictionary-reset codeword until the dictionary has reached its maximum size, i.e. 14-bit codewords are in use.

Keep in mind that these reserved codewords must be processed before the LZW decoder sees them, otherwise it will treat them as lookups into the dictionary, resulting in out of range accesses. Also remember that once the bit length increases, the two reserved codewords will change, as the maximum codeword value has increased. This frees up the "old" reserved codewords which are then used as normal codewords.

At least one EPF file (OVER.EPF from the game "Overdrive") contains corrupted files (4X43.MAP and 4X44.MAP), apparently due to a bug in the original compression algorithm when the files were created. No tools are able to extract these files, and the levels are unplayable in the game (which crashes with an error.)

== Tools ==

{{BeginFileFormatTools|Type=group}}
{{FileFormatTool
| Name = [[Camoto]]
| Platform = Linux/Windows
| canExtract = Yes
| canDecompress = Yes
| canCreate = Yes
| canModify = Yes
| canCompress = No
| editHidden = Yes
| editMetadata = N/A
}}
{{EndFileFormatTools}}

EPF Format

2013-11-22T16:04:50Z

Frenkel: Added game Mr Blobby

{{Archive Infobox
| MaxFiles = 65,535
| FAT = End
| Names = Yes, 8.3
| Metadata = None
| Subdirectories = N
| Compressed = Y
| Encrypted = N
| Hidden = N
| Game1 = Alien Breed Tower Assault
| Game2 = Arcade Pool
| Game3 = Mr Blobby
| Game4 = Overdrive
| Game5 = Project X
| Game6 = Sensible Golf
| Game7 = Spirou
| Game8 = The Jungle Book
| Game9 = The Lion King
| Game10 = The Smurfs
| Game11 = Tin Tin in Tibet
| Game12 = Universe
}}
The EPF file format is used in many games, like:

Some (all?) of these games are made by East Point Software, so EPF (a shortened version of "EPFS" from the file header) probably stands for East Point File System or something similar.

== File format ==

=== Signature ===

The first four bytes in the file are "EPFS", followed by a UINT32LE offset (so that value must be smaller than the total file size.)

=== Header ===

{|class="wikitable"
!Data type!!Description
|-
|BYTE signature[4]||"EPFS"
|-
|UINT32LE fatOffset||Offset of the FAT
|-
|UINT8 unknown||{{TODO|Unknown, always zero - flags?}}
|-
|UINT16LE numFiles||Number of files
|}

The data for the first file starts immediately after the header (i.e. file offset 11.)

=== File entry ===

At offset <tt>fatOffset</tt> sits a list of file entries. The following structure is repeated until the end of the file.

{|class="wikitable"
!Data type!!Description
|-
|BYTE filename[13]||Filename (NULL-terminated)
|-
|UINT8 compressionFlag||0 for "file is not compressed", 1 for "file is compressed"
|-
|UINT32LE compressedSize||size of the compressed file
|-
|UINT32LE decompressedSize||size of the file after decompression
|}

In order to calculate the offset of each file, a running total is required. It should start at offset 11 (just after the header), then the <tt>compressedSize</tt> should be added to reveal the offset of the next file.

=== Compression ===

The compression scheme is [[LZW compression|LZW]], with a dynamic bit length from 9 to 14.

The bits are stored in big-endian byte order, in contrast to e.g. Apogee/id LZW. For example:

12 34 56 // bytes in compressed data file
00010010 00110100 01010110 // converted to 8-bit binary
000100100 011010001 010110 // bits read in big-endian order (Lion King)
000010010 100011010 010101 // bits read in little-endian order (id/Apogee)
^...go here ^bits from here...

Although it uses a "normal" LZW algorithm, there are a few differences:

* There are no reserved codewords at the beginning of the dictionary, so the first valid (9-bit) codeword is 0x100.
* When the dictionary is reset, the bit length is unchanged.
* The two largest possible codewords (at the current bit length) are reserved. The largest codeword is used to signify the end of the data, and the second largest codeword is used to reset the dictionary.
* Once the third-largest codeword is encountered and processed (this is the largest valid/non-reserved codeword - 1021 for 10-bit codes) the bit length is incremented.

The reserved codewords deserve a little extra explanation. For a 10-bit codeword length, the largest possible value that can fit in ten bits is (1<<10)-1 == 1023, so a codeword of 1023 signifies the end of the data. A codeword of 1022 (one less than the maximum) will reset the dictionary, but leave the codeword length unchanged (10-bits in this example), although in reality it would not make sense to encounter a dictionary-reset codeword until the dictionary has reached its maximum size, i.e. 14-bit codewords are in use.

Keep in mind that these reserved codewords must be processed before the LZW decoder sees them, otherwise it will treat them as lookups into the dictionary, resulting in out of range accesses. Also remember that once the bit length increases, the two reserved codewords will change, as the maximum codeword value has increased. This frees up the "old" reserved codewords which are then used as normal codewords.

At least one EPF file (OVER.EPF from the game "Overdrive") contains corrupted files (4X43.MAP and 4X44.MAP), apparently due to a bug in the original compression algorithm when the files were created. No tools are able to extract these files, and the levels are unplayable in the game (which crashes with an error.)

== Tools ==

{{BeginFileFormatTools|Type=group}}
{{FileFormatTool
| Name = [[Camoto]]
| Platform = Linux/Windows
| canExtract = Yes
| canDecompress = Yes
| canCreate = Yes
| canModify = Yes
| canCompress = No
| editHidden = Yes
| editMetadata = N/A
}}
{{EndFileFormatTools}}

B800 Text

2013-11-18T14:41:35Z

Frenkel: /* File format */ The original CGA can display high intensity background colours. Otherwise the 160x100 16 colour mode is not possible.

{{Image Infobox
| Hardware1 = CGA
| Hardware2 = EGA
| Hardware3 = VGA
| Depth = 4-bit
| MinSize = 80×25 cells
| MaxSize = 80×25 cells
| NumPlanes = 2 
| HasTransparency = No
| HasHitmap = No

}}

'''B800 Text''' is a text-mode screen dump, and under x86 real mode (such as used by DOS) can be copied byte for byte into video memory starting at <tt>B800:0000</tt>, causing the data to appear on the screen when the video card is in text mode. It is most often used to display the final text screen after quitting a game, with the DOS prompt appearing on the last line once the game has terminated.

== File format ==

{| style="border-style: none; float: right; clear: right; margin-left: 1.5em; text-align:center; hspace=10px" border="1" cellpadding="5"
! colspan="2" | <nowiki>Full CGA 16-color palette</nowiki>
|-
| style="color: white; background-color: #000000" | 0 — black <nowiki>#000000</nowiki>
| style="color: white; background-color: #555555" | 8 — (dark) gray <nowiki>#555555</nowiki>
|-
| style="color: white; background-color: #0000AA" | 1 — blue <nowiki>#0000AA</nowiki>
| style="color: white; background-color: #5555FF" | 9 — bright blue <nowiki>#5555FF</nowiki>
|-
| style="color: white; background-color: #00AA00" | 2 — green <nowiki>#00AA00</nowiki>
| style="color: black; background-color: #55FF55" | 10 — bright green <nowiki>#55FF55</nowiki>
|-
| style="color: white; background-color: #00AAAA" | 3 — cyan <nowiki>#00AAAA</nowiki>
| style="color: black; background-color: #55FFFF" | 11 — bright cyan <nowiki>#55FFFF</nowiki>
|-
| style="color: white; background-color: #AA0000" | 4 — red <nowiki>#AA0000</nowiki>
| style="color: black; background-color: #FF5555" | 12 — bright red <nowiki>#FF5555</nowiki>
|-
| style="color: white; background-color: #AA00AA" | 5 — magenta <nowiki>#AA00AA</nowiki>
| style="color: black; background-color: #FF55FF" | 13 — bright magenta <nowiki>#FF55FF</nowiki>
|-
| style="color: white; background-color: #AA5500" | 6 — brown <nowiki>#AA5500</nowiki>
| style="color: black; background-color: #FFFF55" | 14 — yellow <nowiki>#FFFF55</nowiki>
|-
| style="color: black; background-color: #AAAAAA" | 7 — white (light gray) <nowiki>#AAAAAA</nowiki>
| style="color: black; background-color: #FFFFFF" | 15 — bright white <nowiki>#FFFFFF</nowiki>
|}

Since the file format is just a direct dump of video memory, this would more accurately be termed the "CGA text mode format." The file is almost always 4000 bytes long, as this is the exact amount of space required to store a standard 80x25 text screen (80 columns * 25 rows * two bytes per cell == 4000 bytes.)

The data is arranged in cells, with each cell being two bytes long (one byte for the ASCII character to display, followed by an attribute byte indicating the colour of the character.) The data appears starting at the top-left of the screen (1,1) and works its way across to the right (80,1) and then wraps down to the next line (1,2).

The attribute byte contains two nybbles of data. The most significant four bits are the background colour, and the least significant bits are the foreground colour. This means the background and foreground colours can each be assigned a colour value between zero (black) and 15 (white) - see the table on the right for the full list of colours.

The background colour is slightly different however. By default, the intensity bit is used to cause the text to flash instead. This means setting the background colour to 14 won't produce a bright-yellow background, but instead will produce a normal yellow background (colour #6) with blinking text. The CGA standard includes a toggle bit that allows this flashing to be switched off, thus allowing the full 16 background colours to be used (without any flashing of course.)

== Example ==

As a demonstration, these bytes:

<pre>
48 1E 65 2E 6C 3E 6C 4E 6F 5E H.e.l.l.o.
</pre>

Would appear like this:

<div style="background-color: black; padding: 4px; font-size: 14pt; width: 20em;"><tt>
 Hello
</tt></div>

== Tools ==

The following tools are known to work with this format:

* [http://en.wikipedia.org/wiki/TheDraw TheDraw] - DOS-based text animation/screen editor, which does support B800 text and many other DOS formats. TheDraw also runs under DOSBox.
* [http://www.theabsolute.net/sware/oldfav.html TextPaint] - DOS-based text screen editor, which unfortunately doesn't support B800 text but is still very powerful, and useful enough to warrant a mention.
* [http://dlc.softwareload.de/SHMANSi/5597 Shmansi] - Another DOS-based text screen editor, which can import and export B800 text.
* [http://www.doomworld.com/idgames/index.php?id=3692 ENDOOMER]- Yet another DOS-based text screen editor, which can import and export B800 text, and can be used with the mouse as well.

== See also ==

* [[Wikipedia:Color Graphics Adapter]] - lots of interesting information about the CGA hardware
* [[Wikipedia:ANSI art]] - An article about ANSI art


[[Category:Blake Stone]]
[[Category:Boppin']]
[[Category:Commander Keen 1-3]]
[[Category:Commander Keen Dreams]]
[[Category:Commander Keen 4-6]]
[[Category:Cosmo's Cosmic Adventures]]
[[Category:Crystal Caves]]
[[Category:Descent]]
[[Category:Duke Nukem II]]
[[Category:Duke Nukem 3D]]
[[Category:Halloween Harry]]
[[Category:Hocus Pocus]]
[[Category:Jill of the Jungle]]
[[Category:Kiloblaster]]
[[Category:Major Stryker]]
[[Category:Monster Bash]]
[[Category:Raptor]]
[[Category:Rise of the Triad]]
[[Category:Secret Agent]]
[[Category:Terminal Velocity]]
[[Category:Vinyl Goddess From Mars]]
[[Category:Wacky Wheels]]
[[Category:Wolfenstein 3-D]]
[[Category:Xargon]]
[[Category:Zone 66]]

User talk:Frenkel

2013-08-14T20:40:00Z

Frenkel: /* ProGraphx map formats */ More questions than answers

== ProGraphx map formats ==

Hi Frenkel. I'm just looking at [[Crystal Caves Map Format]], [[Secret Agent Level Format]] and [[Dark Ages Map Format]], and wondering whether it would be possible to write a single level reader/writer that could handle all three formats. What do you think? The major differences I can think of are that SA can have multiple layers and the background can be set in the level file itself, but is that all the differences? I'm just thinking that given the complexity of mapping codes to tile images, maybe that code could be shared between the map formats, with just a different list of tile mappings for each game. Any thoughts? -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 09:55, 11 August 2013 (GMT)

:What about the [[Duke 1 Level Format]]? Does it also need a special tile mapping algorithm? I haven't checked that. But I do know that just like Dark Ages it has only one plane and that every special/enemy tile uses the tile before/after/above it as its background.
:Oh, and the Crystal Caves Map Format is just weird :).[[User:Frenkel|Frenkel]] ([[User talk:Frenkel|talk]]) 20:40, 14 August 2013 (GMT)

File:Secret Agent Level Format.png

2013-08-14T20:05:46Z

Frenkel: Secret Agent episode 1 level 3

Secret Agent episode 1 level 3

Dark Ages Map Format

2013-08-04T22:45:35Z

Frenkel: /* Map codes */ Only map codes [100, 144) need a lookup table.

{{NeedMoreInfo}}
{{Map Infobox
| Type = 2D tile-based
| Layers = 1
| Tile size = 16×16
| Viewport = 240×144
| Game1 = Dark Ages
}}

This format is used by [[Dark Ages]] to store game levels. It is stored as <tt>file05.da[123]</tt>.

== Signature ==

There is no header or signature in the file. Each level is 1152 bytes long, so the file must be a multiple of this size. Since the game has 10 levels, all the files are 11,520 bytes long.

== Format ==

All levels in the episode are stored in the same file, one after the other. Each level is 128 cells wide and 9 cells high. Each cell occupies one byte in the map file, so each level takes up 1152 bytes (128 × 9).

=== Map codes ===

Map code 0 maps to the first image in the first tileset, 1 maps to the second image in the first tileset. Map code 50 maps to the first image in the second tileset, etc. This is true for all 256 map codes, except for map codes 100 through 143 inclusive. Those map codes must be mapped back to images manually, via a lookup table. Lookup tables are available in those level editors/viewers that include source code.

== Credits ==

This file format was reverse engineered by [[User:Frenkel|Frenkel]]. 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!)

File:Dark Ages Map Format.png

2013-08-04T22:19:04Z

Frenkel: Dark Ages episode 1, level 1. Created with DOSBox and Daview. Notice that enemies and coins don't have a background and the old man occupies only 1 cell instead of 2. Category:Map images

[[Dark Ages]] episode 1, level 1.

Created with DOSBox and Daview. Notice that enemies and coins don't have a background and the old man occupies only 1 cell instead of 2.

[[Category:Map images]]

Crystal Caves Map Format

2013-08-04T22:04:54Z

Frenkel: Viewport changed from 320x200 to 320x192

{{NeedMoreInfo}}
{{Map Infobox
| Type = 2D tile-based
| Layers = 1
| Tile size = 16×16
| Viewport = 320×192
| Game1 = Crystal Caves
}}
The ''Crystal Caves Map Format'' describes a particular section of data within the main [[Crystal Caves]] executable file, where the game levels are stored. Each level is 40 tiles wide and a varying number of tiles high.

== Location ==

The levels are stored inside the executable. To view them, the executable must be decompressed (UNP'd; [[UNLZEXE]] works fine for this.) After decompression, the levels for episodes 1 and 2 are stored at offset 0x8C30 (seg000:7332) or 0x8CE0 (depending on the decompression utility) and take up just under 17kB of space. The levels for episode 3 are stored at offset 0x8F24 in the UNLZEXE'd executable.

There are 19 levels, including the main map and two story levels (used at the start and end of the game.) Each level is stored in order, beginning with the introduction/story, finale/story, main map, then level 1, 2, 3, etc.

The number of rows for each map is hard-coded into the executable as machine instructions, not as an array of heights for each level. In addition, some maps can use data from other maps (in most cases the first or the last row) or use two data-rows to produce a single row on the map. Practically, this makes it very hard to increase a level's height and causes a lot of restrictions to modifying the maps. The levels (not counting Intro and Finale) are all sized 40 x 24 tiles and it is believed that each level uses 24 rows of data, with the following exceptions:

{|class="wikitable"
! Level !! Rows of data
|-
| Intro || 5
|-
| Finale || 6
|-
| Main map || 25
|-
| Level 7 || 23
|-
| Level 8 || 23
|-
| Level 14 || 23
|}

== Format ==

Each map is made up of a variable number of Pascal-style strings, one for each row. This string format contains no terminating 0x00, but rather stores the string length in the first byte. Thus each row of each level begins with the byte 0x28 (decimal 40, the map width.) Each subsequent byte in the string represents a single 16x16 tile.

=== Map codes ===

Unfortunately map codes cannot be converted into tileset indices automatically. This is because the maps were almost certainly designed by hand in a hex editor, without the use of a specific level editing program. Thus the codes were chosen to make some sense to a human, and the game uses some logic to convert the codes into tiles when levels are loaded.

This makes it quite challenging to write a level editor, as despite the map format containing one byte for each tile in the map, many bytes affect the surrounding tiles. For example the "[" character denotes a sign, and if it is followed by a "d" then the two cells will be occupied by a "danger" sign. But if the character following "[" is a "g", a 3×2 cell green box with a yellow border will be inserted instead, assuming the remaining area in the 3×2 space is filled with the letter "n" (which is widely used as a generic "show next tile" code.)

The tiles to use for platforms in a level (including the colour of steel girders and other elements) are set outside the level file in an unknown location. The level codes are relative references to this base value. This means a level can be easily changed from having blue platforms to red ones, brown ones, or blue rocks instead, without changing any level codes in the file.

Unfortunately it is not known where these values are actually set, so for the time being each level is stuck with whatever structural tileset it has in the original game.

==== BlitzMax Code ====

This is the code of a very simple map viewer for Crystal Caves. You need to convert the tile graphics from <tt>CC1.GFX</tt> to PNG with [[Wombat]] and UNLZEXE the executable to use this code.

<pre>
'Crystal Caves Map Viewer
'by K1n9_Duk3

SuperStrict

Local TileImg:TImage = LoadAnimImage("cc1.gfx.png", 16, 16, 0, 1150)
Local in:TStream = ReadFile("CC1-UNLZ.EXE")
Local Maps:Byte[800, 40]

Local MaxY:Int

If in
SeekStream(in, $8ce0) 'CC1 & CC2
' SeekStream(in, $8f24) 'CC3
Local y:Int
Repeat
If ReadByte(in) <> 40 Then Exit

Local s$ = ""
For Local x:Int = 0 Until 40
Local b:Byte = ReadByte(in)
Maps[y, x] = b
Next
y :+ 1

MaxY = y
Forever
CloseFile(in)
Else
End
EndIf

AppTitle = "Crystal Caves Map Viewer"
Graphics 640, 480

SetClsColor(128, 128, 128)

Local CamY:Int
Local Textmode:Byte

Repeat
Cls
For Local y:Int = 0 Until 30
For Local x:Int = 0 Until 40
Local MapTile:Byte = Maps[y+CamY, x]
Local TileIndex:Int = -1

Select MapTile

'Crystals (indices for CC1):
Case $52 TileIndex = 600
Case $2B TileIndex = 601
Case $62 TileIndex = 602
Case $63 TileIndex = 603

'Walls (indices for magenta walls):
Case $72 TileIndex = 1100
Case $74 TileIndex = 1101
Case $79 TileIndex = 1102
Case $66 TileIndex = 1104
Case $67 TileIndex = 1105
Case $68 TileIndex = 1106
Case $34 TileIndex = 1108
Case $35 TileIndex = 1109
Case $36 TileIndex = 1110

'Metal beams (indices for blue beams):
Case $44 TileIndex = 953
Case $64 TileIndex = 954
Case $98 TileIndex = 953 'with hidden crystal
Case $99 TileIndex = 954 'with hidden crystal
Case $9A TileIndex = 955 'with hidden crystal

'Small platform (blue index):
Case $5F TileIndex = 950

'Other Stuff:
Case $21 TileIndex = 650
Case $22 TileIndex = 630
Case $23 TileIndex = 124
Case $24 TileIndex = 860
Case $25 TileIndex = 539
Case $26 TileIndex = 662
Case $28 TileIndex = 184
Case $29 TileIndex = 185
Case $2A TileIndex = 105
Case $2C TileIndex = 537
Case $2D TileIndex = 536
Case $2E TileIndex = 538
Case $2F TileIndex = 480
Case $30 TileIndex = 43
Case $38 TileIndex = 34
Case $39 TileIndex = 96
Case $3A TileIndex = 629
Case $3D TileIndex = 689
Case $3F TileIndex = 50
Case $41 TileIndex = 882
Case $42 TileIndex = 6
Case $45 TileIndex = 680
Case $46 TileIndex = 470
Case $47 TileIndex = 298
Case $48 TileIndex = 590
Case $49 TileIndex = 233
Case $4A TileIndex = 453
Case $4B TileIndex = 1050
Case $4C TileIndex = 1051
Case $4D TileIndex = 300
Case $53 TileIndex = 154
Case $56, $D7, $D6 TileIndex = 594
Case $57 TileIndex = 150
Case $58 TileIndex = 562
Case $59 TileIndex = 250
Case $5D TileIndex = 299
Case $5E TileIndex = 201
Case $61, $71, $82 TileIndex = 560
Case $69 TileIndex = 674
Case $6A TileIndex = 605
Case $6B TileIndex = 1052
Case $6C TileIndex = 1053
Case $6F TileIndex = 100
Case $70 TileIndex = 604
Case $73, $77, $84 TileIndex = 559
Case $76 TileIndex = 580
Case $78 TileIndex = 12
Case $7C TileIndex = 184
Case $7E TileIndex = 212
Case $85
TileIndex = 427
If Maps[y+CamY+1, x] <> $85 Then TileIndex = 431
Case $86
TileIndex = 422
If Maps[y+CamY+1, x] <> $86 Then TileIndex = 423
Case $87
TileIndex = 0
If Maps[y+CamY+1, x] <> $87 Then TileIndex = 4
Case $88
TileIndex = 1
If Maps[y+CamY+1, x] <> $88 Then TileIndex = 5
Case $89 TileIndex = 558
Case $8A TileIndex = 554
Case $8B TileIndex = 3
Case $8C TileIndex = 587
Case $90 TileIndex = 386
Case $91 TileIndex = 499
Case $92 TileIndex = 476
Case $93 TileIndex = 477
Case $94 TileIndex = 378
Case $95 TileIndex = 379
Case $A0 TileIndex = 416
Case $A1 TileIndex = 420
Case $A2 TileIndex = 418
Case $A3 TileIndex = 424
Case $A4 TileIndex = 426
Case $A5 TileIndex = 425
Case $A6 TileIndex = 414
Case $A7 TileIndex = 649
Case $A8 TileIndex = 643
Case $A9 TileIndex = 646
Case $AA TileIndex = 648
Case $AB TileIndex = 644
Case $AC TileIndex = 645
Case $B0 TileIndex = 2
Case $B1 TileIndex = 598
Case $B2 TileIndex = 586
Case $B3 TileIndex = 856
Case $BA TileIndex = 583
Case $BB TileIndex = 588
Case $BC TileIndex = 589
Case $BD TileIndex = 579
Case $BE TileIndex = 578
Case $BF TileIndex = 540
Case $C0 TileIndex = 544
Case $C1 TileIndex = 546
Case $C2 TileIndex = 547
Case $C3 TileIndex = 1057
Case $C4 TileIndex = 1061
Case $C6 TileIndex = 442
Case $CA TileIndex = 584
Case $CB TileIndex = 582
Case $C7 TileIndex = 443
Case $CD TileIndex = 590
Case $CE TileIndex = 1056
Case $CF TileIndex = 543
Case $D0 TileIndex = 557
Case $D1 TileIndex = 542
Case $D5 TileIndex = 639
Case $D8 TileIndex = 581
Case $D9 TileIndex = 545
Case $DA TileIndex = 541
Case $E7 TileIndex = 548
Case $E8 TileIndex = 394
Case $E9 TileIndex = 395
Case $EA TileIndex = 396
Case $EB TileIndex = 397
Case $EC TileIndex = 398
Case $ED TileIndex = 399
Case $F0 TileIndex = 852
Case $F3 TileIndex = 1044
Case $F4 TileIndex = 8
Case $F5 TileIndex = 10
Case $F6 TileIndex = 182
Case $F7 TileIndex = 183
Case $F9 TileIndex = 553
Case $FA TileIndex = 561
Case $FB TileIndex = 585
Case $FC TileIndex = 498
Case $FD TileIndex = 499
Case $FE TileIndex = 476
EndSelect

'Don't draw after a $5B value:
If Maps[y+CamY, x-1] = $5B Then TileIndex = -1

If TileImg And Not Textmode And MapTile = $C5
DrawImage(TileImg, x*16, y*16, 536)
DrawImage(TileImg, x*16, y*16, 539)
ElseIf TileImg And Not Textmode And TileIndex >= 0
DrawImage(TileImg, x*16, y*16, TileIndex)
ElseIf MapTile <> $20
DrawText(Hex(MapTile)[6..], x*16, y*16+3)
EndIf
Next
Next
Flip

If KeyDown(KEY_DOWN)
CamY :+ 1
If CamY > MaxY-30 Then CamY = MaxY-30
EndIf

If KeyDown(KEY_UP)
CamY :- 1
If CamY < 0 Then CamY = 0
EndIf

If KeyHit(KEY_TAB)
Textmode = Not Textmode
EndIf
Until KeyHit(KEY_ESCAPE) Or AppTerminate()
</pre>

== Credits ==

The location of the map data was discovered by [[User:Lemm|Lemm]]. 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!)

ProGraphx Toolbox tileset format

2013-08-04T20:42:34Z

Frenkel: /* Header */ Duke Nukem: numbers.dn? contains 44 sprites and is therefore padded up to 7168 bytes.

{{Tileset Infobox
| Hardware1 = EGA
| MaxTiles = 255 per subtileset, unlimited subtilesets
| Palette = Default EGA
| Names = N
| TileMinSize = 0×0
| TileMaxSize = 2040×255
| NumPlanes = 5
| PlaneArrangement = [[Byte-planar EGA]]
| HasTransparency = Y
| HasHitmap = N
| Metadata = None
| Subtilesets = Y
| Compressed = N
| Hidden = N
| Game1 = Dark Ages
| Game2 = Duke Nukem
| Game3 = Crystal Caves
| Game4 = Secret Agent
}}
This file format is used by the ProGraphx Toolbox to store images used for map tiles in a game.
__TOC__
The ProGraphx Toolbox, written by Peder Jungck, is used by the following games:

* [[Dark Ages]] - <tt>DA3.EXE</tt> contains the string ''Version 1.0 EGA/VGAProGraphx EGA/VGA Toolbox (DA1.EXE and DA2.exe contain gibberish)''
* [[Duke Nukem]] - <tt>DN1.EXE</tt> contains the string ''Version 1.0 EGA/VGAProGraphx EGA/VGA Toolbox''
* [[Crystal Caves]] - <tt>CC1.EXE</tt> contains the string ''Version 1.5 320x200 PAN EGA/VGAProGraphx EGA/VGA Toolbox''
* [[Secret Agent]] - <tt>SAM1.EXE</tt> contains the string ''ProGraphx EGA/VGA Toolbox Version 2.0 320x200 EGA/VGA Copyright 1991 by Peder Jungck''

== File format ==

The file consists of a number of tilesets one after the other. Each tileset is made up of a collection of small images (usually 8×8 or 16×16, but the format supports up to 2040×255.)

In '''Secret Agent''' the files are encrypted with [[Secret Agent encryption]]. In the other games there is no encryption.

=== Signature ===

There is no signature, however careful processing of the header can be used to check whether the last tileset ends at exactly the end of the file (allowing for padding in some versions of the format.) If not, it is unlikely to be in this format. Be careful that files with zero values don't cause an endless loop when calculating offsets.

=== Header ===

Each tileset begins with the following header.

{|class="wikitable"
!Data type!!Description
|-
|[[BYTE]] count||Number of sprites in this chunk (50 in most cases)
|-
|[[BYTE]] width||Sprite width, in bytes (not in pixels)
|-
|[[BYTE]] height||Sprite height, in pixels
|}

The image data for the tileset follows the header. After the image data either the next header begins, or the file ends.

'''Dark Ages:''' Each tileset is padded up to 8064 bytes, except for the last tileset which contains 2 sprites and is padded up to 384 bytes.

'''Duke Nukem:''' Each tileset is padded up to 8064 bytes, except for <tt>NUMBERS.DN?</tt> (7186 bytes) and the backdrop files (<tt>DROP*.DN?</tt>) which have no padding. The backdrop files also have all three header bytes set to zero. For these files, the number of sprites is always 130, the width is always 2 (bytes) and the height is always 16.

'''Crystal Caves:''' The file ends after the last tile's image data, there is no padding.

'''Secret Agent:''' Each tileset is padded up to 8064 bytes for 16×16 sprite files (<tt>SAM?01.GFX</tt>), and 2048 bytes for 8×8 sprite files (<tt>SAM?02.GFX</tt>).

For those files with padding at the end, be careful not to interpret the padding as the presence of more tiles.

=== Image data ===

The image data is in [[Byte-planar EGA]] format with five planes, so reading <tt>width × height × 5</tt> bytes will read in enough data for a single image (one tile.) This value multiplied by the number of tiles (<tt>count</tt>) will yield the number of bytes in the entire tileset, which can be used to skip directly to the next tileset in the file (if any.)

The first byte in each tile's data is the transparency plane (1 == opaque, 0 == transparent), and the following four bytes/planes are blue, green, red and intensity. The MSB in each byte (10000000) is the first/left-most pixel, and the eighth pixel is the LSB (00000001). This means if the bits are processed in a loop, as the X direction increases to the right (0, 1, 2) the bit value decreases (0x80, 0x40, 0x20.)

== Notes ==

* For at least '''Duke Nukem''', the game seems to ignore the header of ''all'' files in this format. You can set the entire header of any tileset file to zero values and the game will still load them properly. This also means that you cannot use larger tilesets without modifying the executable.

== Credits ==

This file format has been reverse engineered by many people over the years. [[User:K1n9_Duk3|K1n9_Duk3]] discovered that Duke Nukem uses this format. [[User:Frenkel|Frenkel]] identified the similarities amongst all the games using the file format, and realised they all use the ProGraphx Toolbox. 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!)