ModdingWiki - User contributions [en-gb]

EGAGraph Format

2023-01-10T12:58:21Z

Sulix: Typo fixes: missing space, KDREAM.EGA→KDREAMS.EGA

{{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>KDREAMS.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]].

GameMaps Format

2023-01-10T12:45:02Z

Sulix: Fill in some missing filenames for GAMEMAPS files. Note that I didn't test the catacombs ones (other than c3d), but got them from the source here: https://github.com/CatacombGames

{{Map Infobox
| Type = 2D tile-based
| Layers = 3
| Viewport = ''Varies by game''
| Games =
{{Game|Bio Menace}}
{{Game|Blake Stone}}
{{Game|Catacomb 3-D}}
{{Game|Catacomb Abyss}}
{{Game|Commander Keen Dreams}}
{{Game|Commander Keen 4-6}}
{{Game|Corridor 7 Alien Invasion}}
{{Game|Dangerous Dave 3}}
{{Game|Dangerous Dave 4}}
{{Game|Super 3-D Noah's Ark}}
{{Game|Operation Body Count}}
{{Game|Rescue Rover 2}}
{{Game|Spear of Destiny}}
{{Game|Wolfenstein 3-D}}
}}

The '''GameMaps Format''' stores levels in a number of [[:Category:id Software]] games. The filenames and compression varies somewhat across different games but all files stored in this format were produced by the [[TED5]] level editor.

There are three main varieties of the file format. The most basic version is just [[RLEW compression|RLEW compressed]], the other two are either [[Carmack compression|carmackized]] or [[Huffman Compression|Huffman compressed]] on top of the RLEW compression. Each variation has its own file naming scheme and pattern of external/internal files.

There are two main components to the format. The game maps proper, which contain the actual level data, and the map headers, which contain both the location of each level's data within the game maps file, and the tile info for the game.

== Variants ==

{|class="wikitable"
! Game !! RLEW !! Carmackization !! Huffman !! Head || Gamemaps || Notes
|-
| Bio Menace || Yes || No || No || maphead.bm[123] || maptemp.bm[123] || gamemaps.bm[123] and mapthead.bm[123] are present but not used
|-
| Blake Stone: Aliens of Gold || Yes || No || No || maphead.bs[16] || maptemp.bs[16] ||
|-
| Blake Stone: Planet Strike || Yes || No || No || maphead.vsi || maptemp.vsi ||
|-
| Catacomb 3-D || Yes || Yes || No || Inside .exe || gamemaps.c3d ||
|-
| Catacomb Abyss || Yes || Yes || No || Inside .exe || gamemaps.abs ||
|-
| Catacomb Apocalypse || Yes || Yes || No || Inside .exe || gamemaps.apc ||
|-
| Catacomb Armageddon || Yes || Yes || No || Inside .exe || gamemaps.arm ||
|-
| Commander Keen Dreams || Yes || No || Yes || Inside .exe || gamemaps.kdr (v1.00), kdreams.map (v1.01+) ||
|-
| Commander Keen 4-6 || Yes || Yes || No || Inside .exe || gamemaps.ck[456] ||
|-
| Corridor 7 Alien Invasion || Yes || No || No || ? || ? || Uses MAPTEMP.xxx (only RLEW compression)
|-
| Dangerous Dave 3 || Yes || No || Yes || Inside .exe || gamemaps.dav ||
|-
| Dangerous Dave 4 || Yes || No || Yes || Inside .exe || gamemaps.dav ||
|-
| Super 3-D Noah's Ark || Yes || Yes || No || maphead.n3d || gamemaps.n3d ||
|-
| Operation Body Count || Yes || No || No || ? || ? || Uses MAPTEMP.xxx (only RLEW compression)
|-
| Rescue Rover 2 || Yes || Yes || No || Inside .exe || gamemaps.rr2 ||
|-
| Spear of Destiny || Yes || Yes || No || maphead.sod || gamemaps.sod ||
|-
| Wolfenstein 3-D (v1.0) || Yes || No || No || maphead.wl1 || maptemp.wl1 ||
|-
| Wolfenstein 3-D (v1.1 and above)|| Yes || Yes || No || maphead.wl[16] || gamemaps.wl[16] ||
|}

The games that use Huffman compression will have a MAPDICT (embedded in the game's main executable). Those missing the map dictionary are not Huffman encoded.

To work out whether Carmackization is used, read the first UINT16LE in a map plane (the field storing the decompressed size). If the value matches the expected size of the plane (i.e. width * height * 2), then only RLEW compression is used. If it doesn't match, check the second UINT16LE in the file (which will become the first UINT16LE once Carmackization has been removed). If this matches the expected plane size then the plane must first have Carmackization removed followed by removal of RLEW. The exception to this rule are plane sizes that have either 0xA7 or 0xA8 as the high byte (i.e. any value from 0xA700 to 0xA8FF), as those values would have been encoded differently by the [[Carmack compression]] algorithm.

== Data structures==

The map data is split into two files: The map header (<tt>MAPHEAD.xxx</tt>) and the main map file (usually <tt>MAPTEMP.xxx</tt> or <tt>GAMEMAPS.xxx</tt>). The map header may be embedded in the game's main executable.

<tt>MAPTEMP.xxx</tt> is the working format saved by [[TED5]] when maps are being edited and can be directly accessed and edited by this utility, allowing changes to be made to the game. Note that if the MAPHEAD file exists as an external file, the game always reads it from a file named named <tt>MAPHEAD.xxx</tt> for both the <tt>GAMEMAPS.xxx</tt> and the <tt>MAPTEMP.xxx</tt> variation. TED5 also saves a <tt>MAPTHEAD.xx</tt> file when editing maps, but that file is only used by TED5 and usually omitted from any game release.

The maps were often compressed even further for the public release versions of the games. This more compressed version of the map file was saved as <tt>GAMEMAPS.xxx</tt> by TED5. Later releases would omit the additional compression layer and ship with the <tt>MAPTEMP.xxx</tt> file instead. One possible reason for this could be that the size of the games grew to the point where they would no longer fit onto and be playable from a single floppy disk, and therefore the additional compression was no longer worth the amount of time it took to compress the maps and re-compile the code.

=== Map headers (MAPHEAD) ===

{|class="wikitable"
! Offset !! Type !! Name !! Description
|-
| 0 || [[UINT16LE]] || magic || Magic word signalling [[RLEW compression]]
|-
| 2 || [[INT32LE]][100] || ptr || 100 pointers to start of level 0-99 data in the game maps file
|-
| 402 || {{TODO|Unknown}} || tileinfo || Optional tileinfo data
|}

The map header file (MAPHEAD) is of varying length and contains three main types of data.

* The first is the magic word or flag used for RLEW compression, which is almost always $ABCD in the original files. It could be changed to any other value if necessary.

* The second is 100 level pointers which give the location of the start of level data in the GAMEMAPS file, relative to the start of that file. A value less than 1 indicates no level (generally 0, but occasionally -1 (0xFFFFFFFF) is used). Using -1 should be preferred over 0, as the pre-Wolf3D version of the engine will treat any negative value as "a non existant map" [sic!] and quit with an appropriate error message, while 0 will cause it to try reading a level header at offset 0 (where the "TED5v1.0" string is usually stored), which will cause all kinds of errors as there is clearly no valid level header at that offset.

* The third is the tileinfo data, which contains tile properties for each tile used in level creation. (These are masked and unmasked and either 8x8, 16x16 or 32x32.)

Many programs treat the tileinfo as a separate file from the MAPHEAD and it is possible to modify a game in this manner. Indeed, some games such as Wolfenstein 3-D do not have any tileinfo data at all in the map header file (giving a total file length of 402 bytes.) However TED5 works with any tileinfo data in the MAPHEAD.

=== Map data (GAMEMAPS) ===

The GAMEMAPS file consists of the string "TED5v1.0" and a number of compressed chunks of varying length. Each level in the file will have from two to four chunks (usually four) depending on the game, with all levels in a given game having the same number of chunks. These are the level header and 1-3 planes (foreground, background and sprite/info.) The chunks are in no particular order and it is possible to read through the entire file decompressing chunks as they're found.

Chunks are ordered by the MAPHEAD file, which will point to the GAMEMAPS level header chunks which in turn contain pointers to the other GAMEMAPS chunks used by that level.

All level data is in the form of [[UINT16LE]] values (or in the case of pointers, [[UINT32LE]].)

==== Level headers ====

The header for each level inside the GAMEMAPS file (which is pointed to by MAPHEAD) is 38 bytes long and ''never'' RLEW compressed. If the GAMEMAPS file is using Huffman compression, the level header itself is Huffman-compressed. In that case, the size of the compressed level header can be found in the MAPHEAD file. Since the uncompressed level header always has a size of 38 bytes, that size is not stored at the beginning of the compressed data. The header is sometimes followed by a signature "!ID!" string, which would give the header a total size of 42 bytes, but that string is not part of the actual level header.

Plane 0 is background using unmasked tiles, plane 1 is foreground and uses masked tiles, and plane 2 is sprite/info. Levels must contain a background plane and usually an infoplane.

For the compressed size of each level plane, a value of 0 indicates the plane does not exist. The offset value for unused planes appears to be set to a random number with the most significant byte set to 0xFF, making it either a negative number or an offset close to the 4 gigabyte range. The games only check the compressed size and ignore the offset if the size is 0.

Note that Wolf3D is hard-coded to always load the first two planes, even if the compressed size of a plane is 0. Wolf3D also ignores the width and height stored in the level header and just assumes the level is 64x64 tiles. This also applies to Blake Stone and probably any other game based on the Wolf3D code.

All versions of the "Id Software Caching Manager" ignore the expanded size value at the beginning of the RLEW data and just assume that the size is the same as the size of the plane (width * height * 2).

{|class="wikitable"
! Offset !! Type !! Name !! Description
|-
| 0 || [[INT32LE]] || offPlane0 || Offset in GAMEMAPS to beginning of compressed plane 0 data (or <= 0 if plane is not present)
|-
| 4 || INT32LE || offPlane1 || Offset in GAMEMAPS to beginning of compressed plane 1 data (or <= 0 if plane is not present)
|-
| 8 || INT32LE || offPlane2 || Offset in GAMEMAPS to beginning of compressed plane 2 data (or <= 0 if plane is not present)
|-
| 12 || UINT16LE || lenPlane0 || Length of compressed plane 0 data (in bytes)
|-
| 14 || UINT16LE || lenPlane1 || Length of compressed plane 1 data (in bytes)
|-
| 16 || UINT16LE || lenPlane2 || Length of compressed plane 2 data (in bytes)
|-
| 18 || UINT16LE || width || Width of level (in tiles)
|-
| 20 || UINT16LE || height || Height of level (in tiles)
|-
| 22 || char[16] || name || Internal name for level (used only by editor, not displayed in-game. null-terminated)
|}

Note that for Wolfenstein 3D, a 4-byte signature string ("!ID!") will normally be present directly after the level name. The signature does not appear to be used anywhere, but is useful for distinguishing between v1.0 files (the signature string is missing), and files for v1.1 and later (includes the signature string).

== Carmack compression ==

[[Carmack compression]] is the method used to compress later ''id Software'' games, when file size was still a concern. It is the most efficient and complex compression method and was created specifically to work with the 16-bit word structure of the GameMaps file. The compression is detailed on its [[Carmack compression|own page.]]

Carmackized game maps files are external <tt>GAMEMAPS.xxx</tt> files and the map header is usually (but not always) stored internally in the executable. The map header must be extracted and the game maps decompressed before TED5 can access them. TED5 itself can produce carmackized files and external <tt>MAPHEAD.xxx</tt> files. Carmackization does not replace the RLEW compression used in uncompressed data, but compresses this data, that is, the data is doubly compressed.

Note that for Wolfenstein 3D v1.0, map files are not carmackized, only RLEW compression is applied.

== Huffman compression ==

[[Huffman Compression]] was probably used by earlier versions of TED5 (but possibly not TED5 at all) before carmackization was introduced. It uses the same method to compress its data as is used by ''id Software'' games to compress their graphics and sounds. Again this compression method works with RLEW compressed data and has its [[Huffman Compression|own page.]]

Huffman compression is easily detected since it works on the bit level and thus disrupts the word structure of the game data. This is easily seen in a hex editor. Compressed data will not contain the string $00 $00 or indeed even $00 very often. (In contrast, even carmackized data contains both strings hundreds of times.)

There will be two internal files for this format: the map header and the Huffman dictionary (which is always the first dictionary in the executable.) The map header format is also slightly different, being 502 bytes long, the extra 100 bytes being the length of the compressed level headers in the game maps data, which occur immediately after the normal level header offsets and before the tileinfo. Each entry is one octet indicating the decompressed header length in bytes or zero if the level does not exist. (These can be ignored when decompressing since Huffman data can be read until the decompressed level header's fixed size is reached, but if they are omitted when writing the MAPHEAD, the game may experience a buffer overflow when reading the maps.)

== Location of internal files ==

The GAMEMAPS file itself is always external, but in the case of compression, the MAPHEAD is stored internally in the main .exe file. Executables are themselves compressed with either with LZEXE or PKLite. Once the .exe has been decompressed it is a trivial task to find the MAPHEAD as it will start with the UINT16LE value $ABCD (i.e. the byte $CD followed by the byte $AB.) For level editing purposes only the first 402 (or 502) bytes of the file need to be extracted, though it is possible to read the MAPHEAD file to calculate its length.

The following table lists the offsets of the MAPHEAD file for various games, relative to the start of the decompressed game .exe file.

{{TODO|TODO: Add all known versions of all games}}

{|class="wikitable"
! Game !! Version !! Location !! Filename !! Offset !! Notes
|-
| [[Bio Menace]] || Freeware || External || <tt>MAPHEAD.BM[123]</tt> || - ||
|-
|rowspan=2| [[Blake Stone]]: Aliens of Gold || Shareware || External || <tt>MAPHEAD.BS1</tt> || - ||
|-
| Registered|| External || <tt>MAPHEAD.BS6</tt> || - ||
|-
| [[Blake Stone]] 2: Planet Strike || All || External || <tt>MAPHEAD.VSI</tt> || - ||
|-
| [[Catacomb 3-D]] (3) || 1.00 || Internal || <tt>CAT3D.EXE</tt> || $1C570 || After UNLZEXE
|-
| [[Catacomb Abyss]] (4) || 1.13 || Internal || <tt>CATABYSS.EXE</tt> || $1C510 || After UNLZEXE
|-
| [[Catacomb Armageddon]] (5) || 1.01a || Internal || <tt>CATARMA.EXE</tt> || $1D900 || After UNLZEXE
|-
| [[Catacomb Apocalypse]] (6) || 1.00b || Internal || <tt>CATAPOC.EXE</tt> || $1DD50 || After UNLZEXE
|-
|rowspan=3| [[Corridor 7 Alien Invasion]] || Demo || External || <tt>MAPHEAD.DMO</tt> || - ||
|-
|| CD || Internal || <tt>CORR7CD.EXE</tt> || $30D50 || File is not compressed
|-
| Floppy || Internal || <tt>C7.EXE</tt> || $24BF0 || File is not compressed
|-
|rowspan=2| [[Commander Keen 4-6|Keen 4]] || Special Demo || ? || ? || ? || File is PKLite compressed
|-
| 1.4 EGA || Internal || <tt>KEEN4E.EXE</tt> || $24830 || After UNLZEXE
|-
| [[Commander Keen 4-6|Keen 5]] || 1.4 EGA || Internal || <tt>KEEN5E.EXE</tt> || $25990 || After UNLZEXE
|-
| [[Commander Keen 4-6|Keen 6]] || 1.4 EGA || Internal || <tt>KEEN6.EXE</tt> || $25080 || After UNLZEXE
|-
| [[Commander Keen Dreams]] || 1.13 || Internal || ? || $1FA50 || After UNLZEXE
|-
| [[Noah's Ark 3D]] || All || External || ? || - ||
|-
| [[Operation Body Count]] || All || External || <tt>MAPHEAD.BC</tt> || - ||
|-
| [[Spear of Destiny]] || All || External || <tt>MAPHEAD.SOD</tt> || - ||
|-
|rowspan=2| [[Wolfenstein 3-D]] || Shareware || External || <tt>MAPHEAD.WL1</tt> || - ||
|-
| Registered || External || <tt>MAPHEAD.WL6</tt> || - ||
|}

== Utilities ==

* [[TED5]] can edit the <tt>GAMEMAPS</tt> format of any games that use it. It is the original editor used to create these files.

== Credits ==

This file format was reverse engineered by Andrew Durdin (adurdin). 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!)

Softdisk Library Format

2023-01-08T05:59:57Z

Sulix: /* LZH */ Improve LZH algorithm description (based loosely on my PCKF post here, as well as comments in the code, the various linked articles, and things NY00123 told me: https://pckf.com/viewtopic.php?p=73323#p73323)

{{Archive Infobox
| MaxFiles = 65,535
| FAT = Beginning
| Names = Yes, 8.3
| Metadata = None
| Subdirectories = N
| Compressed = Y
| Encrypted = N
| Hidden = Y
| Games =
{{Game|Commander Keen Dreams}}
{{Game|Dangerous Dave 3}}
{{Game|Dangerous Dave 4}}
}}
SLIB, or Softdisk LIBrary, compression is a container file format used by [[Softdisk]] software to compress various files used by their games, most notably the Commander Keen Dreams series of games, (Including Dangerous Dave 3 and Dangerous Dave 4)to store title images used at the beginning of each game. It was created in 1992 by Jim Row.

The data held in the file can be compressed in any one of three ways, uncompressed, LZW and LZH. The compression used is primitive and rather different from later or traditional versions of LZW\LZH. SLIB files were created by the program <tt>SOFTLIB.EXE</tt> and as such any game that uses this format contains various segments of code in common with <tt>SOFTLIB</tt> for the decompression of data.

There is a closely related format, the SHL or Softdisk Help Library format. SHL files contain only a single file. Their header is slightly different, it's file signature is 'CMP1' (CoMPression of 1 file) while that of SLIB files is SLIB. The veracity of both files can be confirmed by checking for a word of value 2 at offset 4 in the file. The actual files have been given a number of extensions; <tt>.CMP</tt> (CoMPressed), <tt>.SHL</tt> (Softdisk Help Library) or the game extension.

The SLIB file can roughly be broken into a number of parts; the header, which contains data about the various data chunks, and the data chunks themselves, each containing a single file. Each chunk also has a short header.

== Header ==

The file header is found only in SLIB files and is absent in SHL files, which are loaded into memory in their enitrety. The SLIB header allows individual data chunks to be loaded inhto memory seperately.

The SLIB header is a variable length header that contains information about how many chunks there are in a file as well as their location in the file and size. It is used by the game to load chunks into memory and by <tt>SOFLIB</tt> to extract compressed files.

The first part of the header is a fixed length of 8 bytes and allows the game to identify the file as SLIB and also the total length of the header (Which will be 30 * the value at offset 6 plus 8.) The second part is a series of chunk headers that hold information about what file is held in each chunk. (The last six bytes are repeated at the start of the data chunk.)

FILE HEADER:
0 CHAR[4] fID Signature, 'SLIB' (Softdisk LIBrary)
4 UINT16LE Version Version number, always $0002
6 UINT16LE Chunks Number of data chunks in file
8 CHAR[30x] Chunk headers Chunk headers

IMAGE HEADERS:
? CHAR[16] Name Name of compressed image (Max len 12 chars) padded with nuls
+16 UINT32LE Dat st Start of image data in file (From start of first image chunk)
+20 UINT32LE Dat end End of image data in file (From start of first image chunk)
+24 UINT32LE iOriginalSize Decompressed data size
+28 UINT16LE iCompression Compression used, 0 = none, 1 = LZW, 2 = LZH

== Data Chunks ==

The data chunk has a short header followed by the actual data itself. The format differs slightly between SLIB chunkks and SHL files. Both format must identify themselves to the game, and they do so in different ways.

Notice that in the case of SLIB chunks bytes 4-10 are identical to bytes 24-30 of that chunk's header.

SLIB CHUNK FORMAT
? CHAR[4] cID Signature'CUNK' (Chunk UNKompressed size)
+4 UINT32LE iOriginalSize Decompressed data size
+8 UINT16LE iCompression Compression method
+10 CHAR[?] Data Image data

SHL files are slightly more tricky; an uncompressed SHL file is simply raw data, compressed data must identify itself as such and so the header is slightly longer. It can be considered a combination of the chunk header and the SLIB header in the section above.

SHL FILE FORMAT
0 CHAR[4] cID Signature'CMP1' (CoMPressed s1ingle file)
4 UINT16LE iCompression Compression method (as above)
6 UINT32LE iOriginalSize Decompressed data size
10 UINT32LE iCompressedSize Compressed data size
14 CHAR[?] Data Image data

== Compression ==

As noted above there are three forms of compression. The first is simple enough, no compression at all, the data is simply stored in the file. (Actually increasing the size!) The other two are called 'LZW' and 'LZH' by the programmers but both differ from what are now standard implmentations of those formats.

=== LZW ===

A compression value of 1 means the chunk is [[LZW compression|LZW compressed]]. The format of the compression used is different from the more 'usual' implementation of LZW. Most LZW works by building a 'dictionary', but LZW is in essence just referring back to data that has already been read.

The core of the implementation is that if a sequence is encountered that has already been read then it is replaced with a pointer to it. There are three types of data, flag bytes, pointers and literals.

Flag bytes divide the datastream into segments of eight 'values' which can be either literals or pointers. Pointers are 2 bytes long, literals 1 byte. (Therefore there will be a flag byte every 8 to 16 bytes of data.) The value of each bit (In little endian) indicates whether a value will be a literal (1) or codeword (0) Thus a value of 199 (11000111 in binary) indicates three pointers, three literals and two pointers in that order. (Total of 13 bytes.)

Literals are sequences that have never been seen in the datastream before, they cannot be compressed and are thus the same in the compressed and decompressed datastreams. (If the data is text they become quite obvious.) Any string less than 3 bytes long that has not been read before or cannot be pointed to (See below) will be stored as literals.

Pointers are reference to data that has already been read. They are two bytes long, with the first 12 bits giving the location to read data from and the last 4 bits giving the length of data to read.

The lower nybble (4 bits) of the second pointer byte holds the length of repeat data to read minus three. (This makes sense, the shortest sequence it makes sense to code is three bytes which can be given the value 0.) It will be immediately apparent that the maximum length of repeated data that can be stored as a pointer is 18 bytes.

The high nybble of the second byte is multiplied by 256 then added to the first byte to give the location of the data to read in the 'sliding window' minus 18. In hexadecimal this is as simple as appending the nybble to the first byte. For example flag bytes of <tt>$EA $F6</tt> point to location <tt>$FEA</tt> with '6' relating to the data length to read.

The 'sliding window' in this case is the region of decompressed data that the compressed data can point to. It will be immediately obvious that the pointers can encode values between +-2048, or about 2KB. If the decompressed data is less than 2KB in size then zero is the start of the data, if it is larger than it is 2048 bytes from the end of the data. (This is the origin of the term 'sliding window'; it is a window of data that can be slid along the datastream as it gets bigger.)

It will be noted that it is probable that the compressed datastream will not be perfectly divisible by flag bytes. In this case the unused bits are set to 0. The decompressor stops when the decompressed data size is equal to the value given in the chunk header.

The last thing to keep in mind is that the flagged location obtained requires 18 to be added to it. This is due to how the decompressor is set up in memory; it needs a buffer of 18 bytes (the maximum length of compressed data that can be decompressed) between where it is working and the start of the datastream proper. These bytes are initially filled with blank spaces (<tt>$20</tt> not <tt>$00</tt>.) and considered part of the datastream but not part that is output to the final file. (Their locations are negative.)

This has an odd result; it's entirely possible for a flag byte to point to a negative value and output one or more characters that were never part of the uncompressed data. To illustrate this we will look at the text string 'I am Sam. Sam I am!' as compressed by <tt>softlib.exe</tt>. Note that on line 6 it requests 5 bytes from address -1. This is the string ' I am'. The last four bytes are from the start of the sentence but the first, a blank space, comes from the buffer.

FF Flag byte, 8 literals follow
49 20 61 6D 20 53 61 6D 'I am Sam' as literals
09 Flag byte, 1L, 2P, 1L,4Blanks ($09 = 00001001)
2E '.' as literal
F2 F1 Pointer, read 1 + 3 = 4 bytes from $FF2, or -14 + 18 = 4 in the data. This is ' Sam'
ED F2 Pointer, read 2 + 3 = 5 bytes from $FED or -19 + 18 = -1 in the data. This is ' I am'
21 '!' as literal

=== LZH ===

LZH (also known as LZHUF) is a combination of [[LZSS compression]] and [[Huffman Compression]] originally developed by Haruyasu Yoshizaki for his [https://en.wikipedia.org/wiki/LHA_(file_format) LHarc compressor], based on the prior LZARI algorithm from Haruhiko Okumura.

Compressing data with LZHUF can be considered a two-stage process (though, in practice, both stages are run simultaneously).

First, the data is LZ-compressed, converting it to a series of literals (uncompressed bytes) and matches (references to a contiguous run of bytes which appeared earlier: these references consist of a length and an offset).

These literals and matches are then huffman compressed using two separate huffman tables.

Literals (as well as the lengths of matches) are compressed using the main _adaptive_ Huffman tree. This huffman tree has 256 + 28 = 284 leaf nodes: the first 256 represent literal bytes, the next 28 represent matches of length 2 to length 30. After every entry is encoded or decoded, a probability for that value is updated and, if necessary, the huffman tree is reconstructed to be optimal for the new probability distribution.

If the encoded value is a match length, the offset (which is 12-bits long) is then split into two 6-bit halves. The upper 6 bits are encoded with a fixed huffman dictionary. The bottom 6 bits are stored as-is.

The [http://www.apogeesoftware.com/uncategorized/apogee-releases-blake-stone-source-code Planet Strike source code release] contains C code that handles LZH compression and decompression in <tt>JM_LZH.C</tt>. The code was written by Jim T. Row, who apparently also wrote the Softlib utility, so chances are it is the same implementation of LZH.

The same compressor/decompressor can also be found in the open-sourced Keen Dreams source, in [https://github.com/keendreams/keen/blob/master/lzhuf.c LZHUF.C].

An account of the development of this algorithm can be found in [https://oku.edu.mie-u.ac.jp/~okumura/compression/history.html A History of Data Compression in Japan]. Okumura further describes the algorithms in [https://oku.edu.mie-u.ac.jp/~okumura/compression/ar002/compr2.txt this page]. Note however, that the Softdisk library implementation uses Jim T. Row's implementation, not the original by Okumura and Yoshizaki.

== Softlib ==

Soflib (Softdisk Library Creator) is a DOS program that can be used to create or extract files from SLIB files. It can work with both forms of compression used in SLIB files. It is notable that for some reason files shorter than 24 bytes often fail to be compressed correctly. (Soflib outputs a library with an empty chunk in it.) Soflib can be downloaded from the tools section of this page.

== Data contained in libraries ==

Keen Dreams uses SLIB to compress its title screen and also comes with a number of LZH compressed .SHL files containing text. The title screen is in [[LBM Format]] It is notable that the game does not read most of the LBM chunks, focusing instead on the FORM, BMHD and BODY chunks. This is because while the compressed files were designed to be viewed and edited in a standalone program, the game did not need things such as the LBM palette.

Dangerous Dave 3 and 4 use an additional SLIB file to store their digital sound effects, which are seperate from their [[AudioT Format|PC\adlib sounds]]

== Tools ==

{{BeginFileFormatTools|Type=group}}
{{FileFormatTool
| Name = [http://files.shikadi.net/moddingwiki/tools/kdreams/softlib.exe SOFTLIB.EXE]
| Platform = DOS
| canExtract = Yes
| canDecompress = Yes
| canCreate = Yes
| canModify = Yes
| canCompress = Yes
| editHidden = No
| editMetadata = N/A
| notes = Original DOS program that can create and modify Softdisk Libraries
}}
{{FileFormatTool
| Name = [http://files.shikadi.net/moddingwiki/tools/kdreams/Titlebuild.zip Titlebuild]
| Platform = Windows
| canExtract = No
| canDecompress = No
| canCreate = Yes
| canModify = No
| canCompress = Yes
| editHidden = No
| editMetadata = N/A
| notes = Windows program to turn a 320x200 bitmap into <tt>KDREAMS.CMP</tt> for Keen Dreams
}}
{{EndFileFormatTools}}

== Credits ==

This format partially reverse engineered by [[User:Lemm]] and [[User:Levellass]].

Commander Keen Dreams

2023-01-08T05:17:43Z

Sulix: Keen Dreams was made with TED5 v0.18 (Jun 27 1991), not TED3. Interestingly, this version isn't mentioned in the TED5 source changelog (It would sit between v0.17 on Jun 26 and v0.23 on Jul 12).

{{Stub}}

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

== Tools ==

{{BeginFileFormatTools|Type=game}}
{{FileFormatTool
| Name = [http://files.shikadi.net/moddingwiki/tools/kdreams/softlib.exe SOFTLIB.EXE]
| Platform = DOS
| grp = No
| map = No
| gfx = Edit
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
| notes = Edits title screen only
}}
{{FileFormatTool
| Name = [http://files.shikadi.net/moddingwiki/tools/kdreams/Titlebuild.zip Titlebuild]
| Platform = Windows
| grp = No
| map = No
| gfx = Edit
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
| notes = Creates title screen only
}}
{{EndFileFormatTools}}

See also the [[keenwiki:Other Tools|list of tools]] on the KeenWiki.

== File formats ==

* [[AudioT Format]] - used for storing sound and music data
* [[B800 Text]] - there are a couple of text screens in the main .EXE file (including the text displayed on the screen when you quit)
* [[EGAGraph Format]] - used for storing graphics, text and miscellaneous data
* [[Keen Dreams level Format]] - used for storing level maps
* [[Keen 4-6 Action Format]] Sprite's behaviors are governed by this
* [[Keen 4-6 Tileinfo Format]] Tile information are governed by this
* [[Softdisk Library Format]] - The start menu is in this format
* [[SLIB compression]] The title screen is compressed with this

Compression used in KeenDreams is complex; most of the 'registered' (Non shareware) executables are compressed using [[PKLite compression]] and demo versions have additional files or filenames. Uniquely, the game maps are compressed using [[Huffman Compression]] instead of [[Carmack compression]], as they were made with an earlier version of [[TED5]] (TED5 v0.18).

== Versions ==

There are no less than six versions of Keen Dreams available; these differ very little in actual gameplay, but markedly in file structure. Most of these are listed at [[http://www.shikadi.net/keenwiki/Keen_Dreams_Versions the Commander Keen Wiki]] (They omit version 1.0 and the Id Anthology)

The main moddable version is version 1.13, which is not the latest version of the game. Notably it has less in-game help and text, requires the player to run a program from Gamer's Edge before playing and names its files differently from the later Keen 4-6 manner. It also uses a seperate file for its start screen, which is unusual.

== Related Links ==
* [[Commander Keen 1-3]]
* [[Commander Keen 4-6]]
* The [[KeenWiki:Main Page|Commander Keen Wiki]]

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