ModdingWiki - User contributions [en-gb]

ProGraphx Toolbox tileset format

2025-10-20T05:57:39Z

K1n9 Duk3: /* Header */ fixed typos

{{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 packets (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. {{TODO|Check if header is ignored by the game}}

'''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. The game executables will ignore the entire header of the tileset files and simply load a hard-coded amount of image data into memory, skipping the 3-byte header data. There is never more than one tileset in each file.

'''Duke Nukem:''' Most tilesets are padded up to the nearest multiple of 128 bytes, except for the backdrop files (DROP*.DN?) 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. The game executables will always ignore the entire header of all the tileset files and simply load a hard-coded amount of image data into memory, skipping the 3-byte header data. There is never more than one tileset in each file.

'''Crystal Caves:''' The file ends after the last tile's image data, there is no padding. The game executables will ignore the entire header of the tileset files and simply load a hard-coded amount of tilesets (and a hard-coded amount of bytes per tileset) into memory. Only the main 16x16 pixel tileset file CC?.GFX contains multiple tilesets (23 tilesets in total, 50 tiles each), the other 8x8 pixel tileset files only contain a single tileset per file.

'''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. {{TODO|Check if header is ignored by the game}}

'''Secret Agent:''' Each tileset is padded up to 8064 bytes for 16×16 sprite files (SAM?01.GFX), and 2048 bytes for 8×8 sprite files (SAM?02.GFX). The game executables will ignore the entire header of the tileset files and simply load a hard-coded amount of tilesets (and a hard-coded amount of bytes per tileset) into memory. The 16x16 pixel tileset file contains 16 tilesets and the 8x8 pixel tileset file contains 3 tilesets.

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

2025-10-10T08:28:19Z

K1n9 Duk3: /* Header */ most games ignore the headers and read hard-coded amounts of data

{{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 packets (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. {{TODO|Check if header is ignored by the game}}

'''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. The game executables will ignore the entire header of the tileset files and simply load a hard-coded amount of image data into memory, skipping the 3-byte header data. There is never more that one tileset in each file.

'''Duke Nukem:''' Most tilesets are padded up to the nearest multiple of 128 bytes, except for the backdrop files (DROP*.DN?) 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. The game executables will always ignore the entire header of all the tileset files and simply load a hard-coded amount of image data into memory, skipping the 3-byte header data. There is never more that one tileset in each file.

'''Crystal Caves:''' The file ends after the last tile's image data, there is no padding. The game executables will ignore the entire header of the tileset files and simply load a hard-coded amount of tilesets (and a hard-coded amount of bytes per tileset) into memory. Only the main 16x16 pixel tileset file CC?.GFX contains multiple tilesets (23 tilesets in total, 50 tiles each), the other 8x8 pixel tileset files only contain a single tileset per file.

'''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. {{TODO|Check if header is ignored by the game}}

'''Secret Agent:''' Each tileset is padded up to 8064 bytes for 16×16 sprite files (SAM?01.GFX), and 2048 bytes for 8×8 sprite files (SAM?02.GFX). The game executables will ignore the entire header of the tileset files and simply load a hard-coded amount of tilesets (and a hard-coded amount of bytes per tileset) into memory. The 16x16 pixel tileset file contains 16 tilesets and the 8x8 pixel tileset file contains 3 tilesets.

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!)

Pharaoh's Tomb

2025-10-10T07:40:29Z

K1n9 Duk3: /* File formats */ link to image format

{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}
'''Pharaoh's Tomb''' is a platform game by Micro F/X Software from 1990 with CGA graphics.

==File formats==
*[[Turbo Pascal 3.0 Image Format]] - tile images, stored in the executable
*[[Pharaoh's Tomb Map Format]] - levels are stored in the EXE file
*[[SAV Format (Pharaoh's Tomb)]] - savegames
*[[Pharaoh's Tomb & Arctic Adventure Fullscreen Image Format]] - title screen image (in [[PCX Format]])

==Notes==
*A level editor can be found [http://crystalshard.net/?p=8&s=51 here].
*Maps can be found [http://www.zanderz.net/index.php?id=gamemaps here].

[[Category:Apogee]]
[[Category:Puzzle]]
[[Category:Pharaoh's Tomb]]

Arctic Adventure

2025-10-10T07:39:03Z

K1n9 Duk3: added link to image format

{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}
'''Arctic Adventure''' is a puzzle platformer by George Broussard/Apogee Software from 1991 with CGA graphics.

==File formats==
*[[Turbo Pascal 3.0 Image Format]] - tile images, stored in the executable
*[[Arctic Adventure Map Format]] - levels are stored in the EXE file
*[[Pharaoh's Tomb & Arctic Adventure Fullscreen Image Format]] - full screen image files (title screen, map screen, loading screen) in [[PCX Format]]

[[Category:Apogee]]
[[Category:Puzzle]]
[[Category:Arctic Adventure]]

Turbo Pascal 3.0 Image Format

2025-10-10T07:38:05Z

K1n9 Duk3: basic format, feel free to clean this up and move parts ito the PT and AA pages

Both Pharaoh's Tomb and Arctic Adventure store their tile images directly inside the game's executable. The image data is stored in the same image format used by Turbo Pascal 3.0's "Extended Graphics" and "Turtlegraphics" driver, just with extra padding at the end of each image.

This driver was superseded by the BGI driver in Turbo Pascal 4.0, but the later versions generally still included the old driver in the form of the GRAPH3.TPU unit for compatibility, albeit with practically no documentation on what the procedures and functions in this unit actually do and how to use them.

Each image begins with the following 6-byte header:

0 | UINT16LE | iNumBits | bits per pixel, 1 for 640x200 mode, 2 for 320x200 mode (always 2 in Pharaoh's Tomb and Arctic Adventure)
2 | UINT16LE | iWidth | image width, in pixels
4 | UINT16LE | iHeight | image height, in pixels

The Turbo Pascal 3.0 Reference Manual lists the following formula for calculating the minimal size of a buffer for a given image in 320x200 mode:

Size = ((Width + 3) div 4)*Height*2 + 6

And the official size requirement for images in 640x200 mode is:

Size = ((Width + 7) div 8)*Height + 6

That means a 16x16 pixel image will require 134 bytes in this format when using the formula for 320x200 mode. But given the format and the way the image data is stored, 70 bytes should be enough. The formula should really have used Height + 6 instead of Height*2 + 6 at the end. Perhaps this implies that support for 16-color graphics was supposed to be implemented, or maybe it was just an error in the Turbo Pascal 3.0 documentation.

The image data is stored as raw CGA-like data, left to right, bottom to top. Unlike the memory layout of CGA graphics cards, the odd and even lines of the image are not split in any way. The first byte of image data contains the color information for the first 4 (or 8) pixels on the left of the bottom-most row of the image.

The most-significant bit(s) inside each byte of image data store the color index for the leftmost pixel covered by that byte. If iNumBits is 2, the two most significant bits store the color index for the leftmost pixel (a color index from 0 to 3) and there are 4 pixels per byte. If iNumBits is 1, the most significant bit stores the color index for the leftmost pixel (either 0 or 1) and there are 8 pixels stored in each byte.

If the width, in pixels, does not fill all bits of the last byte in each row, the extra bits will be ignored. For example, if the width of the image is 1, only the most significant bit (or the two most significant bits in 320x200 mode) of each byte will contain the color index for that one pixel and the other bits will be ignored when drawing the image.

Sample C code to "draw" an image to the screen in a context where x=0 is the left edge of the screen and y=0 is the top edge of the screen would look like this:

void DrawImage(int filehandle, int px, int py)
{
UINT16 iNumBits, iWidth, iHeight;
UINT16 x, y;

iNumBits = ReadUINT16LE(filehandle);
iWidth = ReadUINT16LE(filehandle);
iHeight = ReadUINT16LE(filehandle);

for (y = iHeight-1; y >= 0; y--)
{
BYTE buffer;
int bitsleft = 0;

for (x = 0; x < iWidth; x++)
{
BYTE colorindex;

if (bitsleft == 0)
{
buffer = ReadBYTE(filehandle);
bitsleft = 8;
}

colorindex = buffer >> (8-iNumBits);
DrawPixel(px+x, py+y, colorindex);

buffer <<= iNumBits;
bitsleft -= iNumBits;
}
}
}

In Pharaoh's Tomb and Arctic Adventure, all images are 16x16 pixels, but every tile image is always 156 bytes long, not 134 or 70. This wastes quite a lot of memory, but is harmless otherwise. The tile images are stored as a single block inside the executables.

File Name | Ver. | EXE Size | Offset | Number of Tiles
-----------+------+----------+---------+----------------
PTOMB1.EXE | v3.0 | 0x1F730 | 0x18250 | 160 tiles
PTOMB2.EXE | v3.0 | 0x1F790 | 0x182B0 | 160 tiles
PTOMB3.EXE | v3.0 | 0x1F6E0 | 0x18200 | 160 tiles
PTOMB4.EXE | v3.0 | 0x1F6E0 | 0x18200 | 160 tiles
AA1.EXE | v2.0 | 0x22800 | 0x1C450 | 152 tiles
AA2.EXE | v2.0 | 0x22790 | 0x1C3E0 | 152 tiles
AA3.EXE | v2.0 | 0x22780 | 0x1C3D0 | 152 tiles
AA4.EXE | v2.0 | 0x227C0 | 0x1C410 | 152 tiles

Older versions of Pharaoh's Tomb (v2.0, v2.2, v2.3) store some of the tile images in a slightly different order than the later versions (v2.9, v3.0), but every version stores them as a sequence of 156-byte-blocks with no other data in between these blocks.

Note: The EXE Size values given in the table are the executable image sizes. The offsets in the table are relative to the start of the executable image. Since the original executables are compressed with LZEXE, the size of the uncompressed executable and the absolute position of the data in it may vary depending on which program was used to decompress the files. UNLZEXE might produce a slightly different file than UNP, for example. To calculate the absolute file position, read a UINT16LE value at position 8 in the decompressed executable and multiply that value by 16 to get the start offset of the executable image. Add that value to the offset given in the table to get the correct file position.

The following patch scripts allow you to extract the tile image data with K1n9_Duk3's Patching Utility:

%exefile ptomb1.exe 0x1F730
%dump tileset.pt1 $18250 $6180
%abort

%exefile aa1.exe 0x22800
%dump tileset.aa1 $1C450 $5CA0
%abort

The %exefile mode causes the patching utility to operate on the executable image, so you can use the EXE sizes and offsets given in the table and don't need to worry about caclulating an absolute file position.

The same tool can also be used to insert modified tile image data into the executable. Simply use a script in the following form:

%exefile ptomb1.exe 0x1F730
%patchfile $18250 tileset.pt1 0 $6180
%end

%exefile aa1.exe 0x22800
%patchfile $1C450 tileset.pt1 0 $5CA0
%end

And don't forget to save the patched file at the end.

Trivia: Since the 16x16 pixel images in Pharaoh's Tomb and Arctic Adventure really only take up 70 bytes, the remaining 86 bytes in each image contain whatever data was previously stored at that memory location when the images were grabbed. This can be literally anything, even parts of the game's source code.

The following pieces of source code can be found in Pharaoh's Tomb:

d(7 ,'x x xx x x x');
d(8 ,'xx xx ');

d(11,'xxxxxx Y xxxxx');
d(12,'xxxxxxxxxxxxxxxxxxx

object.frame := object.frame + 1;
If object.frame = 5 Then object

if (getdotcolor(man.x,man.y+x)=0) and
(getdotcolor(man.x+15,man.y+x)

ve to answer 10 in a row to get the bonus.
By registering this game, you will receive

The last two lines definitely come from either Trivia Whiz or Next Generation Trivia and have nothing to do with Pharaoh's Tomb. The lines calling the "d" procedure at the beginning are how the levels are defined in the source code for Pharaoh's Tomb, but this particular layout does not appear to be used for any of the levels in the final game.

Pharaoh's Tomb & Arctic Adventure Fullscreen Image Format

2025-10-04T18:01:13Z

K1n9 Duk3: Added a link to the PCX Format

{{Image Infobox
| Hardware1 = CGA
| Depth = 2-bit (CGA)
| MinSize = 320×200
| MaxSize = 320×200
| Palette = Standard CGA
| NumPlanes = 1
| HasTransparency = No
| HasHitmap = No
| Games =
{{Game|Pharaoh's Tomb}}
{{Game|Arctic Adventure}}
}}

This is actually just a description of a CGA version of the [[PCX Format]].

This format is used by [[Pharaoh's Tomb]] and [[Arctic Adventure]] to store full-screen (320 × 200) images. Known extensions are <tt>*.mnu</tt>, <tt>*.map</tt>, and <tt>*.pix</tt>, with the latter two being unique to Arctic Adventure. It's not currently known if the format is able to store images of different sizes, since there are no other known examples of files in this format yet other than those found in the aforementioned two games.

Pharaoh's Tomb only stores the title screen background graphic using this file format. Arctic Adventure uses it for the title screen (<tt>AA?.MNU</tt>), map/overworld background screen (<tt>AA?.MAP</tt>), and a few pieces of large text (<tt>AA?.PIX</tt>), like "Please Wait...", combined into a single image.

== Image ==

Files start with a 128-byte header, whose format and purpose is currently unknown, followed by variable length RLE-compressed image data. When uncompressed, the data is a raw CGA graphics mode screen, exactly 16000 bytes in size. It consists of 200 rows of 80 bytes, with each byte describing 4 pixels. To correctly interpret the data, CGA palette 0 (green/red/brown) should be used for Pharaoh's Tomb, and palette 1 (cyan/magenta/light gray) for Arctic Adventure.

Interestingly, the headers for Arctic Adventure contain mostly 0s, whereas the files for Pharaoh's Tomb have the same bytes filled with repeating sequences of <tt>0xC1 0xFF 0xBF</tt>. Other bytes are mostly identical between the headers of both games.

=== RLE Compression ===

The compression scheme is fairly simple. Any byte value less than or equal to <tt>0xC0</tt> should be copied verbatim. When encountering a value greater than <tt>0xC0</tt>, the byte following afterwards should be repeated <tt>value - 0xC0</tt> times. For example, the byte sequence <tt>0xC2 0xFF 0x0F</tt> expands to <tt>0xFF 0xFF 0x0F</tt>. There is no specific end marker, so data should be read until reaching end of file. As a safe-guard against corrupt or unexpected files, it's probably a good idea to also stop reading as soon as 16000 bytes of unpacked data have been produced.

== Source Code ==

The following C# class can load files in this format and convert them into <tt>System.Drawing.Bitmap</tt> objects, which can be saved using standard formats.

<syntaxhighlight lang="csharp">
public static class AaPtImageParser
{
// Loads an image in Arctic Adventure/Pharaoh's Tomb format into a Bitmap object.
// usePalette1 should be set to true for Arctic Adventure, false for Pharaoh's Tomb.
public static Bitmap LoadImage(string filename, bool usePalette1)
{
var cgaBytes = UnpackImage(filename);

var image = new Bitmap(320, 200);

var palette = usePalette1 ? CGA_PALETTE_1 : CGA_PALETTE_0;

// Convert CGA image data to RGBA
for (var row = 0; row < 200; ++row)
{
for (var col = 0; col < 80; ++col)
{
for (var pixel = 0; pixel < 4; ++pixel)
{
var shift = (3 - pixel) * 2;
var mask = 0b11 << shift;
var bits = (cgaBytes[col + row * 80] & mask) >> shift;

image.SetPixel(col * 4 + pixel, row, palette[bits]);
}
}
}

return image;
}

private static Color[] CGA_PALETTE_0 = [
Color.FromArgb(255, 0, 0, 0),
Color.FromArgb(255, 0, 0xAA, 0),
Color.FromArgb(255, 0xAA, 0, 0),
Color.FromArgb(255, 0xAA, 0x55, 0),
];

private static Color[] CGA_PALETTE_1 = [
Color.FromArgb(255, 0, 0, 0),
Color.FromArgb(255, 0, 0xAA, 0xAA),
Color.FromArgb(255, 0xAA, 0, 0xAA),
Color.FromArgb(255, 0xAA, 0xAA, 0xAA),
];

private static byte[] UnpackImage(string filename)
{
byte[] cgaBytes = new byte[16000];
int dstIndex = 0;

using (var stream = File.Open(filename, FileMode.Open))
{
// Skip over file header
stream.Seek(0x80, SeekOrigin.Begin);

// Decompress RLE data
var reader = new BinaryReader(stream);

while (stream.Position < stream.Length)
{
var marker = reader.ReadByte();

if (marker > 0xC0)
{
// Repeating sequence
var value = reader.ReadByte();

for (var i = 0; i < marker - 0xC0; ++i)
{
cgaBytes[dstIndex] = value;
dstIndex++;
}
}
else
{
// Single byte
cgaBytes[dstIndex] = marker;
dstIndex++;
}
}
}

return cgaBytes;
}
}
</syntaxhighlight>

== Credits ==

This graphic format was reverse engineered by [[User:Lethal guitar|Lethal_guitar]]. 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!)

Arctic Adventure

2025-10-04T17:56:31Z

K1n9 Duk3: /* File formats */ Full-screen images are CGA PCX Files

{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}
'''Arctic Adventure''' is a puzzle platformer by George Broussard/Apogee Software from 1991 with CGA graphics.

==File formats==
*[[Arctic Adventure Map Format]] - levels are stored in the EXE file
*[[Pharaoh's Tomb & Arctic Adventure Fullscreen Image Format]] - full screen image files (title screen, map screen, loading screen) in [[PCX Format]]

[[Category:Apogee]]
[[Category:Puzzle]]
[[Category:Arctic Adventure]]

Pharaoh's Tomb

2025-10-04T17:53:31Z

K1n9 Duk3: Title screens are CGA PCX images

{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}
'''Pharaoh's Tomb''' is a platform game by Micro F/X Software from 1990 with CGA graphics.

==File formats==
*[[Pharaoh's Tomb Map Format]] - levels are stored in the EXE file
*[[SAV Format (Pharaoh's Tomb)]] - savegames
*[[Pharaoh's Tomb & Arctic Adventure Fullscreen Image Format]] - title screen image (in [[PCX Format]])

==Notes==
*A level editor can be found [http://crystalshard.net/?p=8&s=51 here].
*Maps can be found [http://www.zanderz.net/index.php?id=gamemaps here].

[[Category:Apogee]]
[[Category:Puzzle]]
[[Category:Pharaoh's Tomb]]

Crystal Caves

2021-06-07T05:55:48Z

K1n9 Duk3: Undo revision 8356 by Szevvy (talk) - it replaced the Crystal Caves page with the contents of the Keen Dreams page

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

[[Crystal Caves]] is a platform game often noted for the smoothness of the game creature animations, due to the programmer deciding to use more animation frames than was typical at the time.

== Tools ==

{{BeginFileFormatTools|Type=game}}
{{FileFormatTool
| Name = [[Camoto]]
| Platform = Linux/Windows
| grp = N/A
| map = Edit
| gfx = Edit
| mus = N/A
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [http://sfprod.shikadi.net/old/games/crystalcaves.htm#tile_modifier CCmod]
| Platform = DOS
| grp = N/A
| map = No
| gfx = Edit
| mus = N/A
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{EndFileFormatTools}}

{{BeginGameFileList}}
{{GameFile
| Name = *.apg *.cdt *.end *.ttl
| Format = [[PCX Format]]
| KnownFormat = Yes
| Desc = 320×200 16-colour full screen images
}}
{{GameFile
| Name = *.gfx
| Format = [[ProGraphx Toolbox tileset format]]
| KnownFormat = Yes
| Desc = 16×16 16-colour sprites
}}
{{GameFile
| Name = *.mni
| Format = [[ProGraphx Toolbox tileset format]]
| KnownFormat = Yes
| Desc = 8×8 16-colour sprites, like the characters and icons on the status bar. Not to be confused with the MNI files from [[Cosmo's Cosmic Adventures]]
}}
{{GameFile
| Name = *.snd
| Format = [[Crystal Caves Sound format]]
| KnownFormat = Yes
| Desc = PC speaker sound effects (a modified form of [[Inverse Frequency Sound format]])
}}
{{GameFile
| Name = cc?.exe
| Format = [[Crystal Caves Map Format]]
| KnownFormat = Yes
| Desc = Game levels are stored inside the main game .exe
}}
{{EndGameFileList}}

== Trivia ==

* Episode 1, level 16 is made up primarily of green pipes. Two join types (left/right/top and left/open-down) were drawn and have usable level codes, however they were not used in the game.

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

Commander Keen Dreams

2021-06-07T05:52:08Z

K1n9 Duk3: Undo revision 8354 by Szevvy (talk) - it replaced the Keen Dreams page with the contents of the Keen 1-3 page

{{Stub}}

{{Game Infobox
| Levels = Edit
| Tiles = Edit
| Sprites = Edit
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}
== 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]] (TED3).

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

Duke Nukem II Actor Info

2021-04-15T00:02:42Z

K1n9 Duk3: added missing info

{{Tileset Infobox
| Hardware1 = EGA
| MaxTiles = 65,536
| Palette = External
| Names = N
| TileMinSize = 0×0
| TileMaxSize = 524,280×524,280
| NumPlanes = 5
| PlaneArrangement = Byte Planar
| HasTransparency = Y
| HasHitmap = N
| Metadata = None
| Subtilesets = N
| Compressed = N
| Hidden = Y
| Games =
{{Game|Duke Nukem II}}
}}

The tile arrangement for the [[Duke Nukem II]] actors (game characters) is stored in <tt>ACTRINFO.MNI</tt> in the main <tt>NUKEM2.CMP</tt> group file. This file describes how to arrange the bare 8×8 tiles found in the corresponding tileset, so that they form a frame belonging to an actor animation.

== File format ==

{|class="wikitable"
!Data type!!Description
|-
|UINT16LE iNumActors||Number of actors described in the file
|-
|UINT16LE iOffset[iNumActors]||Array of UINT16 offsets to the actor info structure (double these values to turn them into byte offsets)
|}

Following this structure the first actor data should begin. The actor data runs end-to-end, and <tt>iOffset</tt> should only be required when jumping to a particular actor's offset.

Note that <tt>iNumActors</tt> is technically the UINT16-offset of the first structure, however if it is treated as such it becomes difficult to find the number of actors described by the file.

{|class="wikitable"
!Data type!!Description
|-
|UINT16LE iNumFrames||Number of frames this actor has
|-
|INT16LE iDrawIndex||Seems to define when the actor will be drawn to the screen
|-
|ACTOR_FRAME frameInfo[iNumFrames]||Structure holding information about the frame
|}

The iDrawIndex value ranges from -1 to 3. Actors with a lower index will be updated and drawn first, the actors with highest index last. Any value smaller than -1 or greater than 3 is invalid and will prevent the actor from being spawned in a level.

<tt>ACTOR_FRAME</tt> is defined as:

{|class="wikitable"
!Data type!!Description
|-
|INT16LE iHotspotX||X-coord of hotspot (in tiles, can be negative)
|-
|INT16LE iHotspotY||Y-coord of hotspot (in tiles, can be negative)
|-
|UINT16LE iHeight||Frame height (in tiles)
|-
|UINT16LE iWidth||Frame width (in tiles)
|-
|UINT32LE iDataOffset||Offset into <tt>ACTORS.MNI</tt> where the tile data starts
|-
|UINT16LE iPadding1||never used
|-
|UINT16LE iPadding2||never used
|}

The hotspot is the location in the image which should appear at the offset given in the map layer. In other words, take the actor location, subtract iHotspotX number of tiles from the X-coordinate, subtract iHotspotY number of tiles from the Y-coordinate, and the actor will appear at the correct location.

The two padding values at the end are inserted to allow the game to calculate the start of the <tt>ACTOR_FRAME</tt> data for each frame with the same formula:

<tt>start = (iOffset[actor] + 8 * frame + 2) * 2</tt>

This means the padding values are effectively dummies for the <tt>iNumFrames</tt> and <tt>iDrawIndex</tt> values. Even though these padding values could theroretically be omitted for the last frame of each actor entry, they are always present in the original files.

== Notes ==

<tt>ACTORS.MNI</tt> contains some bytes that are not used by any actor frame. These bytes are found at the end of every 64KB block (exactly 65536 bytes) of data. In the original file, no sprite frame is split across these 64KB blocks. The image data is written to the end of the block to fill it up, then the new block is started, containing the entire image data of the sprite's frame.

However, [[Duke Nukem II]] seems to be able to handle the image data correctly, even if it is split across two of these blocks. This might have just been a limitation in the original tool that was used to create the <tt>ACTORS.MNI</tt> file.

The data for sprite number 29 is in a slightly different format. Instead of 4 colour planes and a mask plane, the image data for the frames of this sprite only consist of two planes. The frames of this sprite store the big 8*16 pixel font used in the menus. Furthermore, the game is hard-coded to draw this font at 8*16 pixles, i.e. 1 tile wide and 2 tiles high.

Id Software RLEW compression

2021-04-14T22:56:02Z

K1n9 Duk3: listed which games use RLEB and what it is used for

{{DISPLAYTITLE:id Software RLEW compression}}
{{Compression Infobox
| Type = Stream
| UnitSize = 2-byte
| Games =
{{Game|Bio Menace}}
{{Game|Blake Stone}}
{{Game|Catacomb 3-D}}
{{Game|Catacomb Abyss}}
{{Game|Catacomb Apocalypse}}
{{Game|Catacomb Armageddon}}
{{Game|Commander Keen 1-3}}
{{Game|Commander Keen Dreams}}
{{Game|Commander Keen 4-6}}
{{Game|Corridor 7 Alien Invasion}}
{{Game|Dangerous Dave 2}}
{{Game|Dangerous Dave 3}}
{{Game|Dangerous Dave 4}}
{{Game|Hovertank 3-D}}
{{Game|Super 3-D Noah's Ark}}
{{Game|Operation Body Count}}
{{Game|Rescue Rover}}
{{Game|Rescue Rover 2}}
{{Game|Shadow Knights}}
{{Game|Slordax}}
{{Game|Spear of Destiny}}
{{Game|Wolfenstein 3-D}}
}}

'''id Software RLEW compression''' was used in a number of id's early games. It is an [[RLE Compression]] algorithm that works at the word level, where each word is a group of two bytes (16 bits). The algorithm is used on files that themselves use 16-bit words as their basic units, such as game levels, where a single 16-bit value such as "12 34" might be repeated multiple times in a row. A byte-level RLE algorithm would not be able to compress this data at all, as each byte is different to the previous, however the same RLE algorithm operating at the 16-bit word level can achieve good compression.

The use of 16-bit values over 8-bit also yields other benefits, such as the maximum repetition count increasing from around 256 to 65,536, allowing even greater compression of data with large numbers of repeated values. The RLE code word can also be chosen to be less likely to appear in the data, minimising the number of escapes required. While 8-bit RLE has a 1 in 256 chance of a given byte needing to be escaped, 16-bit RLE reduces that to 1 in 65,536.

RLEW compression is almost exclusively used to compress level data. Most revisions of the early game engines by id Software used arrays of 16 bit values to store the level data.

== Algorithm ==

The algorithm is very straightforward. Every 16-bit value is passed through unchanged until an RLE code value is encountered. Typically this is 0xFEFE or 0xABCD (the latter stored as the two bytes 0xCD 0xAB in little-endian order). When this code word is read, instead of writing it out like the other values, two further words are read. The first is the number of times to repeat the word, and the second is the value to be repeated.

All 16-bit words are in little-endian order, although in practice only the code word and the repeat count need to be treated as little-endian. The other values can be read in either endian so long as they are read and written unchanged.

Data is usually read from the start of a file to the end, but many implementations have the size of the decompressed data as a [[UINT16LE]] at the beginning of the file. This should be used where possible so that trailing data at the end of the file does not inadvertently get read as input data.

A simple algorithm for decompressing this format is as follows;

<ol>
<li>If implemented, get the first word in the file (here called <tt>finalLength</tt>)</li>
<li>While the length of the output data is less than <tt>finalLength</tt>:
<ol style="list-style-type:lower-alpha">
<li>Read a word from the input data</li>
<li>Is this word the RLE code word? (e.g. 0xFEFE)
<ul>
<li>If yes;
<ol style="list-style-type:lower-roman">
<li>Get the next two words, the first as <tt>Count</tt> and the second as <tt>Value</tt>.</li>
<li>Write Value as a word, <tt>Count</tt> times.</li>
<li>Move forward three words and go to 2.</li>
</ol>
</li>
<li>If no;
<ol style="list-style-type:lower-roman">
<li>Write the word to the output.</li>
<li>Move forward a word and go to 2.</li>
</ol>
</li>
</ul>
</ol>
</li>
</ol>

=== Minimal compression ===

As only the code word needs to be handled specially, a quick compression function can be implemented by passing through all values as-is, and if the code word has just been written then it is followed by the additional words 0x0001 and the code word again. For example if the code word is 0xFEFE, then it will end up in the output as <tt>FEFE 0001 FEFE</tt>, meaning "RLE sequence begins: write 0xFEFE once".

=== Inefficiencies and hidden data ===

It is interesting to note that as only the RLEW code word needs to be escaped, no other word would ever need to be repeated only once. This means the escape sequence <tt>FEFE 0001 FEFE</tt> could have been shortened to <tt>FEFE 0001</tt> by omitting the field containing the word to repeat, with the assumption that the only word ever written just once is the RLEW code word itself.

Furthermore, the <tt>Count</tt> field in the RLE sequence is set to 1 to write the word once. This means it can be set to 0 to write the word zero times, effectively discarding that word. In theory this could allow "hidden" data to be embedded in the compressed data stream that would be skipped over by the decompressor and not affect the output decompressed data.

Most RLE algorithms avoid this inefficiency by adding 1 (or more) to the count value before using it, meaning a count of 0 writes the word once, a count of 1 writes it twice, and so on. In this case, as the RLE sequence takes up three words, no space is saved until at least four words are converted into an RLE code. This means adding 3 to the count would have been most efficient, with a count of 0 reserved as a special case for handling the escaping of the code word itself. Thus 0 would write the code word, 1 would repeat the word 4 times, 2 would repeat it 5 times, and so on. Words appearing 2 or 3 times in a row would be written out as-is without incurring any space penalty, with the sole exception of the RLEW code word appearing 2 or 3 times in a row, which would incur a small space penalty.

=== RLEB compression ===

This is almost exactly the same as RLEW compression. The only difference is that it operates on bytes instead of words. The flag value for this compression is $FE in most cases.

[[Dangerous Dave 2]], [[Rescue Rover]] and [[Shadow Knights]] use this method to compress some of their full-screen images. [[Rescue Rover]] and [[Shadow Knights]] also use this method to compress the game's sprite graphics.

=== Example code ===

* Javascript: the [https://github.com/camoto-project/gamecompjs/blob/master/formats/cmp-rlew-id.js cmp-rlew-id] algorithm in gamecomp.js (full compression and decompression)

Talk:FLIC Format

2021-04-08T22:30:28Z

K1n9 Duk3: Created page with "A subset of this format has already been documented as Duke Nukem II Animation Format and a more complete specification of the [http://www.compuphase.com/flic.htm FLIC For..."

A subset of this format has already been documented as [[Duke Nukem II Animation Format]] and a more complete specification of the [http://www.compuphase.com/flic.htm FLIC Format] extists elsewhere. Given that fact, I'm not sure if it would be worth the time and effort to add all of this information to the wiki instead of just linking to the other page. But if you have time to kill, feel free to do it anyway. --[[User:K1n9 Duk3|K1n9 Duk3]] ([[User talk:K1n9 Duk3|talk]]) 22:29, 8 April 2021 (GMT)

Keen 1-3 RLE compression

2021-03-19T03:20:26Z

K1n9 Duk3: /* Example code */ another version of the assembly code

{{Compression Infobox
| Type = Stream
| UnitSize = 1-bit
| Games =
{{Game|Catacomb}}
{{Game|Commander Keen 1-3}}
{{Game|Dangerous Dave}}
}}

[[Commander Keen 1-3]] uses [[RLE Compression]] to compress its 320x200 <tt>FINALE.CKx</tt> and <tt>PREVIEWx.CK1</tt> screens. [[Dangerous Dave]] also uses this format to compress its graphics. It was previously used in [[Catacomb|Catacomb I and II]] for the level data (not the graphics). This is one of many possible ways to create a functional RLE system.

The compressed file consists of a UINT32LE giving the decompressed size, followed by the compressed data.

The compressed data is processed in a loop. After each byte is read, its value is used to select an action. If the high bit is set (val & 0x80) then one more than the lower seven bits ((val & 0x7F) + 1) is the number of following bytes passed through unchanged. If the high bit was not set, then that value plus three is the number of times the following byte is repeated.

The next byte is then read and the same procedure followed until there is no more data or the decompressed size in the header has been reached.

An illustration:

80 aa 00 00 81 bb cc 05 dd

This data is interpreted as follows:

80 aa # Copy AA through unchanged
00 00 # Repeat 00 three times
81 bb cc # Copy BB and CC through unchanged
05 dd # Repeat DD eight times

Or as pseudocode:

* Get the initial dword [Final length]
* If [Decompressed data length] < [Final length] then:
*# Read a byte [Value]
*# If the byte value >= 128, then:
*#* Read and output the next [value - 127] bytes
*#* Move forward [Value - 126] bytes and return to step 1.
*# If the byte value < 128, then:
*#* Read the next byte and output it (value + 3) times.
*#* Move forward 2 bytes and return to step 1.

It can be seen that this system is not optimal since two repeating bytes must be treated as non-repeating.

=== Implementation bugs ===

Some implementations of this particular RLE algorithm have a bug that causes the decompression code to behave erraticly for compressed data whose expanded size exceeds a certain amount of bytes. Since the original games were programmed for 16 bit x86 processors, memory pointers need to be adjusted when reaching a 64k boundary. The RLE implementation adjusts the output pointer incorrectly when the offset reaches 0xFF00 (Dangerous Dave) or 0xFFF0 ([[Commander Keen 1-3]], [[Catacomb II]]). Reaching said offset causes the code to add <tt>offset / 16</tt> to the segment part of the address (which is correct), but then it sets the offset to 0 instead of setting it the remainder of that division (i.e. bitwise AND the offset value with 0xF). This effectively makes the decompression code overwrite up to 15 bytes of the already generated output.

The offset is only checked after writing a run of repeating or non-repeating data, which makes it hard to predict what the actual offset will be when the limit is reached and the pointer is normalized. If the four least significant bits of the offset are 0 at that point, then the offset will be adjusted correctly and no corruption occurs, otherwise up to 15 bytes are overwritten.

A possible workaround for this bug would be to make sure the RLE compression routines generate data that ends a run at offset 0xFF00 (or 0xFFF0, depending on which number the decompression code uses). This means the compression code needs to keep track of the 16 bit offset value the decompression code is going to use and produce a special, slightly less effectively compressed run when that offset is reached.

This implementation bug is usually not a problem, since most data compressed with this algorithm is nowhere near 64k. In [[Commander Keen 1-3]], this form of RLE stores full-screen EGA images, which are only 32000 bytes when decompressed. The first two [[Catacomb]] games use this for their levels, which are only 4096 bytes when decompressed.

Note that the limit of 0xFFF0 in Keen 1-3 and Catacomb II also means that certain run lengths can cause an overflow of the offset value that will remain undetected by the decompression code, causing it to start overwriting the last 64k written the output. For example, if the current offset is 0xFFEF, which is smaller than the limit of 0xFFF0, the code doesn't adjust the offset and proceeds with the next RLE run. If that run writes 17 bytes to the output, the new offset will be 0x0000 instead of 0x10000 (since the code is using 16 bit registers/variables), and the new offset will still be considered smaller than 0xFFF0. Again, this is not a big problem, since these games never use any compressed data large enough to trigger this.

=== Example code ===

* Javascript: the [https://github.com/Malvineous/gamecompjs/blob/master/formats/cmp-rle-id.js cmp-rle-id] algorithm in gamecomp.js

* x86 Assembly: [https://github.com/CatacombGames/TheCatacomb/blob/88947aa28b92be001ca093c613fb4b9c893c4cc5/RLEASM.ASM#L204 RLEASM.ASM] from [[Catacomb II|The Catacomb]] source code (including the offset normalization bug)

* x86 Assembly: [https://github.com/CatacombGames/Catacomb/blob/e657bc3aa8fef0d89bd09aa8fa0e051941c66518/CATASM.ASM#L2010 CATASM.ASM] from [[Catacomb]] source code (has a limit of 0xFF00, but not the normalization bug)

Keen 1-3 RLE compression

2021-03-19T03:06:38Z

K1n9 Duk3: /* Example code */ link to the bug in the implementation

Dangerous Dave Tileset Format

2021-03-19T02:57:09Z

K1n9 Duk3: it isn't necessarily always one byte that is skipped. Could be anything from 0 to 15 bytes

{{Tileset Infobox
| Image = ddave-tileset-vga.png
| ImageNativeWidth = Y
| Hardware1 = CGA
| Hardware2 = EGA
| Hardware3 = VGA
| MaxTiles = 232-1
| Palette = CGA 1i, Default EGA, shared VGA
| Names = N
| TileMinSize = 16×16 (0-53), 0×0 (54+)
| TileMaxSize = 16×16 (0-53), 65535×65535 (54+)
| NumPlanes = 1 (CGA/VGA), 4 (EGA)
| PlaneArrangement = [[Linear CGA]], [[Row-planar EGA]], Linear VGA
| HasTransparency = N
| HasHitmap = N
| Metadata = None
| Subtilesets = N
| Compressed = N
| Hidden = N
| Games =
{{Game|Dangerous Dave}}
}}
Apart from the interface graphics (menu, font, etc.) [[Dangerous Dave]] stores its graphics in three files in this format. The EGA graphics are stored externally in <tt>EGADAVE.DAV</tt>, while the CGA and VGA graphics are stored internally in <tt>DAVE.EXE</tt>.

These graphics in this format are the tiles and sprites, and most images used in-level.

== Compression ==

Both the CGA and VGA data (stored in the .exe) is compressed with [[Keen 1-3 RLE compression]]. (This is not counting the LZEXE compression applied to the final .exe as a whole.) The compression applies to the entire file, headers and all. The EGA data (stored in <tt>EGADAVE.DAV</tt>) is not compressed.

The game allocates a buffer of exactly 90112 (0x16000) bytes for the decompressed tile graphics, so even though the original VGA tileset only has an expanded size of 71238 bytes, there is still some space left for additional graphics.

Due to [[Keen 1-3 RLE compression#Implementation bugs|a bug in the RLE decompression code]] used by the game, great care must be taken when decompressing the original VGA tile graphicss or compressing new tile graphics that are larger than 65,280 (0xFF00) bytes.

The decompression code needs to normalize its pointers when it passes offset 0xFF00 in the output stream, but it does not do so correctly. This means no RLE compression code must run across a 65,280 byte boundary, otherwise the game will not load the graphics correctly. When compressing modified graphics this can be achieved by only compressing 65,280 bytes at a time.

For example the code <tt>0B 00</tt> ("repeat 0x00 14 times") might have to be changed to <tt>02 00 06 00</tt> ("repeat 0x00 five times, then repeat 0x00 nine times") if the 65,280 byte boundary occurs in the middle of the code. (In this case the boundary would be between the <tt>02 00</tt> code and the <tt>06 00</tt> code.) The last RLE code must result in bytes from index 0 to index 65,279 being written, with the next RLE code outputting byte 65,280. Failing to take this into account when compressing data will result in the decompression code skipping/overwriting between 1 and 15 bytes at this boundary.

For the original VGA tileset data of this game, this means after decompressing the first 65,280 bytes of the tileset data, one extra byte must be read and discarded. Failure to take this into account when reading the file will cause the last 10 images in the VGA tileset to appear as though they are 2048 pixels wide instead of 8 pixels wide.

Note that previous versions of this page said this extra byte was inserted every 65,536 bytes but this is incorrect - image #157 (the final frame in the "Dangerous Dave" title screen animation) will have the first few rows of the image come out differently to the way it looks in the game if the "padding" byte is every 65,536 bytes. Having the "padding" byte at 65,280 bytes makes more sense as this is the offset at which the RLE decoder "normalizes" its pointers incorrectly, so that's what causes the code to copy one byte fewer than it should.

Note that as this is a side effect of the RLE compression, this extra byte only needs to be handled for the CGA and VGA graphics. As the EGA graphics are not compressed, they do not have this extra byte.

== File structure ==

After decompression (if required), the file starts with the number of chunks (graphics) in the file, followed by a number of values giving the offset of each chunk.

{|class="wikitable"
!Data type!!Description
|-
|[[UINT32LE]] count||Number of images in the file
|-
|[[UINT32LE]] offsets[count]||Offset of image data
|-
|[[BYTE]] data[]||Image data
|}

There are two types of chunks, those that are 128 bytes in size are taken to be 16x16 tiles (by default the first 53 chunks are these) and consist entirely of raw graphics data with no header. Other chunks start with two [[UINT16LE]] values giving the width and height of the graphic in pixels followed by the image data.

== Image formats ==

=== CGA ===
[[Image:ddave-tileset-cga.png|frame|right|Partial CGA tileset]]
Image data is [[Linear CGA]] (like VGA but 2bpp instead of 8bpp.) In other words, it's not split up into planes like the EGA data is. The pixels are broken up in big-endian order within the byte, so this value:

11001001 (0xC9)

Would translate as four pixels of the following values:

11 00 10 01 (3, 0, 2, 1)

The actual colours for each pixel depend on the active CGA palette, of which there are three basic ones. See [[wp:Color Graphics Adapter]] for details.

=== EGA ===
[[Image:ddave-tileset-ega.png|frame|right|Partial EGA tileset]]
All EGA data is stored in the [[Row-planar EGA]] arrangement, meaning each graphic is split into rows which are then split into EGA planes.

All graphics have four planes, stored in the order I, R, G, B. Tiles are first, followed by player sprites, enemy sprites, in-level images and in-level font.

This is a very basic implementation of EGA data. The only masked sprite is the player sprite (the only sprite that needs to appear over colored tiles and other sprites - enemy sprites are drawn using XOR to avoid the mask, at the expense of causing colour changes should they ever overlap map tiles.) Masking is accomplished by storing the mask as a second, black and white image - that is, black and white EGA. The mask graphic is the same size, in pixels and bytes, as the sprite image it masks - a very wasteful way of doing things.

Dave is also interesting in that it contains graphics whose width does not divide evenly by eight pixels. As EGA data these are stored as if they divided by the next highest multiple of 8 pixels (a 26x8 image is stored like a 32x8 image, with the 'extra' space being blank.) This is standard for storing images padded to a certain byte width (e.g. .BMP images) however it is not often done in games due to the 'wasted' space.

=== VGA ===
[[Image:ddave-tileset-vga.png|frame|right|Partial VGA tileset]]
The VGA data is standard 8bpp single-plane data. The palette is stored in the main EXE file (see [[Dangerous Dave]] for its location.)

== Example code ==

* Javascript: [https://github.com/Malvineous/gamegraphicsjs/blob/master/formats/tls-ddave.js tls-ddave] in Camoto's gamegraphics.js

== Credits ==

This file format and the EGA + VGA graphics were reverse engineered by [[User:Levellass|Levellass]], and the RLE algorithm and CGA graphics were 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!)

Keen 1-3 RLE compression

2021-03-19T02:12:39Z

K1n9 Duk3: more detailed explanation of the RLE bug and how to work around it

GameMaps Format

2021-03-19T00:46:24Z

K1n9 Duk3: no truly uncomressed version has been reported yet - all currently known variations use RLEW compression

{{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|Noah's Ark 3D}}
{{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 !! Notes
|-
| Bio Menace || Yes || No || No || Uses MAPTEMP.xxx (only RLEW compression)
|-
| Blake Stone: Aliens of Gold || Yes || No || No || Uses MAPTEMP.xxx (only RLEW compression)
|-
| Blake Stone: Planet Strike || Yes || No || No || Uses MAPTEMP.xxx (only RLEW compression)
|-
| Catacomb 3-D || Yes || Yes || No ||
|-
| Catacomb Abyss || Yes || Yes || No ||
|-
| Catacomb Apocalypse || Yes || Yes || No ||
|-
| Catacomb Armageddon || Yes || Yes || No ||
|-
| Commander Keen Dreams || Yes || No || Yes ||
|-
| Commander Keen 4-6 || Yes || No || No ||
|-
| Corridor 7 Alien Invasion || Yes || No || No || Uses MAPTEMP.xxx (only RLEW compression)
|-
| Dangerous Dave 3 || Yes || No || Yes ||
|-
| Dangerous Dave 4 || Yes || No || Yes ||
|-
| Noah's Ark 3D || Yes || ? || No ||
|-
| Operation Body Count || Yes || No || No || Uses MAPTEMP.xxx (only RLEW compression)
|-
| Rescue Rover 2 || Yes || Yes || No ||
|-
| Spear of Destiny || Yes || Yes || No ||
|-
| Wolfenstein 3-D (v1.0) || Yes || No || No || Uses MAPTEMP.xxx (only RLEW compression)
|-
| Wolfenstein 3-D (v1.1 and above)|| Yes || Yes || No ||
|}

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 || UINT32LE || offPlane0 || Offset in GAMEMAPS to beginning of compressed plane 0 data (or 0 if plane is not present)
|-
| 4 || UINT32LE || offPlane1 || Offset in GAMEMAPS to beginning of compressed plane 1 data (or 0 if plane is not present)
|-
| 8 || UINT32LE || 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> || - ||
|-
| [[Blake Stone]]: Aliens of Gold || Shareware || External || <tt>MAPHEAD.BS1</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!)

EXE Format

2021-03-14T00:24:17Z

K1n9 Duk3: /* Relocation table */ explained use and structure

{{Executable Infobox
| Interpreted = N
| Platform = MS-DOS
| Code = 16-bit x86
| Hidden = Y
}}
The '''EXE format''' is used by all but the smallest DOS games to store the machine code instructions for running the game itself.

== File format ==

=== Signature ===

The first two characters of the file are "MZ". The following values (see below) will indicate the size of the .exe file, however this should not be relied upon because it is not uncommon for additional data to be appended onto the end of the .exe. The other header fields can however be inspected to ensure the values are sensible, particularly the ones about memory requirements which will never ask for more than 640 kB of memory, otherwise the file would not run on the majority of DOS machines.

=== Header ===

{|class="wikitable"
! Data type !! Name || Description
|-
| [[char]] || signature[2] || "MZ"
|-
| [[UINT16LE]] || lenFinal || Size of final block in the file, or <tt>0</tt> if the final block is a full 512 bytes.
|-
| [[UINT16LE]] || numBlocks || Number of 512-byte blocks in the file, including the final block which may not be the full 512 bytes.
|-
| [[UINT16LE]] || numReloc || Number of entries in the relocation table.
|-
| [[UINT16LE]] || pgHeader || Number of 16-byte blocks (paragraphs) in the file header, including the "MZ" and up until the machine code starts.
|-
| [[UINT16LE]] || pgMemExtra || Number of 16-byte paragraphs of extra memory that must be allocated for the program to run.
|-
| [[UINT16LE]] || pgMemMax || If the program doesn't need all available memory, this value can limit it to a smaller number of paragraphs.
|-
| [[INT16LE]] || segSS || Stack segment offset. This value is added to the load segment and set as the stack segment (<tt>SS</tt> register).
|-
| [[UINT16LE]] || regSP || Initial value of the <tt>SP</tt> (stack pointer/index into stack) register. The stack is located at the segment:offset <tt>SS:SP</tt>.
|-
| [[UINT16LE]] || checknum || Usually ignored and set to zero. Supposedly if all UINT16LE values in the file are summed they should equal zero, and this value can be tweaked to ensure that is the case.
|-
| [[UINT16LE]] || regIP || Initial value of the <tt>IP</tt> (instruction pointer) register, where execution will actually begin. This is normally 0x100 as DOS writes some information (the PSP) between memory offsets 0 and 0x100. This means the first 0x100 bytes of the file are usually 0x00 bytes to avoid code getting overwritten, however to avoid wasting this space in the .exe files, some programs set <tt>regCS</tt> to -16 which will cause everything to be shifted back by 0x100 bytes. This means the code gets loaded at offset 0, then before it gets overwritten with the PSP <tt>regCS</tt> is applied, changing the segment and making the code visible at offset 0x100 instead. Thus the PSP can be written to memory before the code and execution begins at offset 0x100, without needing 0x100 bytes of zeroes at the start of the machine code.
|-
| [[INT16LE]] || regCS || Offset for the <tt>CS</tt> (code segment) register relative to the segment the code was loaded in. Execution begins at <tt>CS:IP</tt> so a value of <tt>1</tt> would skip the first 16 bytes of code that follows the .exe header. May be negative.
|-
| [[UINT16LE]] || offReloc || Offset of the first entry in the relocation table, relative to the start of the .exe file. Increasing this value allows more data to be stored in the .exe header. [[PKLite]] for example uses it to store a copyright message.
|-
| [[UINT16LE]] || overlayIndex || Overlay number, or zero for the main .exe file. Rarely used.
|}

Additional data can appear in the header until <tt>offReloc</tt> is reached where the relocation table begins.

=== Relocation table ===

The relocation table consists of a number of four-byte entries. Beginning at offset <tt>offReloc</tt> from the start of the file and continuing until <tt>numReloc</tt> four-byte entries have been read.

Additional data can appear after the relocation table, until offset <tt>pgHeader * 16</tt> where the machine code begins.

The relocation table lists all the instances in the machine code part of the executable that contain a segment address, either in the form of a pure segment address or as part of a far jump, far pointer or a far function call. These segment addresses are stored in the file as relative values (relative to the beginning of the machine code) and need to be adjusted ("relocated") to the absolute memory position into which the executable is loaded.

Each entry in the relocation table consists of two [[UINT16LE]] values. The first value is an offset and the second one is a paragraph address. The full address can be calculated from this as <tt>offset + paragraph * 16</tt>. This address itself is relative to the beginning of the machine code, so adding <tt>pgHeader * 16</tt> to it would give the absolute position inside the .EXE file where the segment address that needs to be adjusted is stored. The relocation modifies that byte as well as the one following after it.

When modifying the code inside an exectuable file, it is vital to keep track of the bytes that need relocation, as the relocation process will modify those bytes and potentially break whatever code was inserted at that point. While it is possible to work around that limitation, the better alternative is to just add or remove relocation table entries as required.

It does not seem to matter how the full address is split into the offset and paragraph parts for the relocation table entries, as long as the offset is never set to 0xFFFF and <tt>offset + paragraph * 16</tt> matches the intended address. Setting the paragraph address to <tt>address / 16</tt> and the offset to <tt>address % 16</tt> should work fine for any address.

=== Machine code ===

The actual machine code that runs begins at the end of the .exe header (file offset <tt>pgHeader * 16</tt>) and continues until the last (possibly partial) block has been read. This can be calculated like so:

lenCode = numBlocks * 512
if (lenFinal != 0) {
// Last block is not 512 but less than this, so adjust it.
lenCode = lenCode - 512
lenCode = lenCode + lenFinal
}

After this point it is possible for more data to be stored in the .exe, but it will not be loaded into memory by DOS and is essentially ignored. Some games use this to store extra game data in their main .exe, opening their own .exe file at runtime to read out the extra data. These can often be spotted by the fact that the .exe file is much larger than one that will typically fit into memory.

To calculate the offset of this extra data, find the beginning of the code (<tt>pgHeader * 16</tt>) and add the size of the code (<tt>lenCode</tt> above). This will be the offset of the trailing data, or if there is none, it will match the size of the .exe file itself.

== Compression ==

A few schemes exist to compress .exe files while still leaving them executable. These work by compressing the original code and inserting a small decompression routine at the start of the data. When DOS loads the .exe into memory, it ends up running the decompression routine instead of the original code. This routine expands the compressed data and then passes control to it so the program appears to work as normal. The trick with this process is figuring out how to decompress the data while using as little extra memory as possible, as most .exe files take up large amounts of memory and there is typically not enough memory to store both the compressed and decompressed code at the same time. So the decompressor must carefully expand the data such that it overwrites only the compressed data that has already been decompressed and is no longer needed.

Typically the .exe file headers are set up such that DOS will load both the decompression routine and the compressed code into memory at the same time, so the decompressor does not have to worry about opening and reading files.

The individual compression schemes are documented on their own pages, but they refer back to the .exe headers described here. There are many more schemes than listed here as this list only includes those used by games documented on this wiki.

* [[LZEXE]]
* [[PKLite]]

== Successors ==

The .exe format has been extended to add functionality and to work on other platforms:

* [[New Executable (NE) Format]] was introduced with 16-bit Windows.
* [[Linear Executable (LX/LE) Format]] adds 32-bit support and was used by many DOS games from the late 1990s running in protected mode (DOS4GW).
* [[Portable Executable (PE) Format]] was introduced with 32-bit Windows.

Most of these extensions are backwards compatible in that a small "MZ" stub is included that prints an error if the file is run on a platform that does not support the extensions.

== Tools ==

{{BeginFileFormatTools|Type=exe}}
{{FileFormatTool
| Name = MS-DOS debug.exe
| Platform = MS-DOS
| canView = Yes
| canCreate = No
| canModify = No
| canCompress = No
| canDecompress = No
| editHidden = Yes
| notes = Loads into correct offsets, disassemble with "u" command.
}}
{{FileFormatTool
| Name = [[LZEXE]]
| Platform = MS-DOS
| canView = No
| canCreate = No
| canModify = No
| canCompress = Yes, LZEXE
| canDecompress = No
| editHidden = No
}}
{{FileFormatTool
| Name = [[PKLite]]
| Platform = MS-DOS
| canView = No
| canCreate = No
| canModify = No
| canCompress = Yes, PKLite
| canDecompress = Yes, PKLite
| editHidden = No
}}
{{FileFormatTool
| Name = [[LZEXE|UNLZEXE]]
| Platform = MS-DOS
| canView = No
| canCreate = No
| canModify = No
| canCompress = No
| canDecompress = Yes, LZEXE
| editHidden = No
}}
{{FileFormatTool
| Name = [https://github.com/devbrain/mz-explode/ mz-explode]
| Platform = Portable
| canView = No
| canCreate = No
| canModify = No
| canCompress = No
| canDecompress = Yes, [[LZEXE|LZEXE]], [[PKLite|PKLite]], [[Knowledge Dynamics LZW COMPRESSOR|KNOWLEDGE DYNAMICS]], [[Microsoft EXEPACK|EXEPACK]]
| editHidden = No
| notes = C++ library
}}
{{EndFileFormatTools}}

== Credits ==

The .exe structure was taken from the [http://www.delorie.com/djgpp/doc/exe/ DJGPP documentation]. 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!)

Monster Bash Sprite Format

2021-03-13T00:03:29Z

K1n9 Duk3: /* File format */ shifted sprites have an odd quirk

{{Tileset Infobox
| ImageNativeWidth = Y
| Hardware1 = EGA
| MaxTiles = Unlimited
| Palette = Shared
| Names = N
| TileMinSize = 0
| TileMaxSize = 255×255
| NumPlanes = 5
| PlaneArrangement = Variable
| HasTransparency = Yes
| HasHitmap = Yes, as a rectangle
| Metadata = None
| Subtilesets = N
| Compressed = N
| Hidden = N
| Games =
{{Game|Monster Bash}}
{{Game|Scubaventure}}
}}

A Monster Bash sprite contains multiple 16-colour EGA images (for example, an enemy sprite contains all the animation frames for that sprite.) This format is trickier than most, as it contains an arbitrary number of colour planes - the EGA contains four colour planes (red, green, blue and intensity) but each plane in the Monster Bash sprite can refer to multiple EGA planes ''at the same time'' (so you could have a "magenta plane" in the file, which puts data into the EGA red and blue planes at the same time!)

== File format ==

=== Signature ===

All sprite files begin with a single 0xFF byte. The games never checks this value and just skips past it. To correctly detect this file format, the following tests can be used:

* The last image block should end at the end of the file, there should be no trailing data (except a possible trailing 0x00 depending on the decompressor used)
* The last byte in each image block should be 0x00 to signal the final plane of image data

=== Image list ===

A number of image blocks immediately follow the signature byte, repeating until EOF:

{|class="wikitable"
!Data type!!Description
|-
|UINT16 iSize||Size of this sprite
|-
|BYTE cData[iSize]||Block of image data, iSize bytes long
|}

=== Image format ===

Each of the blocks of image data in the above structure contains an image header, followed by multiple planes of data. The header looks like this:

{|class="wikitable"
!Data type!!Description
|-
|UINT8 iFlags||Flags/shifts
|-
|UINT8 iHeight||Height of the image in pixels
|-
|UINT8 iWidth||Width of the image in pixels
|-
|UINT8 iReserved||Must always be set to zero (The game occasionally treats iWidth as a [[UINT16LE]])
|-
|INT16LE iHotspotX||Image is offset by this many pixels (see below)
|-
|INT16LE iHotspotY||Image is offset by this many pixels
|-
|UINT16LE iRectX||Right-coordinate of collision rectangle (object position is left-coordinate)
|-
|UINT16LE iRectY||Bottom-coordinate of collision rectangle (object position is top-coordinate)
|}

The upper four bits of <tt>iFlags</tt> can be one or more of these values:

{|class="wikitable"
! Value !! Description
|-
| 1 || Unused/unknown
|-
| 2 || Set if the sprite is wider than 64 pixels (tells engine to use fallback drawing routine)
|-
| 4 || Unused/unknown
|-
| 8 || Unused/unknown
|}

The lower four bits of <tt>iFlags</tt> specify the number of shifts a sprite has. These make drawing graphics faster on non-byte boundaries. Most sprites have a value of 1 here (no shifts, just the original image) which makes the game perform any shift at drawing time. Sprites that need to be drawn frequently (such as projectiles) typically have a higher value here (2, 4 or 8.) This causes the game to generate this many shifts when loading the sprite, to speed up drawing at the expense of taking up more memory. The "rock" sprite is one of the few that have frames with a shift value other than 1.

If a sprite has a shift count greater than 1, the game expects the <tt>iPlaneBits</tt> value of the first image block to be the same as the width (in bytes) of the image. The game uses this value to calculate <tt>iPlaneSize</tt> as <tt>iWidth * iPlaneBits</tt>. This value is then used to calculate total number of image planes for the current sprite, so that the code knows how big the buffer for the shifted copies must be. This quirk means that the color planes for shifted sprites cannot be chosen as freely as those for non-shifted sprites, possibly increasing the size of the sprite data by another plane.

The "object position" as tracked by the game is the top-left corner of the collision rectangle. <tt>iRectX</tt> and <tt>iRectY</tt> indicate the bottom-right corner of the collision rectangle. <tt>iHotspotX</tt> and <tt>iHotspotY</tt> indicate how far up and to the left the image should be shifted. These (usually negative) values should be added to the object location to draw the sprite frame at the correct location. For instance if <tt>iHotspotX</tt> is -5, then the image is shifted left by five pixels, so the object location is at x=5 (five pixels into the image). Tweaking these variables allows the collision rectangle to be set arbitrarily, with the only restriction being that the object location tracked by the game will always be part of the collision rectangle.

After this header, a number of data planes follow one after the other. Each plane of data can contain the image data for '''multiple''' EGA planes. For example, if EGA plane 1 is blue and EGA plane 2 is green, then a single Monster Bash plane can have a bit flag for 3, which means the data is for EGA plane 1 '''and''' 2 (<code>1 | 2 == 3</code>).

The very first plane in the image is always transparency, and the <tt>iPlaneBits</tt> has special meaning here - it is set to the width of the image, in bytes. This can be calculated with the formula <tt>width_bytes = (width_pixels + 7) / 8</tt>. Each plane is of the following structure:

{|class="wikitable"
! Data type !! Name !! Description
|-
| UINT8 || iPlaneBits || Which colours this plane holds (or image width in bytes, for transparency plane)
|-
| BYTE[iPlaneSize] || cPlaneData || Plane data, one bit-per-pixel
|}

<tt>iPlaneSize</tt> is the size of the data in the plane. In order to calculate this, you must take the width of the image (in pixels, obtained from the frame's header above) and round this up to the nearest byte boundary. For example, if the image is eight pixels wide, it will take up eight bits which fits in one byte. If the image is nine pixels wide, this will take up nine bits, so two bytes are required to hold each scanline of data. The plane size is then the number of bytes in a scanline multiplied by the image height. You can use a formula like one of the following to calculate the various values, where width and height are the image dimensions in pixels:

bits per scanline = width + (8 - (width % 8))
bytes per scanline = (width + 7) / 8
bytes per plane = bytes per scanline * height

An image that's 56x99 pixels, should have a plane size of 693 bytes (7 bytes per scanline.)

<tt>iPlaneBits</tt> indicates which EGA planes the data applies to. If this value is zero the end of the data has been reached. If for example the value is 0x06, this means the plane should be drawn on EGA plane 0x02 and EGA plane 0x04.

This means a given EGA plane (say red, or green) can be updated by multiple image planes. To handle this, each plane's data should be applied using an XOR operation, so that a one-bit in the incoming plane will flip the bit for that colour in the image (so it may get flipped on in one plane, but flipped off again when the next plane is read in.)

Once the image plane identified by 0x00 has been reached, the rendering of the image is complete. There is no data following <tt>iPlaneBits</tt> in this case.

Note that it is possible to set a colour for a transparent pixel. If this is done (i.e. a transparent pixel is not set to black in the other planes) the value will be combined (via XOR) with whatever is behind it. To get proper transparency, those pixels that are transparent should always be set to black.

== Notes ==

* The number of image planes is not stored in the file. The only known way of precalculating this is by working it out from the size of the image. The alternative of simply reading in image planes until one for bit 0 is reached is also undesirable, as a corrupt image could result in the program reading far too much data out of the file. Even a rough calculation of the number of image planes will act as a safeguard against this.

* If an image is not a multiple of eight pixels across, the last byte on each row will contain unused pixels. These pixels must be set to black and marked as transparent, otherwise the game will draw them but fail to erase them as they are past the edge of the image. This will leave a trail of visual artefacts as the sprite moves around.

== Tools ==

{{BeginFileFormatTools|Type=image}}
{{FileFormatTool
| Name = [[Camoto]]
| Platform = Linux/Windows
| canView = Yes
| canExport = Yes
| canImport = Yes
| editMetadata = N/A
}}
{{FileFormatTool
| Name = [[Wombat]]
| Platform = Windows GUI
| canView = Yes
| canExport = Yes
| canImport = No
| editMetadata = N/A
}}
{{EndFileFormatTools}}

== Credits ==

This file format was reverse engineered by [[User:Malvineous|Malvineous]]. Key parts (shifts, flags, transparency planebits special case) were reverse engineered 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!)

Monster Bash Level Format

2021-03-12T23:23:43Z

K1n9 Duk3: /* Background layer */ The first two bytes are actually two UINT8 values (width and height in tiles)

{{NeedMoreInfo}}
{{Map Infobox
| Type = 2D tile-based
| Layers = 3
| Tile size = 16×16
| Viewport = 320×200
| Games =
{{Game|Monster Bash}}
{{Game|Scubaventure}}
}}
[[Monster Bash]] stores its levels across a number of different files inside <tt>[[DAT Format (Monster Bash)|BASHx.DAT]]</tt>. Annoyingly, many of the files have the same filename and only differ in the 'filetype code' also stored in the .DAT file.

== Map description file ==

Each map contains a file (of .DAT filetype code #0) which contains the filenames of the other associated files for the level. The file contains a number of fixed-length strings of 31 bytes each, corresponding to a filename in the main .DAT file. Note that the DAT file will have multiple files matching the names used here, so the DAT filetype codes (or fake filename extensions) are used to differentiate between particular files.

{|class="wikitable"
! Data type !! Description !! DAT filetype code/extension
|-
| [[char]] bgtiles[31] || Filename of the background tileset || 3 (.tbg)
|-
| [[char]] fgtiles[31] || Filename of the foreground tileset || 4 (.tfg)
|-
| [[char]] bonustiles[31] || Filename of the bonus tileset || 5 (.tbn)
|-
| [[char]] sprites[31] || Name of the sprite list || 6 (.sgl)
|-
| [[char]] palette[31] || Filename of the palette file(?) || 14 (.pal)
|-
| [[char]] sounds[31] || Filename of the PC speaker sound effects || 8 (.snd)
|-
| [[char]] unknown[31] || Unused slot? (contains "UNNAMED") || N/A
|}

== Tilesets ==

Each map file uses three tilesets - one for the background and two for the foreground (called ''bonus'' and ''fg'' below.) See [[DAT Format (Monster Bash)]] for details on the file types and image format. The animation frames for each sprite are stored in separate files (one file per sprite.)

== Background layer ==

The background layer is a list of 16-bit indices into the background tileset. It is stored in a file of .DAT filetype code #1.

{|class="wikitable"
! Data type !! Description
|-
| [[UINT8]] mapWidth || Width of map, in tiles
|-
| [[UINT8]] mapHeight || Height of map, in tiles
|-
| [[UINT16LE]] mapWidthBytes || Width of map, in bytes (divide by two to get width in tiles)
|-
| [[UINT16LE]] pixelWidth || Width of map, in pixels (divide by 16 to get width in tiles)
|-
| [[UINT16LE]] pixelHeight || Height of map, in pixels (divide by 16 to get height in tiles)
|-
| [[UINT16LE]] tiles[mapWidth * mapHeight] || Tile codes, one per tile
|}

The lower nine bits of each tilecode are indices into the background tileset (so if <code>tilecode & 0x1FF</code> was 2, the third tile from the background tileset would be drawn at that location.)

The upper seven bits control the tile's behaviour:

{|class="wikitable"
! Bit !! Binary (Decimal) !! Mask !! Purpose when bit is 1
|-
| 1 || 0000001 (1) || 0x0200 || Can't walk right into tile
|-
| 2 || 0000010 (2) || 0x0400 || Can't walk left into tile
|-
| 3 || 0000100 (4) || 0x0800 || Can't fall down through tile (i.e. ground tiles you stand on)
|-
| 4 || 0001000 (8) || 0x1000 || Can't jump up through tile
|-
| 5 || 0010000 (16) || 0x2000 || Foreground tile contains an interactive item (point, spear, zombie spawning grave, etc.)
|-
| 6 || 0100000 (32) || 0x4000 || Slanted tile (direction controlled by foreground tile)
|-
| 7 || 1000000 (64) || 0x8000 || Climbable (ladder)
|}

== Foreground layer ==

The foreground layer is a list of 8-bit indices into the two masked tilesets. It is stored in a file of .DAT filetype code #2 (.mfg).

{|class="wikitable"
! Data type !! Description
|-
| [[UINT16LE]] mapWidth || Width of map, in tiles
|-
| [[BYTE]] tiles[mapWidth * mapHeight] || Tile codes
|}

The height of the layer is the same as for the background layer. If the background layer is unavailable, it can be approximated by dividing the file's size by the map width, but as some files have an extra 0x00 byte at the end this method requires a little more effort to work correctly.

Each byte represents an index to the tileset. Values with the high bit unset (less than 128) are indices into the ''bonus'' tileset, and values with the high bit set (>= 128) are indices into the ''fg'' tileset (so a map code of 129 refers to the second tile in the ''fg'' tileset.)

Foreground tiles are drawn at the very front (obscuring background tiles and sprites), while the bonus tiles are drawn behind sprites, only obscuring the background tiles.

== Sprite layer ==

The sprite layer is a list of sprite filenames and their coordinates. It is stored in a file of .DAT filetype code #7 (.msp), while the sprites themselves are .DAT filetype code #64 (.spr).

The sprite layer begins with an unknown [[UINT16LE]] value which always seems to be 0xFFFE, followed by the below structure repeated until EOF.

{|class="wikitable"
! Data type !! Description
|-
| [[UINT32LE]] len || Length of this structure, including this field
|-
| [[UINT32LE]] unknown || Always 0x00000000
|-
| [[UINT32LE]] unknown || Unused? Changing seems to have no effect
|-
| [[UINT16LE]] unknown || Always 0x0000
|-
| [[UINT32LE]] x || X-offset, in pixels
|-
| [[UINT32LE]] y || Y-offset, in pixels
|-
| [[BYTE]] padding[22] || ?
|-
| [[char]] filename[len-44] || Sprite filename, with two terminating nulls
|}

== Sprite list (.sgl) ==

When loading a level, the engine needs to preload all sprites that will be used in the level. Each sprite must be explicitly listed (even if it's listed in the sprite layer) as well as other associated sprites, such as the knife sprite thrown by the knife-thrower. The game will misbehave if it attempts to draw a sprite that has not been loaded.

The names of these sprites are listed in the Sprite List (.sgl) file. This file contains one ASCII filename (no extension) padded with 0x00 to 31 bytes long, one after the other until EOF.

The official files store the sprite names in alphabetical order, however this is not required.

This list will always include some names, like those belonging to the player sprite and the health gauge, however others only need to be included if related sprites exist in the level. No need to load the zombie head sprites if there are no zombies in the level, for instance (doing so won't cause any harm, but may use up too much memory preventing the level from loading.)

The following table lists the sprites that should appear in this list, based on the sprites appearing in the sprite layer.

{|class="wikitable"
! Sprite name (.msp) !! Additional required sprites (.sgl)
|-
| ''(Mandatory)'' || arrows blank border border2 cat chunk dog flag float100? guage heart leaf rock? {{TODO|Maybe only if rock powerup is used?}} score splat white
|-
| main_l main_r || break_screen crack crawl_left crawl_right dirt_l dirt_r main_die main_exit main_hat_l main_hat_r main_l main_meter main_r main_stars
|-
| axe || axe
|-
| cloud || lightn
|-
| cyclops_l cyclops_r || cyclops_l cyclops_r cyc_horn_l cyc_horn_r {{TODO|Confirm these last two are needed}}
|-
| devil_l devil_r || devil_l devil_r pfork_l pfork_r
|-
| guy_jump || guy_jump
|-
| hand_l hand_r || hand_l hand_r
|-
| horse || horse
|-
| iman_l iman_r || iman_l iman_r hat
|-
| knifee || knifee knife
|-
| knifee_ud || knifee_ud knife
|-
| mouse || mouse
|-
| nemesis || main_broom (plus all main_r dependent sprites)
|-
| score1up || score1up
|-
| skelet_l skelet_r || skelet_l sketet_r jaw_l jaw_r
|-
| snake || snake
|-
| swamp_l swamp_r swamp2_l swamp2_r || swamp_l swamp_r swamp2_l swamp2_r swamp_scum2_l swamp_scum2_r swamp_scum_l swamp_scum_r
|-
| teeth_l teeth_r || teeth_l teeth_r
|-
| tman_bl tman_br || tman_bl tman_br pellet_h
|-
| tman_ld tman_lu || tman_ld tman_lu pellet_h
|-
| tman_rd tman_ru || tman_rd tman_ru pellet_h
|-
| tman_tl tman_tr || tman_tl tman_tr pellet_h
|-
| vulture || vulture vulture_l vulture_r
|-
| zb_l zb_r || zb_l zb_r zbh_l zbh_r zhead zhead_r
|}

The following table lists the sprites that should appear, based on tiles appearing in the foreground layer:

{|class="wikitable"
! Map element !! Additional required sprites (.sgl)
|-
| collapsing walkway || plank plank_r
|-
| skull (point item) || skullw
|-
| dragon || drag_b drag_eye drag_fire drag_l smoke1
|}

== 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!)

Keen 1-3 Saved game format

2021-03-12T23:16:14Z

K1n9 Duk3: some values are signed ints, removed TODO

{{Playerdata Infobox
| Config = Yes
| Storing = Score
| Games =
{{Game|Commander Keen 1-3}}
}}

[[Commander Keen 1-3]]'s saved game files are stored in <tt>SAVEDx.CKy</tt>. The same format and function is used for all 3 episodes of Keen. The files are 92 bytes long and consist of the following:

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT16LE]] || gotBattery || Have battery part? 0=no, 1=yes
|-
| [[UINT16LE]] || gotVacuum || Have vacuum cleaner part? 0=no, 1=yes
|-
| [[UINT16LE]] || gotJoystick || Have joystick part? 0=no, 1=yes
|-
| [[UINT16LE]] || gotPogo || Have pogo stick? 0=no, 1=yes
|-
| [[UINT16LE]] || gotWhiskey || Have whiskey part? 0=no, 1=yes
|-
| [[UINT16LE]] || gotKeycardR || Have red keycard? 0=no, 1=yes
|-
| [[UINT16LE]] || gotKeycardG || Have green keycard? 0=no, 1=yes
|-
| [[UINT16LE]] || gotKeycardB || Have blue keycard? 0=no, 1=yes
|-
| [[UINT16LE]] || gotKeycardY || Have yellow keycard? 0=no, 1=yes
|-
| [[UINT16LE]][16] || levelDone || 16 values for each level, 0=incomplete, 1=completed. With the 32 levels patch this becomes 32 1-byte entries.
|-
| [[INT16LE]] || numLives || Number of lives Keen has left
|-
| [[UINT16LE]] || ammo || Number of shots Keen has left
|-
| [[INT32LE]] || score || Player score
|-
| [[INT32LE]] || posX || Location on world map, in "global" units (256 units = 1 pixel, 4096 units = 1 tile)
|-
| [[INT32LE]] || posY || Location on world map, in "global" units (256 units = 1 pixel, 4096 units = 1 tile)
|-
| [[INT32LE]] || viewportX || Location of left of visible screen, in "global" units. Usually player location minus nine tiles.
|-
| [[INT32LE]] || viewportY || Location of top of visible screen, in "global" units. Usually player location minus three tiles, but variable.
|-
| [[UINT16LE]][9] || cities || In Keen 2, cities saved. 9 2-byte entries, the last seems not to be a valid city, but is kept in memory.
|}

Keycard values are usually set to 0 in saved games, since saving the game is only allowed on the world map and the game takes away all keycards when exiting a level in any way. Because this behavior only changes the keycard values when returning to the world map, loading a saved game that has the keycard values set to 1 will allow the player to enter any level with the keycards still in the inventory.

== Notes ==

* Keen needs the 'pogo got' value in all 3 episodes of Keen, even though he's never without it and it's never displayed in episodes 2 or 3.

== Credits ==

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

Commander Keen 4-6

2021-03-12T22:42:00Z

K1n9 Duk3: /* Tools */ added all known offsets (copied from GalaxyView). Still missing KEEN5C v1.0

{{Game Infobox
| Title = Commander Keen 4.png
| Levels = Edit
| Tiles = Edit
| Sprites = Edit
| Fullscreen = Edit
| Sound = Edit
| Music = Edit
| Text = Edit
| Story = Edit
| Interface = Edit
}}
'''Commander Keen: Goodbye Galaxy''' is a very popular platform scroller, which set the benchmark for this style of game on a PC.

There is a large amount of modding info in the [[keenwiki:Galaxy Tools|modding section of the KeenWiki]] and there is an extensive [[keenwiki:Category:Patches|patch library]] allowing the game to be extended and changed considerably.

== Tools ==

{{BeginFileFormatTools|Type=game}}
{{FileFormatTool
| Name = [[keenwiki:Abiathar|Abiathar]]
| Platform = Windows
| grp = N/A
| map = Edit
| gfx = No
| mus = Replace
| sfx = Edit
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [[CKPatch]]
| Platform = DOS
| grp = N/A
| map = No
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = Yes
}}
{{FileFormatTool
| Name = [[keenwiki:IMF Creator|IMF Creator]]
| Platform = Windows
| grp = N/A
| map = No
| gfx = No
| mus = Create
| sfx = No
| txt = No
| sav = No
| exe = Yes
}}
{{FileFormatTool
| Name = [[keenwiki:Keen: Next (level editor)|Keen: Next]]
| Platform = Windows
| grp = N/A
| map = Edit
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [[keenwiki:Keengraph|Keengraph]]
| Platform = DOS/Win/Linux
| grp = N/A
| map = No
| gfx = Edit
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [[keenwiki:KeenWave|KeenWave]]
| Platform = DOS/Win/Linux
| grp = N/A
| map = No
| gfx = No
| mus = Replace
| sfx = Edit
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = EModKeen/LModKeen
| Platform = Win/Linux
| grp = N/A
| map = No
| gfx = Edit
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [[keenwiki:ModKeen|ModKeen]]
| Platform = DOS
| grp = N/A
| map = No
| gfx = Edit
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [[keenwiki:The Omegamatic|The Omegamatic]]
| Platform = Windows
| grp = N/A
| map = Edit
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [[keenwiki:The Photachyon Transceiver|The Photachyon Transceiver]]
| Platform = Windows
| grp = N/A
| map = Edit
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [[keenwiki:Startext|Startext]]
| Platform = DOS
| grp = N/A
| map = No
| gfx = No
| mus = No
| sfx = No
| txt = Edit
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [[TED5]]
| Platform = DOS
| grp = N/A
| map = Edit
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [[Wombat]]
| Platform = Windows
| grp = N/A
| map = View
| gfx = View
| mus = View
| sfx = View
| txt = View
| sav = No
| exe = No
}}
{{EndFileFormatTools}}

 
{{BeginGameFileList}}
{{GameFile
| Name = audio.ck[456]
| Format = [[AudioT Format]], [[IMF Format]]
| KnownFormat = Yes
| Desc = Sound and music
}}
{{GameFile
| Name = config.ck[456]
| Format = [[Keen 4-6 Configuration File]]
| KnownFormat = No
| Desc = Settings and high scores
}}
{{GameFile
| Name = egagraph.ck[456]
| Format = [[EGAGraph Format]]
| KnownFormat = Yes
| Desc = Graphics, text and miscellaneous data
}}
{{GameFile
| Name = gamemaps.ck[456]
| Format = [[GameMaps Format]]
| KnownFormat = Yes
| Desc = Level maps
}}
{{GameFile
| Name = keen[456]e.exe
| Format = [[B800 Text]], [[Keen 4-6 Action Format]]
| KnownFormat = Yes
| Desc = There are a couple of text screens in the main .EXE file (including the text displayed on the screen when you quit)
}}
{{GameFile
| Name = keen[456]e.exe
| Format = [[Keen 4-6 Action Format]]
| KnownFormat = Yes
| Desc = Sprite behaviours are governed by this
}}
{{GameFile
| Name = keen[456]e.exe
| Format = [[Keen 4-6 Tileinfo Format]]
| KnownFormat = Yes
| Desc = Tile information are governed by this
}}
{{EndGameFileList}}

The main executable also contains a number of important blocks of data. The offsets below apply after removing LZEXE compression. "xGA" refers to "CGA" or "EGA" depending on the game variant.

{|class="wikitable"
!rowspan=2| File !!rowspan=2| Size !!rowspan=2| Version
!colspan=2| AUDIOHED.CKx
!colspan=2| AUDIODCT.CKx
!colspan=2| MAPHEAD.CKx
!colspan=2| MAPDICT.CKx
!colspan=2| xGAHEAD.CKx
!colspan=2| xGADICT.CKx
|-
! Offset !! Length
! Offset !! Length
! Offset !! Length
! Offset !! Length
! Offset !! Length
! Offset !! Length
|-
|rowspan=3| KEEN4C.EXE || 248480 || 1.0
| 131984 || 652
| 216486 || 1024
| 146880 || 402 + 23004
| N/A || N/A
| 132640 || 14232
| 217510 || 1024
|-
| 248496 || 1.1
| 132000 || 652
| 216502 || 1024
| 146896 || 402 + 23004
| N/A || N/A
| 132656 || 14232
| 217526 || 1024
|-
| 253056 || 1.4
| 136096 || 652
| 221020 || 1024
| 151008 || 402 + 23004
| N/A || N/A
| 136752 || 14256
| 222044 || 1024
|-
|rowspan=7| KEEN4E.EXE || 262240 || Demo
| N/A || N/A
| N/A || N/A
| 136336 || 402 + 23004
| N/A || N/A
| 159744 || 18780
| 229382 || 1024
|-
| 258064 || 1.0
| 141696 || 652
| 224758 || 1024
| 156592 || 402 + 23004
| N/A || N/A
| 142352 || 14232
| 225782 || 1024
|-
| 259232 || 1.1
| 142672 || 652
| 225922 || 1024
| 157568 || 402 + 23004
| N/A || N/A
| 143328 || 14232
| 226946 || 1024
|-
| 259920 || 1.2
| 143264 || 652
| 226612 || 1024
| 158176 || 402 + 23004
| N/A || N/A
| 143920 || 14256
| 227636 || 1024
|-
| 263488 || 1.4
| 146416 || 652
| 230134 || 1024
| 161328 || 402 + 23004
| N/A || N/A
| 147072 || 14256
| 231158 || 1024
|-
| 263488 || 1.4f
| 146416 || 652
| 230134 || 1024
| 161328 || 402 + 23004
| N/A || N/A
| 147072 || 14256
| 231158 || 1024
|-
| 264864 || 1.4g
| 147664 || 652
| 231382 || 1024
| 162576 || 402 + 23004
| N/A || N/A
| 148320 || 14256
| 232406 || 1024
|-
|rowspan=2| KEEN5C.EXE || ? || 1.0
| ? || ?
| ? || ?
| ? || ?
| N/A || N/A
| ? || ?
| ? || ?
|-
| 255248 || 1.4
| 138944 || 828
| 222600 || 1024
| 154576 || 402 + 23688
| N/A || N/A
| 139776 || 14790
| 223624 || 1024
|-
|rowspan=3| KEEN5E.EXE || 262176 || 1.0
| 146032 || 828
| 228234 || 1024
| 161664 || 402 + 23688
| N/A || N/A
| 146864 || 14796
| 229258 || 1024
|-
| 266096 || 1.4
| 149632 || 828
| 232132 || 1024
| 165264 || 402 + 23688
| N/A || N/A
| 150464 || 14796
| 233156 || 1024
|-
| 267616 || 1.4g
| 151008 || 828
| 233508 || 1024
| 166640 || 402 + 23688
| N/A || N/A
| 151840 || 14796
| 234532 || 1024
|-
|rowspan=3| KEEN6C.EXE || 256656 || 1.0
| 130848 || 760
| 222626 || 1024
| 148288 || 402 + 23904
| N/A || N/A
| 131616 || 16665
| 223650 || 1024
|-
| 261984 || 1.4
| 135728 || 760
| 227888 || 1024
| 153168 || 402 + 23904
| N/A || N/A
| 136496 || 16665
| 228912 || 1024
|-
| 261456 || 1.5
| 135072 || 760
| 227232 || 1024
| 152512 || 402 + 23904
| N/A || N/A
| 135840 || 16665
| 228256 || 1024
|-
|rowspan=5| KEEN6E.EXE || 236112 || Demo
| 123872 || 588
| 203328 || 1024
| 137568 || 402 + 19152
| N/A || N/A
| 124464 || 13098
| 204352 || 1024
|-
| 238368 || Promo
| 126224 || 588
| 205590 || 1024
| 139920 || 402 + 19152
| N/A || N/A
| 126816 || 13098
| 206614 || 1024
|-
| 266032 || 1.0
| 140320 || 760
| 230674 || 1024
| 157776 || 402 + 23904
| N/A || N/A
| 141088 || 16683
| 231698 || 1024
|-
| 271696 || 1.4
| 145488 || 760
| 236270 || 1024
| 162944 || 402 + 23904
| N/A || N/A
| 146256 || 16683
| 237294 || 1024
|-
| 270896 || 1.5
| 164528 || 760
| 235342 || 1024
| 181984 || 402 + 23904
| N/A || N/A
| 165296 || 16683
| 236366 || 1024
|}

Note that the offsets and EXE sizes given here are only valid for files that have been decompressed with UNLZEXE. Decompressing the executables with other utilities like UNP may generate executables with a slightly different header size and therefore the size of the executable will not match the values listed above and the offsets will be invalid for such files.

=== AudioT Format Details ===

Keen 4, 5 and 6 use the compressed version of the [[AudioT Format]] to store music and sound. The main audio file for each game, the AUDIOT.xxx file, is called AUDIO.CKx (for example, AUDIO.CK4 for Keen 4).

The two secondary files needed for this format, the AUDIOHED.CKx and AUDIODCT.CKx, are embedded inside the main .exe file of each game as listed above.

== Related Links ==

* [[Commander Keen 1-3]]
* [[Commander Keen Dreams]]
* The [[KeenWiki:Main Page|Commander Keen Wiki]]

[[Category:Apogee]]
[[Category:id Software]]
[[Category:Sidescroller]]

Talk:Commander Keen 4-6

2021-03-12T02:18:43Z

K1n9 Duk3: reply to Szevvy

Can we get the save game format up here?
[[User:Lemm|Lemm]] 08:09, 21 October 2010 (GMT)

: How would that be done? I know the format of Keen 4-6 roughly, as well as several games related to it (Keen Dreams, Dangerous Dave 3/4, Biomenace, Catacomb 3D...) what would we title the page, would every game have a different format though they're broadly similar? --[[User:Levellass|Endian? What are you on about?]] 05:17, 9 November 2010 (GMT)

:: Does the Keen engine have a name? Otherwise you could just call the page [[Keen 4-6 Savegame Format]] and link to it from the other game pages, a bit like how some Xargon and Jill of the Jungle pages link to each other because of shared formats. At any rate if you have the info it'd be better to document it anywhere here and we can clean it up later! -- [[User:Malvineous|Malvineous]] 23:12, 14 November 2010 (GMT)

So I've got offsets for most of the exe data - map, audio, etc - in Wombat, under scripts/games/commander keen 4-6.script.txt. I know mine are correct, because I've tested to make sure maps etc work across all the versions I support. Looking at the exe table, the values filled out (Keen 4 1.4, Keen 5 1.4) are different to mine for the maphead, which makes me reluctant to fill the rest out. I suspect what's going on is that Wombat decompresses lzexe compressed exes differently to whatever was used to get the offsets in the table...are the ones in there after putting them through unzlexe, or something else? [[User:Szevvy|Szevvy]] ([[User talk:Szevvy|talk]]) 00:54, 12 March 2021 (GMT)

:: The offsets currently on the page are not absolute file positions, they are relative to the start of the executable "image". These numbers would be for use with CKPATCH for patching the mapheads directly, for example. To get an absolute file position, you would need to calculate the size of the EXE header and add that size value to the offset. See also [http://keenmodding.org/viewtopic.php?f=31&p=34490#p34490 this thread at keenmodding]. --[[User:K1n9 Duk3|K1n9 Duk3]] ([[User talk:K1n9 Duk3|talk]]) 02:18, 12 March 2021 (GMT)

Cosmo's Cosmic Adventure

2021-01-01T00:47:01Z

K1n9 Duk3: /* Game Engines */ moved STATUS.MNI to tileset section

{{Game Infobox
| Title = Cosmo's_Cosmic_Adventure.gif
| Levels = Edit
| Tiles = Edit
| Sprites = Edit
| Fullscreen = Edit
| Sound = Edit
| Music = Edit
| Text = No
| Story = No
| Interface = No
}}
'''Cosmo's Cosmic Adventure''', also known simply as Cosmo, is a three part series chronicling the adventures of Cosmo, a small, green sucker-handed alien boy who is seeking his parents after a comet collision forces them to land their ship on a dangerous and uncharted planet.

The Cosmo engine was later updated and used for [[Duke Nukem II]], so the two games share a number of file formats.

== Tools ==

{{BeginFileFormatTools|Type=game}}
{{FileFormatTool
| Name = [[Camoto]]
| Platform = Linux/Windows
| grp = Edit
| map = Edit
| gfx = Edit
| mus = Edit
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [http://www.shikadi.net/wiki/files/moddingwiki/tools/cosmo/cosedit.zip CosEdit]
| Platform = DOS GUI
| grp = No
| map = Edit
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [https://dl.dropbox.com/u/3940020/COSGRAPH-working.zip Cosgraph]
| Platform = Windows GUI
| grp = Read
| map = No
| gfx = Edit
| mus = Edit
| sfx = Edit
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [http://www.shikadi.net/wiki/files/moddingwiki/tools/cosmo/cosmedit10.zip Cosmo Edit]
| Platform = DOS console
| grp = No
| map = Edit
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [http://www.shikadi.net/wiki/files/moddingwiki/tools/cosmo/textract.zip TExtract]
| Platform = DOS console
| grp = Read
| map = No
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [[Wombat]]
| Platform = Windows GUI
| grp = View
| map = View
| gfx = View
| mus = View
| sfx = View
| txt = View
| sav = No
| exe = No
}}
{{EndFileFormatTools}}

== Game Engines ==
[https://github.com/yuv422/cosmo-engine Cosmo-Engine] - An open source game engine for playing Cosmo's Cosmic Adventure on modern systems.

{{BeginGameFileList}}
{{GameFile
| Name = *.mni (32,000 bytes)
| Format = [[Raw EGA data#Planar|Full-screen planar EGA]]
| KnownFormat = Yes
| Desc = 320×200 full-screen images (in four planes: blue, green, red, intensity)
}}
{{GameFile
| Name = *.mni (4,000 bytes)
| Format = [[B800 Text]]
| KnownFormat = Yes
| Desc = Text screens shown at exit
}}
{{GameFile
| Name = actors.mni bd*.mni cartoon.mni masktile.mni players.mni status.mni tiles.mni
| Format = [[Cosmo Tileset Format]]
| KnownFormat = Yes
| Desc = Tilesets with 8×8 tiles
}}
{{GameFile
| Name = tileattr.mni
| Format = [[Cosmo Tile Attributes]]
| KnownFormat = Yes
| Desc = Tile properties
}}
{{GameFile
| Name = cosmo*.stn cosmo*.vol
| Format = [[VOL Format]]
| KnownFormat = Yes
| Desc = Archive file storing the game data
}}
{{GameFile
| Name = a*.mni
| Format = [[Cosmo Level Format]]
| KnownFormat = Yes
| Desc = Levels
}}
{{GameFile
| Name = m*.mni (except masktile.mni)
| Format = [[IMF Format]]
| KnownFormat = Yes
| Desc = Background music - see [[#Notes]] below
}}
{{GameFile
| Name = sounds*.mni
| Format = [[Inverse Frequency Sound format]]
| KnownFormat = Yes
| Desc = PC speaker sound effects
}}
{{GameFile
| Name = cosmo*.sv*
| Format = [[Cosmo Savegame Format]]
| KnownFormat = Yes
| Desc = Saved games. <tt>cosmo?.svt</tt> is a temporary save written at the start of each level
}}
{{GameFile
| Name = *info.mni
| Format = [[Cosmo Tileinfo Format]]
| KnownFormat = Yes
| Desc = How to lay out the actor tiles into complete frames
}}
{{GameFile
| Name = prevdemo.mni
| Format = [[Cosmo Demo Format]]
| KnownFormat = Yes
| Desc = Game demo format
}}
{{GameFile
| Name = cosmo*.cfg
| Format = [[Cosmo Config Format]]
| KnownFormat = Yes
| Desc = Game configuration format
}}
{{EndGameFileList}}

== Notes ==

* Graphics limitations and glitches:
** The masktile graphics can be corrupted by a buffer overflow by the addition of a large enough IMF music file to the [[:Category:Group Files|group file]] (usually around 40KB). (That is, the music goes over it's intended memory boundary.) This is not permanent, and will only occur until the offending file is removed or a smaller or less-complex file is imported in its place.
** Actor graphics can be corrupted by a self-contained arithmetic overflow by the addition of too many sprites. (that is, it writes to the end of the allocated block, then back around to the beginning, where it overwrites the header data.) Again, this is not permanent unless the user does not change the data in the group file.
** If an actor (a good example would be Cosmo himself) is behind a masked tile with the foreground bit set on it, any transparent regions of the tile overlapping the actor will remove those regions on the actor, showing the background instead.

*Directory miscellany:
** The game reads from the VOL and STN archive files in preference to the current directory, but will read from the current directory if the archive files are not present. Any game files in the current directory will not be read while the VOL/STN files are present. To modify a file, it will either need to be imported back into the VOL/STN, or the VOL/STN should have its entire contents extracted into the game folder and then be removed or renamed.
** A directory path (relative to the current directory) can be given on the command line. Any files that the game writes (saved games, high scores, etc.) will be written to this folder instead. This is probably to allow running the game directly from read-only media like a CD.
** The <tt>*.stn</tt> files appear to be for "standard" data common to all episodes, as the files are identical between all three games. It is a curiosity that there are three identical STN files, rather than a single <tt>cosmo.stn</tt> shared amongst all three episodes.

*Game Engine Glitches:
**In editing levels, if two or more blue moving platforms collide, the tiles that overlap will disappear. Furthermore, if Cosmo stands anywhere on any one of these platforms when they collide, he will literally be deleted from the level, and the game engine will treat him as if he had died or fallen off the bottom of the screen, restarting the level over again.
**If a player actor is not specified in a level file, a unique event can occur. The level coordinates of the player from the previous level (or any level, if using the warp cheat) carry over, meaning that the player can enter the level in a very different spot than what was intended before, even entering the level trapped inside a wall!

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

Cosmo Tileset Format

2021-01-01T00:44:38Z

K1n9 Duk3: /* Cosmo's Cosmic Adventures */ added STATUS.MNI

{{Tileset Infobox
| Hardware1 = EGA
| MaxTiles = Fixed, varies
| Palette = Default EGA
| Names = N
| TileMinSize = 8×8
| TileMaxSize = 8×8
| NumPlanes = 4-5
| PlaneArrangement = [[Raw EGA data#Byte-planar EGA data|Byte-planar]]
| HasTransparency = Y
| HasHitmap = N
| Metadata = None
| Subtilesets = N
| Compressed = N
| Hidden = N
| Games =
{{Game|Cosmo's Cosmic Adventures}}
{{Game|Duke Nukem II}}
{{Game|Major Stryker}}
}}
The Cosmo Tileset Format is the graphics format used by [[Cosmo's Cosmic Adventures]] (and later [[Duke Nukem II]]) for storing a collection of images, used for nearly all graphics in the game, from tiles to sprites to background images.

== File format ==

The format is quite simple, as it contains no header or index information, consisting simply of [[Raw EGA data]]. The file consists of a number of 8x8 tiles divided into EGA planes stored consecutively. These images then may make up larger images such as sprites o backgrounds. Most files are four plane (16-colour) however the "mask" files are five plane (16-colour + transparency.) The planes are stored in the order: transparency (0=opaque, 1=transparent), blue, green, red, intensity. This also applies to Duke Nukem II which is actually a 16-colour game, even though the VGA palette changes cleverly disguise it as 256-colour.

This means each tile will take up eight bytes per plane, or 32 bytes for a 4-plane tile and 40 bytes for a 5-plane tile. This makes it easy to seek to a particular tile's offset, or to calculate the number of tiles in the file based on its size (assuming the number of planes is known in advance.) However this is complicated by the fact that larger files are broken up into 65535 byte ($FFFF) blocks and that those blocks may be padded with random data.

If the tilesets are being displayed on-screen for a human to look at, most of them have an ideal width which makes all the tiles line up across each row. This width depends on the tileset and is shown in the table below. Some tilesets (primarily the ones used for game creatures) will have different widths depending on the creature itself (and these are stored in [[Cosmo Tileinfo Format|separate files]].)

== Known files ==

This is the list of known files in this format, along with the number of planes and the tilecount of each file.

=== Cosmo's Cosmic Adventures ===

{|class="wikitable"
!Filename!!Planes!!Tiles!!Best Width!!Purpose
|-
|actors.mni||5||4797 (file size doesn't divide evenly!)||N/A||Enemy/creature animations
|-
|bd*.mni||4||720||40||Map backdrop images
|-
|cartoon.mni||5||1632||N/A||Images for game story
|-
|masktile.mni||5||1000||40||Masked/transparent tiles for map foreground layer
|-
|players.mni||5||750||N/A||Main game character animations
|-
|status.mni||4||228||38||Background graphics for the in-game status bar
|-
|tiles.mni||4||2000||40||Solid tiles for map background layer
|-
|fonts.mni||5||100||N/A||Masked font tiles
|}

'''Notes'''

The <tt>ACTORS.MNI</tt> file consists of multiple blocks, each sized up to 65535 bytes. This means that the last 15 bytes of each full block can be ignored as they don't contain enough data to fill a tile (as said before, a masked tile has a size of 40 bytes) and no entry in <tt>ACTRINFO.MNI</tt> (see [[Cosmo Tileinfo Format]]) actually reads those bytes. This restriction might also apply to the other files, but none of them is larger than 64280 bytes.

In <tt>FONTS.MNI</tt>, a pixel will be ''solid'' if the mask bit is set, otherwise it will be transparent (just like in Duke 1). In all the other masked files, the pixel will be ''transparent'' if the mask bit is set.

=== Duke Nukem II ===

{|class="wikitable"
!Filename!!Planes!!Tiles!!Best Width!!Purpose
|-
|czone*.mni||4/5||100/160||40||Map background/foreground tiles (see [[Duke Nukem II CZone Format]])
|-
|drop*.mni||4||720||40||Map backdrop images
|}

'''Notes'''

<tt>ACTORS.MNI</tt> also is in this format, but with mixed entry types. Most entries are 5-plane graphics (masked), but there are also some 2-plane graphics (with one plane used as a mask) included, which store the bigger (8×16 pixel) font used in the menus.

=== Major Stryker ===

See [[Major Stryker Tileset Format]]. The format is identical except most tiles are 16×16 instead, although a couple of tilesets are in Cosmo format.

== Credits ==

This file format was reverse engineered by [[User:Malvineous|Malvineous]], [http://archive.shikadi.net/sites/www.geocities.com/dooknookimklassik/ among others]. 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!)

Mystic Towers

2019-10-13T23:50:49Z

K1n9 Duk3: the DOS version doesn't use the Amiga sprite banks

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

[[Mystic Towers]] is an isometric action/puzzle game starring the comical wizard Baron Baldric. Gameplay revolves around destroying all monsters in each tower, as well as the tower's monster generator, which requires a special bomb spell to blow up.

== Tools ==

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

{{BeginGameFileList}}
{{GameFile
| Name = *.dat
| Format = [[DAT Format (Mystic Towers)]]
| KnownFormat = Yes
| Desc = Archive storing most of the game data
}}
{{GameFile
| Name = *.fnt
| Format = 8×8 monochrome font bitmap
| KnownFormat = Yes
| Desc = 8×8 font
}}
{{GameFile
| Name = *.mod
| Format = [[MOD Format]]
| KnownFormat = Yes
| Desc = Protracker Modul (Music)
}}
{{GameFile
| Name = *.pcs
| Format = [[Mystic Towers PC Speaker Sound Format]]
| KnownFormat = Yes
| Desc = Archive storing PC Speaker Sounds
}}
{{GameFile
| Name = *.pcx
| Format = [[PCX Format]]
| KnownFormat = Yes
| Desc = 320×200 full-screen images '''Note:''' Mystic Towers ignores the PCX header, so all PCX images must be 320×200 pixels.
}}
{{GameFile
| Name = *.sbk
| Format = [[Mystic Towers Sound Bank Format]]
| KnownFormat = Yes
| Desc = Archive storing 8Bit signed PCM Mono Audio Files
}}
{{GameFile
| Name = *.sp
| Format = [[Mystic Towers Sprite Format]]
| KnownFormat = Yes
| Desc = Archive storing sprites. Palettes are taken from the PCX files.
}}
{{GameFile
| Name = *.spp
| Format = [[Mystic Towers Sprite Palettes Format]]
| KnownFormat = Yes
| Desc = Stores 32 colors for 'MAIN2.PCX' index 33 - 64 as 6-bit DAC RGB
}}
{{GameFile
| Name = *.tab
| Format = [[Mystic Towers Highscore Format]]
| KnownFormat = Yes
| Desc = Stores the highscore table
}}
{{GameFile
| Name = MagicID: 'AmBk'
| Format = [[Amiga OS Memory Bank]]
| KnownFormat = No
| Desc = ?
}}
{{GameFile
| Name = MagicID: 'AmSp'
| Format = [[Amiga OS Sprite Bank]]
| KnownFormat = Yes
| Desc = Archive storing sprites with 5-bit palette (never used in the DOS version)
}}
{{GameFile
| Name = MYSTMSG1
| Format = Game Messages Format
| KnownFormat = Yes
| Desc = XOR 85 coded file
}}
{{GameFile
| Name = DEMO
| Format = [[Mystic Towers Demo Format]]
| KnownFormat = No
| Desc = ?
}}
{{EndGameFileList}}

[[Category:Apogee]]

Mystic Towers Sprite Format

2019-10-13T23:34:39Z

K1n9 Duk3: fixed typos and removed the NeedMoreInfo tag

{{Tileset Infobox
| Hardware1 = VGA
| MaxTiles = 65535
| Palette = Shared
| Names = N
| TileMinSize = 0
| TileMaxSize = 255×65535
| NumPlanes = 1
| HasTransparency = Yes
| Metadata = None
| Subtilesets = N
| Compressed = N
| Hidden = N
| Games =
{{Game|Mystic Towers}}
}}

== Format ==

Files in this format begin with a generic bank header also found in other files used by [[Mystic Towers]].

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT16LE]] || iNumEntries || Number of chunks (sub-files) in this file
|-
| [[UINT32LE]][iNumEntries] || iOffsets || Offset of each chunk (from the beginning of the file)
|}

The sprite data found at each offset has the following header:

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT16LE]] || iWidth || Width of the sprite, in pixels
|-
| [[UINT16LE]] || iHeight || Height of the sprite, in pixels
|-
| [[UINT16LE]] || iUnused || Either 0 or 5. The game ignores this value.
|-
| [[INT16LE]] || iOffX || Offset for drawing the sprite; moves the sprite <tt>(iOffX & 0x3FFF)</tt> pixels to the left.
|-
| [[INT16LE]] || iOffY || Offset for drawing the sprite; moves the sprite up by <tt>iOffY</tt> pixels.
|-
|}

The Sprite header is followed directly by the image data. For every row of the image, the following data structure is repeated:

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[BYTE]] || bSkip || Skip this amount of pixels (move to the right)
|-
| [[BYTE]] || bLen || Amount of pixel bytes
|-
| [[BYTE]][bLen] || pixels || pixel data (0=transparent)
|}

After parsing one of these data blocks, the draw pointer is moved to the beginning of the next row and the next data block is processed. That means the transparent parts at the left and right side of each row have no pixel data and are to be left untouched (or set to 0 to indicate transparency).

If one of the pixel bytes in the middle of the row is 0, that pixel is also supposed to be transparent and will not be drawn by the game.

== Notes ==

Even though the sprite header stores the image width as a [[UINT16LE]], the usage of [[BYTE]] values in the row data means that each row can only have up to 255 visible pixels and that it is impossible to access anything beyond the first 510 pixels.

== Credits ==

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

Mystic Towers Sprite Format

2019-10-13T23:21:00Z

K1n9 Duk3: basic format

{{NeedMoreInfo}}
{{Tileset Infobox
| Hardware1 = VGA
| MaxTiles = 65535
| Palette = Shared
| Names = N
| TileMinSize = 0
| TileMaxSize = 255×65535
| NumPlanes = 1
| HasTransparency = Yes
| Metadata = None
| Subtilesets = N
| Compressed = N
| Hidden = N
| Games =
{{Game|Mystic Towers}}
}}

== Format ==

Files in this format begin with a generic bank header also found in other files used by [[Mystic Towers]].

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT16LE]] || iNumEntries || Number of chunks (sub-files) in this file
|-
| [[UINT32LE]][iNumEntries] || iOffsets || Offset of each chunk (from the beginning of the file)
|}

The sprite data found at each offset has the following header:

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT16LE]] || iWidth || Width of the sprite, in pixels
|-
| [[UINT16LE]] || iHeight || Height of the sprite, in pixels
|-
| [[UINT16LE]] || iUnused || Either 0 or 5. The game ignores this value.
|-
| [[INT16LE]] || iOffX || Offset for drawing the sprite; moves the srite <tt>(iOffX & 0x3FFF)</tt> pixels to the left.
|-
| [[INT16LE]] || iOffY || Offset for drawing the sprite; moves the sprite up by <tt>iOffY</tt> pixels.
|-
|}

The Sprite header is followed directly by the image data. For every row of the image, the following data structure is reapeated:

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[BYTE]] || bSkip || Skip this amount of pixels (move to the right)
|-
| [[BYTE]] || bLen || Amount of pixel bytes
|-
| [[BYTE]][bLen] || pixels || pixel data (0=transparent)
|}

After parsing one of these data blocks, the draw pointer is moved to the beginning of the next row and the next data block is processed. That means the transparent parts at the left and right side of each row have no pixel data and are to be left untouched (or set to 0 to indicate transparency, see below).

If one of the pixel bytes in the middle of the row is 0, that pixel is also supposed to be transparent and will not be drawn by the game.

== Notes ==

Even though the sprite header stores the image width as a [[UINT16LE]], the usage of [[BYTE]] values in the row data means that each row can only have up to 255 visible pixels and that it is impossible to access anything beyond the first 510 pixels.

== Credits ==

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

Mystic Towers PC Speaker Sound Format

2019-10-13T22:39:02Z

K1n9 Duk3: basic format

{{Sound Infobox
| Type = PC Speaker
| Count = 0-65535
| Rate = 50 Hz
| NumChannels = 1
| BitsPerSample = 16
| Compressed = N
| Tags = None
| Games =
{{Game|Mystic Towers}}
}}

== Format ==

Files in this format begin with a generic bank header also found in other files used by [[Mystic Towers]].

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT16LE]] || iNumEntries || Number of chunks (sub-files) in this file
|-
| [[UINT32LE]][iNumEntries] || iOffsets || Offset of each chunk (from the beginning of the file)
|}

Each sound itself is just an array of 32 [[UINT16LE]] values, so each sound has a size of 64 bytes. Each value in the array is shifted two bits to the right to convert it into a sound frequency in Hertz that is to be generated by the PC speaker.

If the resulting frequency value is 10,000 Hz or higher, no sound will be played. Otherwise the frequency value is passed as an argument to Turbo-Pascal's Sound() procedure.

== Credits ==

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

Mystic Towers

2019-10-13T22:01:46Z

K1n9 Duk3: /* Tools */ renamed format links and added a few bits

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

[[Mystic Towers]] is an isometric action/puzzle game starring the comical wizard Baron Baldric. Gameplay revolves around destroying all monsters in each tower, as well as the tower's monster generator, which requires a special bomb spell to blow up.

== Tools ==

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

{{BeginGameFileList}}
{{GameFile
| Name = *.dat
| Format = [[DAT Format (Mystic Towers)]]
| KnownFormat = Yes
| Desc = Archive storing most of the game data
}}
{{GameFile
| Name = *.fnt
| Format = 8×8 monochrome font bitmap
| KnownFormat = Yes
| Desc = 8×8 font
}}
{{GameFile
| Name = *.mod
| Format = [[MOD Format]]
| KnownFormat = Yes
| Desc = Protracker Modul (Music)
}}
{{GameFile
| Name = *.pcs
| Format = [[Mystic Towers PC Speaker Sound Format]]
| KnownFormat = Yes
| Desc = Archive storing PC Speaker Sounds
}}
{{GameFile
| Name = *.pcx
| Format = [[PCX Format]]
| KnownFormat = Yes
| Desc = 320×200 full-screen images '''Note:''' Mystic Towers ignores the PCX header, so all PCX images must be 320×200 pixels.
}}
{{GameFile
| Name = *.sbk
| Format = [[Mystic Towers Sound Bank Format]]
| KnownFormat = Yes
| Desc = Archive storing 8Bit signed PCM Mono Audio Files
}}
{{GameFile
| Name = *.sp
| Format = [[Mystic Towers Sprite Format]]
| KnownFormat = Yes
| Desc = Archive storing sprites. Palettes are taken from the PCX files.
}}
{{GameFile
| Name = *.spp
| Format = [[Mystic Towers Sprite Palettes Format]]
| KnownFormat = Yes
| Desc = Stores 32 colors for 'MAIN2.PCX' index 33 - 64 as 6-bit DAC RGB
}}
{{GameFile
| Name = *.tab
| Format = [[Mystic Towers Highscore Format]]
| KnownFormat = Yes
| Desc = Stores the highscore table
}}
{{GameFile
| Name = MagicID: 'AmBk'
| Format = [[Amiga OS Memory Bank]]
| KnownFormat = No
| Desc = ?
}}
{{GameFile
| Name = MagicID: 'AmSp'
| Format = [[Amiga OS Sprite Bank]]
| KnownFormat = Yes
| Desc = Archive storing sprites with 5-bit palette
}}
{{GameFile
| Name = MYSTMSG1
| Format = Game Messages Format
| KnownFormat = Yes
| Desc = XOR 85 coded file
}}
{{GameFile
| Name = DEMO
| Format = [[Mystic Towers Demo Format]]
| KnownFormat = No
| Desc = ?
}}
{{EndGameFileList}}

[[Category:Apogee]]

TED5

2019-08-29T21:28:08Z

K1n9 Duk3: updated 3drealms download link

{{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 [http://www.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].

[[Category:id Software]]

GameMaps Format

2019-08-29T21:15:12Z

K1n9 Duk3: /* Map data (GAMEMAPS) */ level headers are *NEVER* RLEW-compressed, but they can be Huffman-compressed

{{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}}
{{Game|Corridor 7 Alien Invasion}}
{{Game|Dangerous Dave 3}}
{{Game|Dangerous Dave 4}}
{{Game|Noah's Ark 3D}}
{{Game|Operation Body Count}}
{{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: uncompressed, [[Carmack compression|carmackized]], and [[Huffman Compression|Huffman compressed]]. 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.

== Structure of uncompressed data ==

The uncompressed format is used by several games including [[Bio Menace]] and [[Wolfenstein 3-D]]. In this format map data is stored in <tt>MAPTEMP.xxx</tt> and map headers in <tt>MAPTHEAD.xxx</tt>. This 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 filenames differ and that Wolfenstein 3-D uses <tt>GAMEMAPS.WLx</tt> and <tt>MAPHEAD.WLx</tt> files to store data (except for v1.0, which uses <tt>MAPTEMP.WLx</tt> in place of <tt>GAMEMAPS.WLx</tt>).

The main indicator of this format being used is that in the unaltered game the map header file is external.

Only the latest Id Software games lacked compression, when file size was no longer an issue.

=== Map headers (MAPHEAD) ===

{|class="wikitable"
! Offset !! Type !! Name !! Description
|-
| 0 || [[UINT16LE]] || magic || Magic word signalling [[RLEW compression]]
|-
| 2 || [[UINT32LE]][400] || ptr || 100 pointers to start of level 0-99 data in the game maps file
|-
| 402 || {{TODO|Unknown}} || tileinfo || 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 always $ABCD. 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 greater than 0 indicates no level (generally 0, but occasionally -1 (xFFFFFFFF) is used). 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 RLEW 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.

For the offsets to level planes, a value of 0 indicates the plane does not exist.

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.

{|class="wikitable"
! Offset !! Type !! Name !! Description
|-
| 0 || UINT32LE || offPlane0 || Offset in GAMEMAPS to beginning of compressed plane 0 data (or 0 if plane is not present)
|-
| 4 || UINT32LE || offPlane1 || Offset in GAMEMAPS to beginning of compressed plane 1 data (or 0 if plane is not present)
|-
| 8 || UINT32LE || 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 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> || - ||
|-
| [[Blake Stone]]: Aliens of Gold || Shareware || External || <tt>MAPHEAD.BS1</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!)

Talk:GameMaps Format

2019-08-29T20:43:24Z

K1n9 Duk3: /* InfoPlane values */ reply

The values in that table are also good for Keen Dreams, except for the !ID! tag.

== Cleaning this mess up ==

I think this page should be merged together with the [[Keen Dreams level Format]] and the [[TED5]] page to get a clean documentation of the general file format. A lot of the stuff in here is only partially correct. For example, Bio Menace (and the first version of Wolf3D) uses the uncompressed form (MAPTEMP) of the format, not the carmackized version as is implied at the end of this article and in the TED5 article (it says that the MAPTEMP file is not used by the games).

I also noticed that this article claims that the MAPHEAD file is 402 bytes long, giving it space for 256 level entries (which makes no sense at all, there are exactly 100 level offsets), but the MAPHEAD also stores the TileInfo data, giving a much larger size. You can see this in Bio Menace, where the files are external, but also in every Keen game. The TileInfo data in the exe starts directly after the MAPHEAD data (add 100 bytes in between for games that use the Huffman-compressed version, like Keen Dreams and Dave 3 & 4). --[[User:K1n9 Duk3|K1n9 Duk3]] 21:06, 11 February 2011 (GMT)

: You're welcome to clean it up, but just remember that all this stuff is work in progress so it's only a "mess" because nobody has had the time to finish it off yet. If you're able to do so, then that's great! Also don't immediately assume something is wrong because it doesn't fit what you have seen - there are many versions of games around the place so make sure you consider something carefully before deleting it (I learned that the hard way!) I don't think this page should be merged with [[TED5]] though, that page should be solely about the editor and perhaps some files that are not used elsewhere. If it's used in a game it should be on one of the "xyz Format" pages (so by all means move some stuff *off* TED5.) -- [[User:Malvineous|Malvineous]] 12:36, 12 February 2011 (GMT)

:: Yes, several points are worth noting. There should be a single article for all the TED5 formats with perhaps sections explaining the different compressions used (None-Biomenace, Huffman-Dreams,Dave3\4, Carmack-Keen) and especially a note about the tileinfo, for Keen only the 402 MAPHEAD was extracted and patched, seperate from the tileinfo, nobody really realized the two were connected and that TED could be used to edit tile properties, this is thus something of great interest to modders. I have a lot of data on what format of MAPs various games use. TED5 is a program and should be kept separate though. --[[User:Levellass|Endian? What are you on about?]] 03:46, 14 February 2011 (GMT)

== Wolfenstein-3D maps ==

"About Wolfenstein-3D (6 episodes version): after decompressing the planes, I noticed that --1-- Each plane starts with 0x0020, --2-- The third plane is always empty (except for the 0x0020), --3-- Decompressed planes are always longer than necessary: assuming every map is 64x64 tiles and a tile is stored on 2 bytes, a plane should be 8192 bytes long (8194 bytes if you count the 0x0020 signature). Am I missing something here? When displayed, the map makes sense to me but I'm just not sure if I did anything wrong..." -> Scratch that, I'm an idiot, the first UINT32LE is the size (in bytes) of the decompressed data, I thought it was a part of the RLEW-compressed chunk and had to compute the decompressed chunk size by myself... Anyway, the wiki page states that "The header for each level that is pointed to by MAPHEAD is 42 bytes long and RLEW compressed", unless I misunderstand what the sentence means, it doesn't apply to Wolfenstein-3D (the RLEW compression I mean).
--[[User:Ilovemyq3map2|Ilovemyq3map2]] ([[User talk:Ilovemyq3map2|talk]]) 16:09, 14 October 2013 (GMT)

== InfoPlane values ==
So, it'd be real nice to have a list of what the values in InfoPlane map to. Not sure where to put them, as they're a per-game thing. Additionally, some item IDs are things that appear in certain difficulty levels only - ID 47 in Keen 4 is a Lick that only appears in Hard (and perhaps Medium) Having a list somewhere might help with this. Any thoughts? [[User:Szevvy|Szevvy]] ([[User talk:Szevvy|talk]])

:For many games using this format, you can just use the first couple of tiles from the TILE16M tileset as icons for the InfoPlane entries. Things that only spawn on certain difficulty settings usually have the number 2 or 3 somewhere in the icon graphic, representing normal and hard difficulty levels respectively. That should work for Keen 4-6 (not all versions, though), Keen Dreams, BioMenace, Dave 3 & 4 and the Catacomb 3D series. Wolf3D-based games usually don't have any TILE16M tiles, so a list or a table would be more helpful for those games.
:I'd say that a detailed table of InfoPlane values should be a separate page for each game, since there are some very game-specific quirks, especially in the Gamer's Edge/JAM games (Dave 3 & 4, the Catacomb trilogy and the Blake Stone series). How the game interprets the various InfoPlane values doesn't really have anything to do with the GAMEMAPS format itself. --[[User:K1n9 Duk3|K1n9 Duk3]] ([[User talk:K1n9 Duk3|talk]]) 20:43, 29 August 2019 (UTC)

== Location of data in exes ==
On thing to note when filling out the location of data in exes - UNP and unpklite decompress exe's slightly differently, so any PKLITE'd values need to have the decompression tool marked in the table.[[User:Szevvy|Szevvy]] ([[User talk:Szevvy|talk]])

Dark Ages Map Format

2019-08-08T22:40:32Z

K1n9 Duk3: added tile mapping table and tile attributes

{{Map Infobox
| Type = 2D tile-based
| Layers = 1
| Tile size = 16×16
| Viewport = 240×144
| Games =
{{Game|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.

{|class="wikitable"
! Tile code !! Suggested icon !! Background !! Description
|-
| 100 || 150 || from right || green gem (increases firepower)
|-
| 101 || 158 || from right || gold coin
|-
| 102 || 168 || from right || green monster
|-
| 103 || 174 || from right || fly/moth
|-
| 104 || 184 || from above || lava
|-
| 105 || 188 || from above || slime
|-
| 106 || 192 || from right || stalagtite
|-
| 107 || 198 || from right || spikes (ceiling)
|-
| 108 || 200 || from above || red dude
|-
| 109 || 230 || from right || boulder
|-
| 110 || 234 || from above || door
|-
| 111 || 236 || from right || spider (ceiling)
|-
| 112 || 239 || from right || spider (ground)
|-
| 113 || 242 || from right || frog (jumps left)
|-
| 114 || 246 || from right || frog (jumps right)
|-
| 115 || 250 || from below || cobwebs (top-left corner)
|-
| 116 || 251 || from below || cobwebs (top-right corner)
|-
| 117 || 252 || from above || cobwebs (bottom-left corner)
|-
| 118 || 253 || from above || cobwebs (bottom-right corner)
|-
| 119 || 254 || from right || wizard (this also replaces the tile below it with the tile to the right of that one, probably a bug)
|-
| 120 || 154 || from left || item: key
|-
| 121 || 155 || from left || item: ankh
|-
| 122 || 156 || from left || item: shield
|-
| 123 || 157 || from left || item: apple
|-
| 124 || 262 || 29 || falling brick
|-
| 125 || 264 || from below || leaky pipe
|-
| 126 || 258 || from above || handrail, left
|-
| 127 || 259 || from above || handrail, middle
|-
| 128 || 260 || from above || handrail, right
|-
| 129 || 273 || from left || large column, bottom
|-
| 130 || 274 || from left || large colump, middle
|-
| 131 || 275 || from left || large column, top
|-
| 132 || 10 || 81 || hidden passage
|-
| 133 || 280 || from right || hand with scroll 1
|-
| 134 || 281 || from left || hand with scroll 2
|-
| 135 || 282 || from left || power up statue 1
|-
| 136 || 283 || from left || power up statue 2
|-
| 137 || 285 || from right || small column (2 tiles high) (also replaces tile above it with the tile to the right of that one)
|-
| 138 || 286 || from right || water fountain (middle)
|-
| 139 || 290 || from right || water fountain (top, moving up & down)
|-
| 140 || 182 || from left || shootable button
|-
| 141 || 296 || from above || bone claw
|-
| 142 || 180 || from right || heart (full heal)
|-
| 143 || 300 || from above || Garth (boss monster)
|}

These tile numbers are to be applied to the combined tileset loaded from the files <tt>FILE06.DA?</tt> to <tt>FILE12.DA?</tt>. Tiles 0 to 49 are loaded from <tt>FILE06.DA?</tt>, tiles 50 to 99 from <tt>FILE07.DA?</tt> and so on. The final tileset file, <tt>FILE12.DA?</tt>, only contains 2 full tiles, leadin to a total of 302 tiles. The game tries tries to load 400 image bytes (the equvalent of 2.5 tiles) from the final tileset file for some reason. That file is only 384 bytes in size.

Tile attributes are hard-coded as well:

* Tiles 0 to 39 are fully blocking for all game objects.
* Tiles 30 to 49 are fully blocking for the enemies, but the player can stand on (or in) them and can also walk and shoot through these tiles.
* Tile 29 hurts the player when the player jumps into it from below.
* Tiles 50 and above don't block anything.
* Tiles 50 to 80 are animated in three frames, consisting of the base tile and the two following tiles.

== Credits ==

This file format was reverse engineered by [[User:Frenkel|Frenkel]]. The tile mapping table and tile attributes were reverse engineered by [[User:K1n9_Duk3|K1n9_Duk3]] 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!)

Duke Nukem/Mods

2019-05-15T22:13:34Z

K1n9 Duk3: fixed links and added notes on suspicious file dates

{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|-
! Title
! Download(s)
! Release date
! Modder(s)
! # of levels
! Protagonist
! Notes
|-
| Duke's Next Adventure (DN_LS1)
| [http://archive.shikadi.net/sites/www.geocities.com/dooknookimklassik/dn1edit20.zip 1.0]
| 1993
| Larry Shanker
| 10
| Duke Nukem
| Level Pack, included with DukeEdit
|-
| DN_LS2
| [http://archive.shikadi.net/sites/www.geocities.com/dooknookimklassik/dn1edit20.zip final]
| 1993
| Larry Shanker
| 10
| Duke Nukem
| Level Pack, included with DukeEdit
|-
| Rambo Levels (DN_WW1)
| [http://archive.shikadi.net/sites/www.geocities.com/dooknookimklassik/dn1edit20.zip final]
| 1994
| William Witkowski
| 10
| Duke Nukem
| Level Pack, included with DukeEdit
|-
| DN_DB1
| [http://archive.shikadi.net/sites/www.geocities.com/dooknookimklassik/dn1edit20.zip final]
| 1994
| David Bollinger
| 10
| Duke Nukem
| Level Pack, included with DukeEdit
|-
| DN_DB2
| [http://archive.shikadi.net/sites/www.geocities.com/dooknookimklassik/dn1edit20.zip final]
| 1994
| David Bollinger
| 7
| Duke Nukem
| Level Pack, included with DukeEdit
|-
| Wartime II
| [http://ettingrinder.youfailit.net/dukenukem1-addons.html final]
| 1995
| Jim S. Hart
| 10
| Duke Nukem
| Level Pack
|-
| Neil McRae's first levels
| [http://www.stuntsillusion.com/games.html final]
| 1999
| Neil McRae
| 30
| Duke Nukem
| Level Pack
|-
| Neil McRae's second levels
| [http://www.stuntsillusion.com/games.html final]
| 1999
| Neil McRae
| 10
| Duke Nukem
| Level Pack
|-
| Shifted's First DN1 Level
| [http://dosclassics.com/duke/dl.php final]
| 2005
| The Shifted One
| 1
| Duke Nukem
| Single level
|-
| The Returning
| [https://drive.google.com/file/d/0B3MDAZU7IeLBZE9YQXgxYWwyUzg/view 2017 Edition]
| 2010
| (_DNV_)
| 10
| Duke Nukem
| Level pack + partial graphics mod
|-
| Pieter Simoons' levels
| [http://crystalshard.net/?p=8&s=51 final]
| 2012?
| Pieter Simoons (Radiant)
| 3
| Duke Nukem
| Level Pack
|-
| Dr. Protons Revenge
| [http://k1n9duk3.shikadi.net/files/mods/DNPRInstall.zip final?]
| 2003/2005
| NicksSoftware
| 10?
| Duke Nukem
| Level pack + partial graphics mod some levels (dated 1995-01-29 to 1995-01-31) stolen from earlier level packs?
|-
| Proton's Master Plan
| [http://k1n9duk3.shikadi.net/files/mods/DNPMPInstall.zip final?]
| 2006
| NicksSoftware
| 10?
| Duke Nukem
| Level pack + partial graphics mod levels (all dated 1998-01-03) stolen from earlier level packs?
|-
|}

[[Category:Mods by game]]

Duke Nukem/Mods

2019-05-15T22:02:35Z

K1n9 Duk3: Added "Dr. Protons Revenge" and "Proton's Master Plan". I had old zips of them (dated 2011-04-01) on my HDD and uploaded them to my website for now.

{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|-
! Title
! Download(s)
! Release date
! Modder(s)
! # of levels
! Protagonist
! Notes
|-
| Duke's Next Adventure (DN_LS1)
| [http://archive.shikadi.net/sites/www.geocities.com/dooknookimklassik/dn1edit20.zip 1.0]
| 1993
| Larry Shanker
| 10
| Duke Nukem
| Level Pack, included with DukeEdit
|-
| DN_LS2
| [http://archive.shikadi.net/sites/www.geocities.com/dooknookimklassik/dn1edit20.zip final]
| 1993
| Larry Shanker
| 10
| Duke Nukem
| Level Pack, included with DukeEdit
|-
| Rambo Levels (DN_WW1)
| [http://archive.shikadi.net/sites/www.geocities.com/dooknookimklassik/dn1edit20.zip final]
| 1994
| William Witkowski
| 10
| Duke Nukem
| Level Pack, included with DukeEdit
|-
| DN_DB1
| [http://archive.shikadi.net/sites/www.geocities.com/dooknookimklassik/dn1edit20.zip final]
| 1994
| David Bollinger
| 10
| Duke Nukem
| Level Pack, included with DukeEdit
|-
| DN_DB2
| [http://archive.shikadi.net/sites/www.geocities.com/dooknookimklassik/dn1edit20.zip final]
| 1994
| David Bollinger
| 7
| Duke Nukem
| Level Pack, included with DukeEdit
|-
| Wartime II
| [http://ettingrinder.youfailit.net/dukenukem1-addons.html final]
| 1995
| Jim S. Hart
| 10
| Duke Nukem
| Level Pack
|-
| Neil McRae's first levels
| [http://www.stuntsillusion.com/games.html final]
| 1999
| Neil McRae
| 30
| Duke Nukem
| Level Pack
|-
| Neil McRae's second levels
| [http://www.stuntsillusion.com/games.html final]
| 1999
| Neil McRae
| 10
| Duke Nukem
| Level Pack
|-
| Shifted's First DN1 Level
| [http://dosclassics.com/duke/dl.php final]
| 2005
| The Shifted One
| 1
| Duke Nukem
| Single level
|-
| The Returning
| [https://drive.google.com/file/d/0B3MDAZU7IeLBZE9YQXgxYWwyUzg/view 2017 Edition]
| 2010
| (_DNV_)
| 10
| Duke Nukem
| Level pack + partial graphics mod
|-
| Pieter Simoons' levels
| [http://crystalshard.net/?p=8&s=51 final]
| 2012?
| Pieter Simoons (Radiant)
| 3
| Duke Nukem
| Level Pack
|-
| Dr. Protons Revenge
| [https://k1n9duk3.shikadi.net/files/mods/DNPRInstall.zip final?]
| 2003/2005
| NicksSoftware
| 10?
| Duke Nukem
| Level pack + partial graphics mod
|-
| Proton's Master Plan
| [https://k1n9duk3.shikadi.net/files/mods/DNPMPInstall.zip final?]
| 2006
| NicksSoftware
| 10?
| Duke Nukem
| Level pack + partial graphics mod
|-
|}

[[Category:Mods by game]]

Major Stryker

2019-04-15T04:55:30Z

K1n9 Duk3: /* File formats */ changed color for the Save Game Format entry

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

'''Major Stryker''' is an EGA top down shooter, similar to the later VGA games [[Kiloblaster]] and [[Raptor]]. Its file formats are very similar (in some cases identical) to [[Cosmo's Cosmic Adventures]] and [[Duke Nukem II]], both of which were produced around the same time by the same developers.

== Tools ==

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

 
== File formats ==

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

{|class="wikitable"
! File name !! Format !! Description
|-
| <tt>VOLUME?.MS?</tt>
| style="background: #CCFFCC;" | [[CMP Format]]
| Group files containing most of the game's data files
|-
| <tt>DOSTEXT2.DR1</tt>
| style="background: #CCFFCC;" | [[B800 Text]]
| Text screen displayed at exit
|-
| <tt>TITLEDR.DR1</tt> <tt>CREDITS.DR1</tt> <tt>CHOOSE.DR1</tt> <tt>ENDLEVEL.DR1</tt> <tt>GOODLUCK.DR1</tt> <tt>MISSION.DR1</tt>
| style="background: #CCFFCC;" | [[Raw EGA data#Planar EGA data|Full-screen planar EGA]]
| 320 x 200 pixel fullscreen images
|-
| <tt>*.DR?</tt> (see format page)
| style="background: #CCFFCC;" | [[Major Stryker Tileset Format]]
| Tileset graphics
|-
| <tt>WORLDAL?.DR?</tt>
| style="background: #CCFFCC;" | [[Major Stryker Level Format]]
| Level files
|-
| <tt>DRSOUND*.SND</tt>
| style="background: #CCFFCC;" | [[Inverse Frequency Sound format]]
| PC Speaker sound effects
|-
| <tt>*.VOC</tt>
| style="background: #CCFFCC;" | [[VOC Format]]
| Digitised sound effects
|-
| <tt>*.IMF</tt>
| style="background: #CCFFCC;" | [[IMF Format]]
| Background music
|-
| <tt>*.MS?</tt> (see format page)
| style="background: #CCFFCC;" | [[Major Stryker Text Format]]
| In-game texts
|-
| <tt>CONFIG.MS</tt>
| style="background: #FFCCCC;" | [[Major Stryker Config Format]]
| Game configuration
|-
| <tt>HS.MS?</tt>
| style="background: #CCFFCC;" | [[HS Format (Major Stryker)|HS Format]]
| High scores
|-
| <tt>SR?.MS</tt>
| style="background: #CCFFCC;" | [[Major Stryker Save Game Format]]
| Save game slots
|}

[[Category:Apogee]]
[[Category:Overhead]]
[[Category:Space Invaders]]

HS Format (Major Stryker)

2019-04-15T04:52:01Z

K1n9 Duk3: clarification on checksum algorithm

{{Playerdata Infobox
| Config = Yes
| Storing = Scores
| Games =
{{Game|Major Stryker}}
}}

The '''Major Stryker high score format''' is used to store the top ten scores in [[Major Stryker]].

== File format ==

=== Header ===

The file begins with a single byte checksum in order to prevent tampering. The checksum is generated by summing most of the bytes in the high score file into a byte value, and throwing away the overflow. The first byte (the checksum itself) and the last two bytes of the file are excluded from this sum. The same algorithm is used to calculate the checksum of the [[Major Stryker Save Game Format]].

{|class="wikitable"
! Data type !! Name !! Description
|-
| BYTE || checksum || Checksum of the file.
|}

=== Data ===

The data consists of a list of ten scores.

{|class="wikitable"
! Data type !! Name !! Description
|-
| CHAR[...] || score || Player's score. Space (0x20) terminating.
|-
| CHAR[...] || name || Player's name. \r\n (0x0D, 0x0A) terminating. Maximum 12 characters.
|}

=== Footer ===

The list contains an eleventh score which is really just an unnecessarily long end of file marker.

{|class="wikitable"
! Data type !! Name !! Description
|-
| CHAR[5] || score || Always "1000". Space (0x20) terminating.
|-
| CHAR[2] || name || Always "..". \r\n (0x0D, 0x0A) terminating.
|}

== Code ==

This FreeBASIC program will generate a new high score file with whatever names and scores you like, and prefix the proper checksum header.

<source lang="freebasic">
' Major Stryker High Score Generator.
' ------------------------------------------
' This program generates a high score file
' with the proper checksum value.

' Declare work variables.
Dim Table As String
Dim File As String
Dim Checksum As Byte

' Change this file path to the location of your Major Stryker high score file.
File = "D:\Documents\Games\Stryker\HS.MS1"

' Generate the high score list.
' Change any of the scores and names to the value you desire,
' but keep your scores less than 7 digits and your names
' less that 12 characters long.
Table = ""
Table = Table + "50000 Hudson " + Chr(13) + Chr(10)
Table = Table + "45000 Hicks D. " + Chr(13) + Chr(10)
Table = Table + "40000 Vasquez J. " + Chr(13) + Chr(10)
Table = Table + "35000 Bishop L. " + Chr(13) + Chr(10)
Table = Table + "30000 Apone A. " + Chr(13) + Chr(10)
Table = Table + "25000 Spunkmeyer " + Chr(13) + Chr(10)
Table = Table + "20000 Dietrich C. " + Chr(13) + Chr(10)
Table = Table + "15000 Wierzbowski " + Chr(13) + Chr(10)
Table = Table + "10000 Berk C. " + Chr(13) + Chr(10)
Table = Table + "5000 Ripley E. " + Chr(13) + Chr(10)
Table = Table + "1000 .." + Chr(13) + Chr(10)

' Generate the checksum.
' The checksum simply adds the ASCII value of each character in the high
' score file to a byte value, while throwing away the overflow.

' The checksum value is salted with 233 to make it harder to reverse
' engineer. But that didn't stop me! ;-)
Checksum = 233

' Sum up each character in the file.
Dim X As UShort
For X = 1 To Len(Table)
Checksum = Checksum + Asc(Mid(Table, X, 1))
Next X

' Attach the checksum to the front of the high score list.
Table = Chr(Checksum) + Table

' Delete the high score file if it already exists.
Kill File

' Open the high score file, store the new list, and save it.
Open File For Binary As #1
Put #1, , Table
Close #1
</source>

== Credits ==

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

Major Stryker Save Game Format

2019-04-15T04:48:59Z

K1n9 Duk3: added missing info

{{Playerdata Infobox
| Config = Yes
| Storing = Saves
| Games =
{{Game|Major Stryker}}
}}

The '''Major Stryker save game format''' is used to store a saved game [[Major Stryker]], up to 10 in total. Each save will be named 'SR*.MS', with the asterisk replaced for letter A-J for save slot 0-9 respectively, though there is also a letter N used to hold the list of names corresponding to each save slot file.

== File format ==

=== Header ===

The file begins with a single byte checksum in order to prevent tampering. The checksum is generated by summing most of the bytes in the save game file into a byte value, and throwing away the overflow. The first byte (the checksum itself) and the last two bytes of the file are excluded from this sum. The same algorithm is used to calculate the checksum of the [[HS Format (Major Stryker)]].

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[BYTE]] || checksum || Checksum of the file.
|}

=== Data ===

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[INT16LE]] || Fire power level || 0x01: Single shot forward 0x02: Double shot forward 0x03: Tripe shot forward 0x04: Triple shot forward cone 0x05: Triple shot forward cone + rear single 0x06: Triple shot forward cone + rear single + side single
|-
| [[INT16LE]] || Lives || Count
|-
| [[BYTE]] || Shield level || 0x00: No shield 0x01: Side shields 0x02: Spinning shields 0x03: Bubble
|-
| [[INT16LE]] || Burst level || Level is minus 1. (0x00-0x07 represents 1-8 respectively.)
|-
| [[INT16LE]] || Zap bombs || Count
|-
| [[BYTE]] || Level || 0x00-0x23 for level 1-36 respectively. (0x00-0x0B for Lava planet, 0x0C-0x17 for Arctic planet, and 0x18-0x23 for Desert planet.)
|-
| [[BYTE]] || Skill || 01: Beginner 02: Novice 03: Expert
|-
| [[INT16LE]] || Enemies total || Number of enemies encountered in all previous levels combined
|-
| [[INT16LE]] || Enemies killed || Number of enemies killed in all previous levels combined
|-
| [[INT16LE]] || Men total || Number of cryogenic tubes encountered in all previous levels combined
|-
| [[INT16LE]] || Men saved || Number of captured humans freed in all previous levels combined
|-
| CHAR[...] || Score || Player's score as an ASCII string, EOF terminated.
|}

== Save slot names file format ==

=== Data ===

Each save slot is represented in the save slot names file by up to 24 bytes sequentially. There is no header or footer. Data is per-slot, with each following slot concatenated to its previous slot.

{|class="wikitable"
! Data type !! Name !! Description
|-
| CHAR || Slot number || Number is in ASCII (0x30-0x39 representing slots 0-9 respectively), space (0x20) terminating.
|-
| CHAR[0-22] || Slot name || Save slot name up to 20 characters, CRLF (0x0D,0x0A) terminating.
|}

== Credits ==

This save game format was reverse engineered by [[User:Adambean|Adambean]] and [[User:K1n9_Duk3|K1n9_Duk3]]. 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!)

Crunched Screen Image

2019-03-05T22:58:18Z

K1n9 Duk3: somebody please rename this page to "Crunched Screen Image"

A special format is used internally by [[Super ZZT]] to draw the title screen and ending screen graphics. The format assumes a 80x25 display window.

The same format is also used to store compressed text screens in various other titles by Epic Megagames, including [[Jill of the Jungle]], [[Kiloblaster]] and [[Xargon]] where the hardware configuration screens (and sometimes ending screens) are stored in this format. Some menu programs also use this format to store text-based menu, ordering info and ending screens.

The [[Xargon]] source code refers to this data format as "TheDraw C Crunched Screen Image" in <tt>CFG_WIN.H</tt>. [[Kiloblaster]]'s source code uses the same name in <tt>BEGIN.H</tt>.

== Format ==

There is no header information for this format. It is read as a stream of bytes until the Y-position goes off the bottom (row 25). The <tt>uncrunch</tt> algorithm found in the [[Xargon]] and [[Kiloblaster]] source code takes the length of the compressed block as a parameter and stops decompressing once all bytes have been processed.

The <tt>uncrunch</tt> decompression starts with the text attributes set to 0 (black text on black background, not blinking). The text usually appears at the top left corner of the text screen.

{|class="wikitable"
!Value!!Description
|-
|00-0F||Set the foreground color of following output to this value.
|-
|10-17||Set the background color of following output to the lower 4 bits of this value.
|-
|18||Go to the beginning of the following text line.
|-
|19||Read one more byte ''n'', and output a space character ''n''+1 times.
|-
|1A||Read two more bytes ''n'' and ''char'', and output ''char'' for ''n''+1 times.
|-
|1B||Toggle blinking text on/off
|-
|1C-1F||Undefined (<tt>uncrunch</tt> just skips these)
|-
|20-FF||Output this character exactly.
|}

== Location ==

These graphics cannot be found or used outside the game executable. They are referenced directly by the code and compiled into the game engine itself.

Jill of the Jungle Map Format

2018-11-17T06:49:37Z

K1n9 Duk3: /* Savegame data */ added correct max. health for Jill

{{Map Infobox
| Type = 2D tile-based
| Layers = 2
| Tile size = 16×16
| Viewport = 232×160
| Games =
{{Game|Jill of the Jungle}}
}}

The '''Jill of the Jungle map format''' is the format used to describe the levels played during the game. The maps contain two layers - a background layer and an "object" layer. The background layer is a grid of 16x16 pixel tiles, 128 tiles wide and 64 tiles high. The object layer is made up of an arbitrary list of objects, with X and Y offsets in pixels.

== File format ==

The main map file starts off with the background layer, then immediately following it is the foreground layer, the savegame data block and the string stack.

=== Background layer ===

The background layer is quite simple. It is an array of 8,192 16-bit values (128 tiles wide by 64 tiles high == 8192 tiles total.) Each 16-bit value is a code, such as 0xC0D3. The formula ((x * MAP_HEIGHT) + y) * 2 (where MAP_HEIGHT is 64) will provide the offset (in bytes) into the map file where that grid's 16-bit code is located.

Once the code is found, its lower 14 bits are isolated (e.g. code & 0x3FFF) which provides an ID that is listed in the tile mapping table (see below.) The tile mapping table then provides an index into the graphics file for the image that should be displayed at that grid location. The upper two bits are only used during gameplay to record information about which tiles are on screen at any given time.<ref>[https://github.com/Malvineous/xargon/blob/master/src/include/xargon.h#L23 xargon.h lines 23-30]</ref> The official games all seem to have these upper two bits set in the map file, so it's probably a good idea to do the same when writing out modified maps.

For example, if the 16-bit code is 0xC0D3, then isolating the lower three nybbles will provide the number 0x00D3. At the entry for ID 0x00D3 in the tile mapping table, the value might be iTileset as 0x12 and iTile as 0x34. This means that in the graphics file, tileset number 0x12 should be accessed, and tile number 0x34 within that tileset should be drawn at the grid coordinate.

It is also important to note that these values are stored little-endian, like the [[SHA Format|SHA format]]. This means that for example the value 0xC0D3 is stored as the two bytes D3-C0, not as C0-D3.

==== Tile mapping table ====

There is a separate file in the game directory that contains mappings between tile codes in the background layer and the game's graphics. In [[Jill of the Jungle]] this is called <tt>JILL.DMA</tt> and in [[Xargon]] it is <tt>TILES.XRx</tt>.

This file is arranged as an array of entries, one after the other. Each entry is in the following format:

{|class="wikitable"
!Data type!!Description
|-
| [[UINT16LE]] iMapCode || ID used in map file
|-
| [[UINT8]] iTile || Index into the tileset for the image to use
|-
| [[UINT8]] iTileset || Index of tileset containing this tile's image (ignore upper two bits - see below)
|-
| [[UINT16LE]] iFlags || Flags for this tile (can stand on, can hurt player, etc.)
|-
| [[UINT8]] iLength || Length of tile name
|-
| [[char]] cName[iLength] || <tt>iLength</tt> characters for the tile name. This string is not NULL-terminated.
|}

Note that only the lower six bits of <tt>iTileset</tt> refer to the tile number. The purpose of the upper unknown bits is unknown. To get a valid tileset index use <code>iTileset & 0x3F</code>.

<tt>iFlags</tt> is broken up as follows:

{|class="wikitable"
!Bit!!Hex!!Name!!Description
|-
||-||0x0000||<zero>||Default solid block
|-
|1||0x0001||F_PLAYERTHRU||Blocks you can walk, jump or fall through (background tiles, the path on the overhead map, etc.)
|-
|2||0x0002||F_STAIR, F_NOTSTAIR (Xargon)||Blocks that you can stand on (can also jump up through when combined with F_PLAYERTHRU)
|-
|3||0x0004||F_VINE, F_NOTVINE (Xargon)||Can climb this block - usually combined with F_PLAYERTHRU (giving 0x0005)
|-
|4||0x0008||F_MSGTOUCH||Activates game-specific code when touched
|-
|5||0x0010||F_MSGDRAW|| Regular blocks have just one shape, f_msgdraw triggers <tt>msg_block(msg_draw)</tt> for animated blocks.
|-
|6||0x0020||F_MSGUPDATE|| game-specific code (through <tt>msg_block(msg_update)</tt>) at every frame. For animated blocks.
|-
|7||0x0040||F_INSIDE||This block contains text inside it
|-
|8||0x0080||F_FRONT|| object property : Foreground object
|-
|9||0x0100||F_TRIGGER||Unknown
|-
|10||0x0200||F_BACK || object property: Background object (e.g. torches)
|-
|10||0x0200||F_TINYTHRU|| (likely PlayerThru when player is in 'mini' mode, unused in Xargon)
|-
|11||0x0400||F_ALWAYS|| object property : "Always updates object"
|-
|12||0x0800||F_KILLABLE|| object property : monster can be killed with regular weapon.
|-
|13||0x1000||F_FIREBALL|| object property : object is a fireball
|-
|14||0x2000||F_WATER|| A water tile. regular player will sink, the S.U.B. and aquatic monster can swim through it, but not out of it
|-
|14||0x4000||F_NOT_WATER|| (Xargon) Not a water tile.
|-
|15||0x4000||F_WEAPON|| object property : object is a regular weapon
|-
|16||0x8000||(unused)||(unused)
|}

Note that the same "flag set" is used for both blocks and objects. Some properties only apply to blocks, some only apply to objects, some to both (<tt>f_msgtouch</tt>), and some flags have a different meaning for blocks and tile (e.g. 0x200 and 0x2000).

=== Object layer ===

The object layer is drawn in front of the background layer, and contains all the interactive elements of the map, such as points and enemies.

The object data starts straight after the background layer data, so that's at offset 16,384 bytes into the map file (8,192 tiles * two bytes per tile.) The first two bytes in the object layer are a 16-bit integer ([[UINT16LE]]) that stores the number of objects in the map, and this is followed by the data for each object, one after the other.

Each object is 31 bytes long, and is stored in the following structure:

{|class="wikitable"
!Data type!!Description
|-
|UINT8 iType||Object type (e.g. a "point item", or an enemy.)
|-
|UINT16 iX||X-coordinate of object
|-
|UINT16 iY||Y-coordinate of object
|-
|UINT16 iXD|| object horizontal speed
|-
|UINT16 iYD|| object vertical speed
|-
|UINT16 iWidth||Width of object
|-
|UINT16 iHeight||Height of object
|-
|UINT16 iState||Object sub-type (e.g. what type of "point item"), or current "State" (running, jumping, etc)
|-
|UINT16 iSubState||object-specific semantic
|-
|UINT16 iStateCount||object-specific semantic, typically a frame counter
|-
|UINT16 iCounter||Various uses. Often used to link doors or switches to obstacles.
|-
|UINT16 iFlags|| internally used for rendering.
|-
|UINT32 lPointer||Used internally as a pointer. If this value is 0, there is no entry for this object in the string stack (see below.) Any non-zero value means there is an entry for this object in the string stack.
|-
|UINT16 iInfo1||Unknown
|-
|UINT16 iZapHold||Unknown
|-
|}

At the present time it is assumed (perhaps hoped) that objects can be mapped to images in the same way as the tiles in the background layer can be mapped to images, but as yet there is no known way of doing this.

=== Savegame data ===

Saved games are "snapshots" of the current level state, which is why some spare room exists in the map format to allow special data to be saved.

<table>
<tr>
<td style="vertical-align: top; width: 50%;">

'''Jill'''

In Jill of the Jungle, this section is 70 bytes long.

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[INT16LE]] || level || Level number, displayed in the status screen
|-
| [[INT16LE]] || health || Player health, 0..8, 0=dead, 8=full
|-
| [[INT16LE]] || inventoryLength || Number of items in the inventory
|-
| [[INT16LE]][16] || inventory || Space for up to 16 inventory items, only the first <tt>inventoryLength</tt> entries are valid. (Note that used items such as keys are not removed from this stack, but items are rearranged to override the key value, according to the amount of items displayed in the inventory)
|-
| [[UINT32LE]] || score || Player score
|-
| [[BYTE]][28] || pad || Padding, set to zero
|}

{|class="wikitable"
!InvItemNumber!!Description
|-
|0|| Morph: Jill
|-
|1|| Key: Red Key
|-
|2|| Weapon: Knive
|-
|3|| Key: Crystal Rock
|-
|4|| Morph: Frog
|-
|5|| Morph: Fire bird
|-
|6|| Bag of coins (?)
|-
|7|| Morph: Fish
|-
|8|| Weapon: Blade
|-
|9|| Bonus: High Jump
|-
|}

</td><td style="vertical-align: top;">

'''Xargon'''<ref>[https://github.com/Malvineous/xargon/blob/master/src/include/xargon.h#L69 xargon.h line 69]</ref>

In Xargon, this section is 97 bytes long.

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[INT16LE]] || level || Level number, displayed in the status screen
|-
| [[INT16LE]] || health || Player health, 0..5, 0=dead, 5=full
|-
| [[INT16LE]] || emeralds || Number of emeralds
|-
| [[INT16LE]] || inventoryLength || Number of items in the inventory
|-
| [[INT16LE]][30] || inventory || Space for up to 30 inventory items, only the first <tt>inventoryLength</tt> entries are valid
|-
| [[INT16LE]] || ouched || Player highlight state, set to zero, used during gameplay only. Makes player flash red/blue/etc. depending on current state.
|-
| [[BYTE]][22] || pad || Padding, set to zero
|-
| [[UINT32LE]] || score || Player score
|-
| [[INT8]] || fruit || Number of fruit items (collecting 16 fruits gets one health bar)
|}

{|class="wikitable"
! Inventory item !! Name !! Description (from source code)<ref>[https://github.com/Malvineous/xargon/blob/master/src/include/xargon.h#L80 xargon.h line 80]</ref>
|-
| 0 || inv_hero || Hero, as in a life? NADA
|-
| 1 || inv_mapkey || Opens doors on MAP
|-
| 2 || inv_epic || For EPIC bonus
|-
| 3 || inv_fire || Fireballs
|-
| 4 || inv_laser || Extra laser bullets
|-
| 5 || inv_bird || Hero turns into bumblebee
|-
| 6 || inv_fish || Underwater bubble
|-
| 7 || inv_rock || Rock to throw
|-
| 8 || inv_jump || High jump
|-
| 9 || inv_invin || Invincibility
|-
| 10 || inv_icon1 ||
|-
| 11 || inv_icon2 ||
|-
| 12 || inv_icon3 ||
|-
| 13 || inv_key0 || Keys open doors
|-
| 14 || inv_key1 ||
|-
| 15 || inv_key2 ||
|-
| 16 || inv_key3 ||
|}

</td>
</tr>
</table>

=== String stack ===

The Strings Stack is just a bunch of arbitrary strings (can be either text or file references). Each entry starts with an unsigned short integer defining the length of the incoming string. Note that the string is always followed by a null byte (so if "length of next entry" is 12, you only have the string size and should not forget to read an extra byte to reach the next entry). The string stack's entries are used for iType[20] ("write text"), 21 ("write text in big") and 12 ("checkpoints") and can contain music filenames, demo filenames, next level filenames or arbitrary text content.

In Xargon and Jill, the checkpoint type contains a string:

* If the first character of this string is '*' then the rest of the string is taken to be the filename of the music file to play in that level.
* If the first character is '#' then the string is also a music file, but it is only played if there is no song currently playing, or the level number is between 1 and 32 inclusive. This is probably used for the main menu/credits/etc. so as not to interrupt the theme song when displaying those "levels", and it is used for the map level so the theme music keeps playing (rather than starting from the beginning again) when starting a game.
* The first character of the string can also be '&' which, in Xargon, forces the song to be <tt>song_33.xr1</tt> and in Jill does not change the song. The rest of the string as a macro filename, to be read and played back as a demo. This is used in the ending sequences.

== Object iTypes ==

Here's a list of objects used in Jill maps. A brief Xargon list is available [https://github.com/Malvineous/xargon/blob/master/src/include/x_obj.h in the source code].

iXD and iYD defines both speed and direction of items and ennemies. Positive values goes to right and down while values under zero move the object left and up.
lPointer referes to a segment of memory and is likely used to store entries from the string stack, that's why the gap between two consecutive pointers equals 65536 (this is the maximum size in byte of a string in the stack)
Playable objects must be the first entry in the list to avoid a weird "scroll to first entity" bug in Jill

=== Functional ===

*iType[0] ''(PLAYER)'' Playable: Jill (level)
:ObjectInfo1 (sometimes '-1'): usage unknown
*iType[23] ''(TINY)'' Playable: Jill (map overview in Jill3)
*iType[54] ''(JILLFISH)'' Playable: Fish (never used in maps - if player dies, restart as Jill)
*iType[56] ''(JILLBIRD)'' Playable: Firebird (never used in maps - if player dies, restart as Jill)
*iType[57] ''(JILLFROG)'' Playable: Frog (never used in maps - if player dies, restart as Jill)
*iType[12] ''(CHECKPT)'' Trigger: Checkpoint
:iXD ('> 0'): X position of start in new map
:iYD ('> 0'): Y position of start in new map
:iState: If set to 1, the level is reset to it's initial state if player dies. If set to 0, the level's state is unchanged if player dies.
:iCounter ('>= 0'): checkpoint/level number
:iPointer: pointer
:'''NOTE:''' Always lock access to previous checkpoint when the player reaches a new checkpoint. This item reads an entry from the string stack: a single-character code and a filename. If the code is "*", it means "load and play this song from the beginning". If the code is "#", it means "keep on playing this song". If the code is "!", then there's no filename and it means "load previous map". If there's no code, then the filename is the next level to load.
*iType[15] ''(PAD)'' Trigger: Touch Trigger
:iCounter ('>= 0'): target tag
*iType[32] ''(SWITCH)'' Trigger: Switch
:iState (usually '0'): switch position, if target is off, set to '1'
:iXD (usually '0'): set to '0' when triggering two objects with different start states (one bridge 'off' and a wall 'on' for example)
*iType[52] ''(BUTTON)'' Trigger: Press Button
:iXD (set to '1' to face right, '-1' to face left): direction
:iState (set to '1' if target is off)
:iSubState: usage unknown, rarely used
:iCounter ('>= 0'): target tag
*iType[24] ''(DOOR)'' Misc: Locked Door
:iYD (usually '0', set to '1' for crystal): required key type
:iCounter ('>= 0'): self tag
*iType[25] ''(FALLDOOR)'' Misc: Collapsing ceiling
:iCounter ('>= 0'): self tag
*iType[26] ''(BRIDGER)'' Misc: Toggle Wall
:iXD (set to 1 for horizontal/floor)
:iYD (set to 1 for vertical/wall)
:iCounter ('>= 0'): self tag
:'''NOTE:''' If set as wall, must be placed on top of the wall, if set as floor, must be placed on the far left of the floor. By default, these walls are "off", use "ELEVMID" tiles for wall and "BRIDGE" for floor. Walls and bridges cannot go through two different types of tiles.
*iType[44] ''(KNIGHT)'' Misc: Knight
:iState (set to '1' for start on, '0' for start off): initial state
:iStateCount (set to '6' for 'none shall pass')
:iCounter ('>= 0'): self tag (toggle when triggered)
*iType[61] ''(ELEV)'' Misc: Lift
:iCounter (usually '0'): if set to '-1', do not return to initial state
:'''NOTE:''' When going up, the elevator will travel until the player hits a solid tile. When going down, the elevator will erase "ELEVMID" tiles, replacing them with the tile directly above. "ELEVBOT" tiles look the same as "ELEVMID" tiles, but an elevator will not travel through it.

=== Items & Bonus ===

*iType[1] ''(APPLE)'' Bonus: Apple
*iType[28] ''(TOKEN)'' Bonus: Pickup Item & morphing icons
:iCounter ('>= 0'): item type (can be anything from 0 to 9 and matches the inventory item number)
*iType[2] ''(KNIFE)'' Weapon: Knife
*iType[14] ''(KEY)'' Key: Old Red Key
*iType[33] ''(GEM)'' Key: Crystal
:iCounter (rarely set to '1'): usage unknown

=== Monsters ===

*iType[4] ''(BIGANT)'' Green bug
:iXD (usually '2'): movement speed
*iType[7] ''(DEMON)'' Devil
*iType[8] ''(BUNNY)'' Bunny
*iType[9] ''(INCHWORM)'' Worm
:iXD (usually '2'): movement speed
*iType[11] ''(BOBSLUG)'' Giant Slug
:iXD (usually '2'): movement speed
*iType[17] ''(FATSO)'' Lizard Man
:iXD (usually '2'): movement speed
*iType[22] ''(FROG)'' Frog
*iType[29] ''(ANT)'' Giant Ant
:iXD (usually '3'): movement speed
*iType[30] ''(PHOENIX)'' Phoenix
:iXD (usually '3'): movement speed
*iType[39] ''(SNAKE)'' Invincible Snake
:iXD (usually '2'): movement speed
*iType[43] ''(BAT)'' Giant Bat
*iType[45] ''(BEENEST)'' Hive
*iType[46] ''(BEESWARM)'' Bees
*iType[47] ''(CRAB)'' Crab
*iType[48] ''(CROC)'' Gator
:iXD (usually '2'): movement speed
*iType[53] ''(PAC)'' Ghost
:iXD (usually '2'): initial direction
:iCounter (usually '2'): movement speed
:'''NOTE:''' Ghosts move along the same tile type
*iType[59] ''(JELLYFISH)'' Jellyfish
*iType[60] ''(BADFISH)'' Eels

=== Traps ===

*iType[35] ''(BOULDER)'' Rolling Stone
*iType[38] ''(STALAG)'' Falling Spike
:iCounter ('>= 0'): self tag (fall when triggered)
*iType[41] ''(BOLL)'' Boucing Ball
:iCounter (usually '4'): ball type (0-small, 3-red, 4-green)
*iType[65] ''(VINECLIMB)'' Sparks
:iYD (usually '2'): movement speed
:'''NOTE:''' Sparks move along the same tile type

=== Misc ===

*iType[13] ''(PAUL)'' Misc: Prince
:iState (<code><nowiki>''</nowiki></code>): object animation frame
*iType[19] ''(CLOUD)'' Misc: Cloud
:iCounter ('>= 0'): usage unknown
:iXD (<code><nowiki>''</nowiki></code>): movement speed
*iType[20] ''(TEXT6)'' Misc: Write text (small capital letters)
:iXD (<code><nowiki>''</nowiki></code>): CGA color index number
:iYD (usually '-1' for transparent): background color
:lPointer: pointer
:'''NOTE:''' This item reads an entry from the string stack
*iType[21] ''(TEXT8)'' Misc: Write text (big letters)
:iXD (<code><nowiki>''</nowiki></code>): CGA color index number
:iYD (usually '-1' for transparent): background color
:lPointer: pointer
:'''NOTE:''' This item reads an entry from the string stack
*iType[40] ''(SEAROCK)'' Misc: Underwater Rock
*iType[42] ''(MEGA)'' Misc: Huge letter
:iXD ('>= 0'): letter type (0-M, 1-E, 2-G, 3-A, 4-S)
:iCounter ('>= 0'): self tag (fall when triggered)
*iType[49] ''(EPIC)'' Misc: Epic Logo
*iType[51] ''(SKULL)'' Misc: Big Skull
:iCounter ('>= 0'): self tag (laugh with red gloomy eyes when triggered)
*iType[64] ''(EYE)'' Misc: Eye
*iType[66] ''(FLAG)'' Misc: Flag
*iType[67] ''(MAPDEMO)'' Misc: "Demo"/"Map" sign
:iXD (sign type, '>= 0'): set to '1' for "map", '0' for "demo"

=== Untested ===

*iType[3] ? (buggy/unusable)
*iType[5] ? (buggy/unusable)
*iType[10] ? (buggy/unusable)
*iType[16] ? (buggy/unusable)
*iType[27] ? (buggy/unusable)
*iType[34] ? (buggy/unusable)
*iType[50] ? (buggy/unusable)
*iType[55] ? (buggy/unusable)
*iType[6] Buggy: harmless firebird
*iType[18] Saves: Demon attack
:iSpeedX (<code><nowiki>''</nowiki></code>): Horizontal speed
:iSpeedY (<code><nowiki>''</nowiki></code>): Vertical speed
*iType[31] Saves: flame attack
*iType[36] Saves: Particle
:iState (<code><nowiki>''</nowiki></code>): color
:iSpeedX (<code><nowiki>''</nowiki></code>): velocity X
:iSpeedY (<code><nowiki>''</nowiki></code>): velocity Y
:iFlag (<code><nowiki>'16384'</nowiki></code>): Unknow
:iCounter (<code><nowiki>''</nowiki></code>): Unknow
*iType[37] Saves: Pain effect
*iType[58] Saves: Bubbles
:iFlag (<code><nowiki>'16384'</nowiki></code>): Unknow
*iType[62] Saves: Player attack (fireball)
*iType[63] Saves: Player attack (fish)

== References ==

<references/>

== Credits ==

This file format was reverse engineered by [[User:Malvineous|Malvineous]], [[User:Ilovemyq3map2|Ilovemyq3map2]] and [[User:SaxxonPike|SaxxonPike]]. 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:Bio Menace/Cheats

2018-08-01T23:01:21Z

K1n9 Duk3: added signature

When you use Super Plasma Bolt "cheat", you also lose a lifebar with that. Is it bug? --[[User:Szemigi|Szemigi]] ([[User talk:Szemigi|talk]]) 21:42, 1 August 2018 (UTC)

: It's not a bug. That's exactly how the Super Plasma Bolt is supposed to work. Just read the BM-HINT.TXT file that comes with the freeware release. All the <tt>SECRET BATTLE MOVES</tt> are described in there. --[[User:K1n9 Duk3|K1n9 Duk3]] ([[User talk:K1n9 Duk3|talk]]) 23:01, 1 August 2018 (UTC)

Talk:Bio Menace/Cheats

2018-08-01T22:57:05Z

K1n9 Duk3: RTFM

SAV Format (Hocus Pocus)

2017-11-25T00:13:18Z

K1n9 Duk3: Added complete C struct with all the data fields and fixed the info in the savegame part.

{{NeedMoreInfo}}
{{Playerdata Infobox
| Config = Yes
| Savegame = Yes
| Storing = Sound, Scores
| Where = Start
| Elements = Level, Difficulty, Score
| Games =
{{Game|Hocus Pocus}}
}}

Information from the shareware episode:

== File format ==

The file HOCUS.SAV stores the following data structure:

<source lang="c">
typedef struct {
Uint16 soundOn, musicOn;
Uint16 controlMode;
Uint16 gamespeed;
Uint16 joyLoX, joyMiX, joyHiX;
Uint16 joyLoY, joyMiY, joyHiY;
Uint16 joyFireButton;
Uint8 controlKeys[8];
//saved games:
Sint16 sg_episodes[9];
Sint16 sg_levels[9];
Sint16 sg_skill[9];
char sg_names[9][26]; //9 entries, 26 chars each (25 chars + terminating 0)
Uint8 unused[10]; //only used by setup (first 9 bytes set to 1)
Sint32 sg_scores[9];
//high scores:
char hs_names[4][5][26]; //4*5 entries, 26 chars each (25 chars + terminating 0)
Sint32 hs_scores[4][5];
//sound setup:
Sint16 soundCard;
Uint16 numVoices;
Uint16 mixBits;
Sint16 musicCard;
Uint16 midiPort;
//settings for setup tool:
Uint16 soundCardIndex;
Uint16 numVoicesIndex;
Uint16 mixingQualityIndex;
Uint16 musicCardIndex;
Uint16 midiPortIndex;
//more sound settings:
Uint16 soundVolume;
Uint16 musicVolume;
Uint16 usesGravis;
} TGameConfig;
</source>

=== Save Game part ===

{|class="wikitable"
!Offset!!Data type!!Description
|-
|0x1E||SINT16LE episode[9]||episode, also indicating whether the each savegame can be loaded. -1 = empty. 0 = first episode. 1 = second episode etc.
|-
|0x30||INT16LE level[9]||saved level of each savegame. 0 = first level. 1 = second level etc.
|-
|0x42||INT16LE difficulty[9]||difficulty of each savegame 0 = easy, 1 = moderate, 2 = hard, 3 = godmode
|-
|0x54||ASCIZ [9][26]||name of each savegame with trailing zero. (maximum 25 characters + trailing zero)
|-
|0x13E||BYTE unused[10]||some rubbish 9 times 1 and 1 time zero. Never used by the game. Note: The 0 might just be padding, so that the scores start at an even address.
|-
|0x148||INT32LE score[9]||score of each savegame.
|}

==== Example ====

Small sample program(C++) to show information about the savegames: (start like this: '''app HOCUS.SAV''')
''int assumed to be 32 bit, short to be 16 bit. Only for little endian machines.''

<source lang="cpp">
#include <iostream>
#include <fstream>
using namespace std;

int main(int argc, char* argv[]) {
if(argc != 2) return 1;

ifstream input(argv[1]);
input.seekg(0x1E,ios::beg);
short signed int episode[9];
input.read(reinterpret_cast<char*>(&episode),2*9);
short level[9];
input.read(reinterpret_cast<char*>(&level),2*9);
short difficulty[9];
input.read(reinterpret_cast<char*>(&difficulty),2*9);
char name[9][26];
input.read(&name[0][0],9*26);

input.seekg(0x148,ios::beg);
int score[9];
input.read(reinterpret_cast<char*>(&score),4*9);

for(int i = 0;i < 9;i++) {
cout << "save " << i+1 << " episode " << episode[i]
<< " level " << level[i] << " difficulty " << difficulty[i]
<< " name: "<< name[i] << " score " << score[i] << endl;
}
return 0;
}
</source>

=== Highscore part ===

{|class="wikitable"
!Offset!!Data type!!Description
|-
|0x16C||ASCIZ Name1[5][26]||Names of the people with highscores for episode 1
|-
|0x1EE||ASCIZ Name2[5][26]||Names of the people with highscores for episode 2
|-
|0x270||ASCIZ Name3[5][26]||Names of the people with highscores for episode 3
|-
|0x2F2||ASCIZ Name4[5][26]||Names of the people with highscores for episode 4
|-
|0x374||INT32LE Score[4][5]||Highscores themselves. Listed by episode.
|}

=== Sound Configuration ===

Stored at the bottom of the file. (less interesting as setup.exe can change those)

== Credits ==

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

Cosmo Level Format

2017-11-23T22:37:12Z

K1n9 Duk3: added ALL supported actor types

{{Map Infobox
| Type = 2D tile-based
| Layers = 3
| Tile size = 8×8
| Viewport = 304×144
| Games =
{{Game|Cosmo's Cosmic Adventures}}
}}

== File format ==
The file is in this basic layout:

{|class="wikitable"
!Data type!!Description
|-
|UINT16LE iFlags||Flags indicating music, backdrop and other stuff
|-
|UINT16LE iMapWidth||Map width in tiles
|-
|UINT16LE iActorSize||Number of UINT16 values in the actor block
|-
|ACTORDATA actorData[]||Variable-length array of all the actors in the level
|-
|BYTE bgLayer[65528]||The map data for the background layer
|}

The iMapWidth values in the original Cosmo levels is either 64, 128, 256 or 512. The "view window" in the game is 304x144 Pixels, so the minimal map width would be 38. However, the game will ''only'' recognize the values 32, 64, 128, 256, 512, 1024 and 2048. Any other value will not be handled by the game at all, thus leaving a vital variable uninitialized. However, the values 32 and 2048 should never be used in a level, since the width or height of the level would be smaller than the viewport.

The iActorSize values are reliable for all the original Cosmo level files (Version 1.20). Since the game loads the entire actorData array into a block of 65535 bytes, the iActorSize value must be less than 32766. Larger values would lead to memory corruption.

The map data found in the original level files is actually sized 65528 Bytes or 32764 Words, but the game will read it a block of up to 65535 bytes. Each Word entry in this block is divisable by 8 (see [[#Mapping cell values to tiles]]).

=== Level Flags ===

The structure of the bits in the iFlags value is as follows:

[ mmmmm | ppp | yxr | bbbbb ]

m: music index
p: palette animation type
y: y-scrolling backdrop
x: x-scrolling backdrop
r: rain
b: backdrop index

Assuming the iFlags value was read as a UINT16LE, the value can be split like this:

rain = (iFlags & 0x20) != 0;
backdrop = iFlags & 0x1F;
scrollX = (iFlags & 0x40) != 0;
scrollY = (iFlags & 0x80) != 0;
animation = (iFlags >> 8) & 7;
music = (iflags >> 11) & 0x1F;

The indices for music and backdrop refer to an array of filename strings stored in the executable. You can find them by searching for the first filename in each array. For backdrops, the first filename (index: 0) is <tt>BDBLANK.MNI</tt>, for music it's <tt>MCAVES.MNI</tt>. Note that some backdrop files are not used by the games. The complete list is:

{|class="wikitable" style="float: left;"
! Backdrop value !! Filename
|-
| 0 || bdblank.mni
|-
| 1 || bdpipe.mni
|-
| 2 || bdredsky.mni
|-
| 3 || bdrocktk.mni
|-
| 4 || bdjungle.mni
|-
| 5 || bdstar.mni
|-
| 6 || bdwierd.mni
|-
| 7 || bdcave.mni
|-
| 8 || bdice.mni
|-
| 9 || bdshrum.mni
|-
| 10 || bdtechms.mni
|-
| 11 || bdnewsky.mni
|-
| 12 || bdstar2.mni
|-
| 13 || bdstar3.mni
|-
| 14 || bdforest.mni
|-
| 15 || bdmountn.mni
|-
| 16 || bdguts.mni
|-
| 17 || bdbrktec.mni
|-
| 18 || bdclouds.mni
|-
| 19 || bdfutcty.mni
|-
| 20 || bdice2.mni
|-
| 21 || bdcliff.mni
|-
| 22 || bdspooky.mni
|-
| 23 || bdcrystl.mni
|-
| 24 || bdcircut.mni
|-
| 25 || bdcircpc.mni
|-
| 26-31 || ''Unused''
|}

{|class="wikitable" style="float: left;"
! Music value !! Filename
|-
| 0 || mcaves.mni
|-
| 1 || mscarry.mni
|-
| 2 || mboss.mni
|-
| 3 || mrunaway.mni
|-
| 4 || mcircus.mni
|-
| 5 || mtekwrd.mni
|-
| 6 || measylev.mni
|-
| 7 || mrockit.mni
|-
| 8 || mhappy.mni
|-
| 9 || mdevo.mni
|-
| 10 || mdadoda.mni
|-
| 11 || mbells.mni
|-
| 12 || mdrums.mni
|-
| 13 || mbanjo.mni
|-
| 14 || measy2.mni
|-
| 15 || mteck2.mni
|-
| 16 || mteck3.mni
|-
| 17 || mteck4.mni
|-
| 18 || mzztop.mni
|-
| 19-31 || ''Unused''
|}

{|class="wikitable" style="float: left;"
! Animation value !! Use !! Description
|-
| 0 || most levels || no palette changes
|-
| 1 || A4 || random lightning (with thunder soundeffect)
|-
| 2 || C8-C10 || cycling: red -> yellow -> white
|-
| 3 || A7 || cycling: red -> green -> blue
|-
| 4 || A8, B3, B4, B7 || cycling: black -> grey -> white
|-
| 5 || C6, C7 || flashing: red -> magenta -> white
|-
| 6 || C1 || replace dark magenta with black, no animation unless triggered by a bomb actor. (ONLY PRESENT IN COSMO3.EXE.)
|-
| 7 || None || no palette changes
|}

 

=== Background Layer ===

The <tt>bgLayer</tt> block contains the grid/cell data:

{|class="wikitable"
!Data type!!Description
|-
|UINT16LE iMapData[32764]||Actual map data
|}

Each "element" in <tt>iMapData</tt> refers to the foreground and/or background tile used in a single grid cell. The grids are arranged left to right, top to bottom, so the index can be calculated by this formula:

int iIndex = (y * iMapWidth) + x;
iMapData[iIndex] = <new value to set at x,y>

The map data in the original Cosmo level files is a constant 32764 UINT16LE cells long (65528 bytes), and the engine will never read more than 65535 bytes. However, the game calculates the map height using this formula:

int iMapHeight = 32768 / iMapWidth - 1;

Since the width of the map is always a power of 2 (min. 64), you can see that each of the original level files is "missing" 8 Bytes (or 4 Words). That means the last line of the map will always be missing the last 4 tiles. The game ignores that last, incomplete line (hence the -1 in the formula). However, in one level (A8.MNI), there is an actor placed in that last line. Since actors are saved as individual structures instead of a grid, that actor will still be loaded by the game. For editing a level, you should make sure the last line is visible, so that it's possible to place actors in that line or remove them from there. Using a buffer of at least 65536 bytes for the level tiles is highly recommended for this.

==== Mapping cell values to tiles ====

The method of mapping elements in the <tt>iMapData</tt> structure into tiles is fairly straightforward. Each cell value is a pixel index into the tilemap. Imagine the tileset laid out left to right all on the one row. Since each tile is 8x8 pixels, at 16 pixels into the image, the third tile will begin (x = 0 for first tile, x = 8 for second tile, x = 16 for third tile.) Assuming the solid/unmasked tileset graphics are layed out as an 8 pixel wide column, the cell value is essentially a pixel y-coordinate into the solid/unmasked tileset.

Note that in the tileset file, the solid tiles are made up of 2000 4-plane (16-colour) images, and these are followed by 1000 5-plane images (16-colour + transparency.) The game interprets any value smaller than 16000 as an index into the solid/unmasked tileset. Any other value will be treated as an index into the masked tileset (the offset 16000 is subtracted, of course). The cell value will be zero for the first solid tile, it will be eight for the second solid tile, it will be 15992 for the last solid tile, and it will be 16000 for the first masked tile.

This means that if the solid and masked tiles have been treated as separate images, a check will need to be performed so that any cell value below 16000 is loaded from the solid tileset, and any value larger than this is loaded from the masked tileset (after subtracting 16000 from the cell value, to put it at zero for the first masked tile.) However, since the masked tiles consist of five planes, the values for the masked tiles are at multiples of five tiles (tile #0 (x=0) is the first tile, tile #5 (x=40) is the second tile.) The following formula can be used to convert the values into tile numbers once they stray into the masked tile area:

#define COSMO_TS_SOLID_NUMTILES 2000 // 40x25
#define COSMO_TS_MASKED_NUMTILES 1000 // 40x4

tile = cell_value / 8
if (tile > COSMO_TS_SOLID_NUMTILES) {
// Once we're in the masked tileset it counts up in multiples of five planes
tile = COSMO_TS_SOLID_NUMTILES + (tile - COSMO_TS_SOLID_NUMTILES) / 5;
}
// Now 'tile' will be between 0 and 2999 inclusive

As an example of a few tile values:

{|class="wikitable"
! Cell value !! Tile number !! Tileset !! Index !! Comments
|-
| 0 || 0 || N/A || N/A || See through to map backdrop
|-
| 8 || 1 || Solid || 1 || First solid tile, note increment of 8
|-
| 16 || 2 || Solid || 2 || Second solid tile, increment of 8 again
|-
| 15992 || 1999 || Solid || 1999 || Last solid tile
|-
| 16000 || 2000 || Masked || 0 || First masked tile
|-
| 16040 || 2001 || Masked || 1 || Second masked tile, note increment of 40
|-
| 16080 || 2002 || Masked || 2 || Third masked tile, increment of 40 again
|-
| 55960 || 2999 || Masked || 999 || Last masked tile
|-
| 56000 || N/A || N/A || N/A || Should never get a value this size or larger
|}

Note that while the cell value cannot be out of range for the solid tiles/background layer (since any values larger than 16000 will be loaded from the masked tileset) the cell values for the masked tileset have no such restriction. (Although obviously out of range tiles will not be drawn correctly by the engine!)

Another thing to keep in mind is that the game will simply draw the background for any cell value smaller than 80. The first ten tiles in the tileset are never drawn in the game, but they should be drawn by a level editor.

==== Gotchas ====

* The first ten tiles in the solid tileset is used as transparent tiles. The game does not draw these tile, so any cells with this as the background cell will be where the map backdrop shows through. If you wish to draw the map with the backdrop in-place, remember not to draw tile #0 over the top of the backdrop.

* The solid tiles #1 to #8 are used to define a path, along which the platforms move in the game. The path should be laid out in a loop and should never lead to a non-direction tile. If tile #0 is part of the path, the platform will stop moving once it reaches that cell. Any tile larger than #8 will lead to the game reading memory beyond an array boundary, which will result in undefined behavior.

=== Actor data ===

The <tt>actorData</tt> block is in the following format:

{|class="wikitable"
!Data type!!Description
|-
|UINT16LE iType||Type of actor
|-
|UINT16LE iX||X-coordinate of actor (in tile units)
|-
|UINT16LE iY||Y-coordinate of actor (in tile units)
|}

Because the <tt>iActorSize</tt> value in the header is in UINT16s and there are three UINT16s per actor, the number of actors can be obtained quite simply:

iNumActors = iActorSize / 3

This is exactly how the game treats this value.

==== Mapping Actor Types to image indices ====

For the ActorTypes from 31 to 296 (inclusive), you can get an image index from ACTORS.MNI and ACTRINFO.MNI like this:

ImageIndex = ActorType - 31

However, this does not work for every ActorType. Some share the same images (e.g.: normal stars and falling stars), some use flipped versions of other images (like the pink eye plants) and some are invisible in the game. In either case, the index in the ACTRINFO.MNI will be "empty". You will either have to include hard-coded info to draw these, or just draw something else (like the actual ActorType as text).

==== List of Actor Types ====

This is a list of all the actor types that are actually used by the game. Any value not listed here will be ignored by the game.

Limitations:
* Using more than 10 platforms or more than 10 mud fountains (total) in a level will lead to memory corruption.
* There can be up to 199 lights in a level (if there are more, the game will ignore the rest).
* There can be up to 410 actors in a level. Anything with a type value of 31 and above counts as an actor, but invalid/unused types will not take up an actor slot. The game will stop parsing the <tt>actorData</tt> array immediately after spawning actor #410, ignoring any other data that might be left in the unparsed part of the array, such as platforms, mud fountains, ligths and even Cosmo.

{|class="wikitable"
! Type !! Actor Sprite !! X !! Y !! Description
|-
| 0 || N/A || x || y || Cosmo (Starting position, facing right)
|-
| 1 || N/A || x || y || moving platform (fixed path)
|-
| 2 || 79 || x-1 || y-1 || mud fountain 1 (small)
|-
| 3 || 79 || x-1 || y-1 || mud fountain 2 (medium)
|-
| 4 || 79 || x-1 || y-1 || mud fountain 3 (large)
|-
| 5 || 79 || x-1 || y-1 || mud fountain 4 (huge)
|-
| 6 || N/A || x || y || light shining down (left side)
|-
| 7 || N/A || x || y || light shining down (middle)
|-
| 8 || N/A || x || y || light shining down (right side)
|}
{|class="wikitable"
! Type !! Actor Sprite !! X !! Y !! Description
|-
| 31 || 0 || x || y || CRATE: empty
|-
| 32 || 1 || x || y || BONUS: Star (200)
|-
| 33 || 2 || x || y || PLAT: Floor Spring
|-
| 34 || 3 || x || y || HAZARD: Extending Arrow Spear (from right to left)
|-
| 35 || 4 || x-4 || y || HAZARD: Extending Arrow Spear (from left to right)
|-
| 36 || 5 || x || y || HAZARD: Plasma Fireball (from right to left)
|-
| 37 || 5 || x-1 || y || HAZARD: Plasma Fireball (from left to right)
|-
| 38 || 7 || x || y+1 || Blue Switch (on ceiling)
|-
| 39 || 8 || x || y+1 || Red Switch (on ceiling)
|-
| 40 || 9 || x || y+1 || Green Switch (on ceiling)
|-
| 41 || 10 || x || y+1 || Yellow Switch (on ceiling)
|-
| 42 || 11 || x || y || Blue Door
|-
| 43 || 12 || x || y || Red Door
|-
| 44 || 13 || x || y || Green Door
|-
| 45 || 14 || x || y || Yellow Door
|-
| 47 || 16 || x || y || OBJECT: Blue Mobile Trampoline Car
|-
| 48 || 17 || x || y || HAZARD: Non-Retracting Spikes
|-
| 49 || 18 || x || y || HAZARD: Retracting Spikes
|-
| 51 || 20 || x || y || HAZARD: Big Saw Blade (moving up/down)
|-
| 53 || 20 || x || y || HAZARD: Big Saw Blade (moving left/right)
|-
| 55 || 24 || x || y || HAZARD: Activated Bomb
|-
| 56 || 25 || x || y || HAZARD: Green Pruny Cabbage Ball (takes 1 hit)
|-
| 59 || 28 || x || y || BONUS: Power Up (health/12800)
|-
| 60 || 29/28 || x || y || BARREL: Power Up (health/12800)
|-
| 62 || 0/32 || x || y || CRATE: Green Tomato
|-
| 63 || 32 || x || y || BONUS: Green Tomato (falling)
|-
| 64 || 0/33 || x || y || CRATE: Tomato (200)
|-
| 65 || 33 || x || y || BONUS: Tomato (falling)
|-
| 66 || 0/36 || x || y || CRATE: Yellow/Cyan Fruit
|-
| 67 || 36 || x || y || BONUS: Yellow/Cyan Fruit (falling)
|-
| 68 || 0/38 || x || y || CRATE: Cyan Fruit
|-
| 69 || 38 || x || y || BONUS: Cyan fruit (falling)
|-
| 70 || 39 || x || y || OBJECT: Exit Sign (ends level on touch)
|-
| 71 || 41 || x || y || HAZARD: Spear (not moving)
|-
| 72 || 41 || x || y || HAZARD: Spear (coming down from ceiling)
|-
| 73 || 43 || x || y+1 || HAZARD: Leaking Green Acid
|-
| 74 || 43 || x || y+1 || HAZARD: Dripping Green Acid
|-
| 75 || 44 || x || y || ENEMY: Plasma Energy Sprites (Blue Flame-like creatures)
|-
| 76 || 45 || x || y || HAZARD: "Two Tons" Weight going down & up
|-
| 77 || 46 || x || y || ENEMY: Jumping Bulletheads
|-
| 78 || 47 || x || y || ENEMY: Stone Heads (Only drops when Cosmo is close by)
|-
| 79 || 49 || x || y+1 || HAZARD: Big Yellow Spike on ceiling
|-
| 80 || 49 || x || y+1 || HAZARD: Big Yellow Spike on ceiling (falling down)
|-
| 81 || 49i || x || y || HAZARD: Big Yellow Spike on ground
|-
| 82 || 51 || x || y || ENEMY: Ghost
|-
| 83 || 0/135 || x || y || CRATE: Green thing
|-
| 84 || 0/136 || x || y || CRATE: Blue thing
|-
| 85 || 54 || x || y || ENEMY: Angry Moon (blue floating characters)
|-
| 86 || 55 || x || y || ENEMY: Small Red Plant
|-
| 87 || 29/57 || x || y || BARREL: Bomb (100)
|-
| 88 || 57 || x || y || BONUS: Bomb (100)
|-
| 89 || 29/2 || x || y || BARREL: Floor Spring
|-
| 90 || 60 || x || y || OBJECT: switch (1) (Activates moving platform(s))
|-
| 92 || 60 || x || y || OBJECT: switch (2) (Activates Question Mark Block Wall Generator)
|-
| 93 || 62 || x || y || OBJECT: Question Mark Block (Generates a wall when activated by switch)
|-
| 94 || 63 || x || y || HAZARD: Ground Claw Spikes
|-
| 95 || 64 || x || y || OBJECT: Rubber Wall (can blow it up, throws Cosmo backwards when touched)
|-
| 96 || 65 || x || y || ENEMY: Mini Ghost (jumps)
|-
| 97 || 68 || x || y || HAZARD: Flashing ball projectile (Moving South West)
|-
| 98 || 68 || x || y || HAZARD: Flashing ball projectile (Moving South East)
|-
| 99 || 68 || x || y || HAZARD: Flashing ball projectile (Moving South)
|-
|100 || 69 || x || y || CREATURE: Green Roamer Worm
|-
|101 || 70 || x || y || PIPE TRANSIT DIRECTION: Arrow Up
|-
|102 || 71 || x || y || PIPE TRANSIT DIRECTION: Arrow Down
|-
|103 || 72 || x || y || PIPE TRANSIT DIRECTION: Arrow Left
|-
|104 || 73 || x || y || PIPE TRANSIT DIRECTION: Arrow Right
|-
|105 || 75 || x || y || ENEMY: Egg Head (cracks when player is near)
|-
|106 || 75 || x || y || ENEMY: Egg Head (cracks when pounced)
|-
|109 || 78 || x || y || ENEMY: Robotic Spike on ground
|-
|111 || 80 || x || y+2 || ENEMY: Robotic Spike on ceiling
|-
|112 || 0/82 || x || y || CRATE: Burger
|-
|113 || 82 || x || y || BONUS: Burger
|-
|114 || 83 || x || y || ENEMY: Blue/Red Clam Plant on ground
|-
|115 || 83i || x || y+2 || ENEMY: Blue/Red Clam Plant on ceiling
|-
|116 || 85 || x || y+2 || BONUS: Purple Grapes (800)
|-
|117 || 86 || x || y || ENEMY: Blue Ball
|-
|118 || 87 || x || y || HAZARD: Spikes (on left wall)
|-
|119 || 88 || x || y || HAZARD: Retracting Spikes (on left wall)
|-
|120 || 89 || x-3 || y || ENEMY: Spikes (on right wall)
|-
|121 || 90 || x || y || ENEMY: Robot with Blue Vertical Electric Arc
|-
|122 || 91 || x || y || PLAT: Blue Platform (splits open when standing on top)
|-
|123 || 92 || x || y || ENEMY: Spark
|-
|124 || 0/94 || x || y || CRATE: Cyan Dancing Mushroom (400)
|-
|125 || 94 || x || y || BONUS: Cyan Dancing Mushroom (400)
|-
|126 || 95 || x || y || DECO: Pink Eye Plant
|-
|127 || 95i || x || y+1 || DECO: Pink Eye Plant (hanging upside down)
|-
|131 || 29/251 || x || y || BARREL: Cabbage Monster (see type 282)
|-
|132 || 101 || x || y || ENEMY: Big Red Jumper (NOT IMPLEMENTED IN COSMO1!)
|-
|133 || 102 || x || y || ENEMY: BOSS (Purple Alien in Spike-bottomed ship) (NOT IMPLEMENTED IN COSMO2!)
|-
|135 || 105 || x-1 || y+2 || PNEUMATIC PIPES: Exit
|-
|136 || 105 || x-1 || y+2 || PNEUMATIC PIPES: Entrance
|-
|137 || 106 || x || y || ENEMY: Suction-Cup-Legged Alien
|-
|138 || 108 || x || y || OBJECT: Teleporter A
|-
|139 || 108 || x || y || OBJECT: Teleporter B
|-
|140 || 68 || x || y || HAZARD: Flashing ball projectile (Moving West)
|-
|141 || 68 || x || y || HAZARD: Flashing ball projectile (Moving East)
|-
|142 || 112 || x-3 || y || ENEMY: Cyan Spitting Plant (on left wall)
|-
|143 || 111 || x || y || ENEMY: Cyan Spitting Plant (on right wall)
|-
|144 || 113 || x || y || ENEMY: Blue Turret Alien
|-
|145 || 114 || x || y || PLAT: Hoverboard
|-
|146 || 0/138 || x || y || CRATE: pile of green balls
|-
|147 || 0/139 || x || y || CRATE: blue/yellow fruit
|-
|148 || 29/140 || x || y || BARREL: Saxophone-like thing
|-
|149 || 118 || x || y || ENEMY: Red Chomper Alien
|-
|150 || 0/137 || x || y || CRATE: Salad
|-
|151 || 60 || x || y || switch (3) (Activates lights, if actors 6,7, & 8 are present in level.)
|-
|152 || 60 || x || y || switch (4) (Deactivates Actors 153 & 154; Energy Beams)
|-
|153 || 122 || x || y || HAZARD: Vertical Energy Beam (Deactivated by Switch)
|-
|154 || 123 || x || y || HAZARD: Horizontal Energy Beam (Deactivated by Switch)
|-
|155 || 124 || x || y || ENEMY: Pink slug/Worm (Turns to bubbling goo when jumped upon)
|-
|156 || 125 || x || y || HINT GLOBE #0: "These hint globes will help you along your journey. Press the up key to reread them."
|-
|157 || 126 || x || y || ENEMY: Silver Robot (pushes player around)
|-
|158 || 127 || x || y || ENEMY: Security Robot (shoots flashing bullet, can act as moving floor spring)
|-
|159 || 128 || x || y || HAZARD: Bubbling pink goo (see type 155)
|-
|160 || 129 || x || y || PLAT/HAZARD: Dragonfly
|-
|161 || 130 || x || y || Slug Box (explodes and spawns a slug, can only be destroyed safely with bombs)
|-
|165 || 134 || x || y || BONUS: Bottle with red liquid
|-
|166 || 135 || x || y || BONUS: Green thing
|-
|167 || 136 || x || y || BONUS: Blue thing
|-
|168 || 137 || x || y || BONUS: Salad?
|-
|169 || 138 || x || y || BONUS: Pile of green balls
|-
|170 || 139 || x || y || BONUS: Blue/yellow fruit
|-
|171 || 140 || x || y || BONUS: Saxophone-like thing
|-
|172 || 141 || x || y+2 || BONUS: blue thing
|-
|173 || 29/134 || x || y || BARREL: Bottle with red liquid
|-
|174 || 143 || x || y || DECO/BONUS: Satellite (can be destroyed with bombs, spawns a hamburger)
|-
|176 || 145 || x || y || ENEMY: Green Ivy Plant
|-
|177 || 146 || x || y+2 || BONUS: 5 Yellow Grapes (800)
|-
|178 || 147 || x || y || BONUS: Headdress-like object
|-
|179 || 0/147 || x || y || CRATE: with item 178
|-
|180 || 149 || x-4 || y || EXIT: Jaws & Tongue (facing left)
|-
|181 || 150 || x || y || EXIT: invisible exit marker (go right to exit)
|-
|182 || 151 || x || y || HAZARD: small flame
|-
|183 || 152 || x || y || ENEMY: Big Red Plant (spitting Blue Balls/catapult)
|-
|184 || 153 || x || y || BONUS: Red/green gem
|-
|185 || 154 || x || y || BONUS: Blue Crystal (on ground)
|-
|186 || 155 || x || y || BONUS: Red Crystal (on ground)
|-
|187 || 29/153 || x || y || BARREL: Red/Green Gem
|-
|188 || 29/154 || x || y || BARREL: Blue Crystal
|-
|189 || 29/155 || x || y || BARREL: Red Crystal
|-
|190 || 32 || x || y || BONUS: Green Tomato (floating)
|-
|191 || 34 || x || y || BONUS: Tomato (floating)
|-
|192 || 36 || x || y || BONUS: Yellow/Cyan Fruit (floating) (200)
|-
|193 || 162 || x || y || HAZARD: Clamp Trap
|-
|194 || 163 || x || y || PLAT: Blue Cube (falls down when you walk off)
|-
|195 || 164 || x || y || TRIGGER: "What's happening? Is Cosmo falling to his doom?" (ONLY IN COSMO1!)
|-
|196 || 164 || x || y || TRIGGER: "Is there no end to this pit? An what danger awaits below?!" (ONLY IN COSMO1!)
|-
|197 || 164 || x || y || TRIGGER: Win game (ONLY IN COSMO1!)
|-
|198 || 0/168 || x || y || CRATE: Root (400)
|-
|199 || 168 || x || y || BONUS: Root
|-
|200 || 0/170 || x || y || CRATE: 4 Brown Berries (400)
|-
|201 || 170 || x || y || BONUS: 4 Brown Berries
|-
|202 || 0/172 || x || y || CRATE: Potato-like vegetable
|-
|203 || 172 || x || y || BONUS: Potato-like vegetable
|-
|204 || 29/174 || x || y || BARREL: Green Gem
|-
|205 || 174 || x || y || BONUS: Green Gem
|-
|206 || 29/176 || x || y || BARREL: Diamond (3200)
|-
|207 || 176 || x || y || BONUS: Diamond
|-
|208 || 177 || x || y || MESSAGE: Floating score effect (100)
|-
|209 || 178 || x || y || MESSAGE: Floating score effect (200)
|-
|210 || 179 || x || y || MESSAGE: Floating score effect (400)
|-
|211 || 180 || x || y || MESSAGE: Floating score effect (800)
|-
|212 || 181 || x || y || MESSAGE: Floating score effect (1600)
|-
|213 || 182 || x || y || MESSAGE: Floating score effect (3200)
|-
|214 || 183 || x || y || MESSAGE: Floating score effect (6400)
|-
|215 || 184 || x || y || MESSAGE: Floating score effect (12800)
|-
|217 || 186 || x || y || EXIT: Alien-Eating Space Plant (Exits the current level)
|-
|218 || 187 || x || y || ENEMY: Blue Bird
|-
|219 || 188 || x || y || OBJECT: Rocket
|-
|220 || 189 || x || y || BONUS: Invincibility Cube
|-
|221 || 192 || x || y || PLAT: Destructible Pedestal 1 (14 tiles high)
|-
|222 || 192 || x || y || PLAT: Destructible Pedestal 2 (20 tiles high)
|-
|223 || 192 || x || y || PLAT: Destructible Pedestal 3 (26 tiles high)
|-
|224 || 29/194 || x || y || BARREL: Diamond 2
|-
|225 || 194 || x || y || BONUS: Diamond 2 (falling)
|-
|226 || 29/196 || x || y || BARREL: Red Berry
|-
|227 || 196 || x || y || BONUS: Red Berry (falling)
|-
|228 || 29/198 || x || y || BARREL: Crystal (800)
|-
|229 || 198 || x || y || BONUS: Crystal (falling)
|-
|230 || 29/200 || x || y || BARREL: Blue Gem
|-
|231 || 200 || x || y || BONUS: Blue Gem (falling)
|-
|232 || 201 || x || y || Invincibility Shield (automatically makes player invincible when it becomes visible)
|-
|233 || 202 || x || y+2 || DECO: Rocket Exhaust
|-
|234 || 108 || x || y || EXIT: Teleporter
|-
|235 || 125 || x || y || HINT GLOBE #1: "Bump head into switch above!"
|-
|236 || 125 || x || y || HINT GLOBE #2: "The ice in this cave is very, very slippery."
|-
|237 || 125 || x || y || HINT GLOBE #3: "Use this shield for temporary invincibility."
|-
|238 || 125 || x || y || HINT GLOBE #4: "You found a secret area!!! Good Job!"
|-
|239 || 125 || x || y || HINT GLOBE #5: "In hight places look up to find bonus objects."
|-
|240 || 125 || x || y || HINT GLOBE #6: "Out of Order..."
|-
|241 || 125 || x || y || HINT GLOBE #7: "This might be a good time to save your game!"
|-
|242 || 125 || x || y || HINT GLOBE #8: "Press your up key to use the transporter."
|-
|243 || 125 || x || y || HINT GLOBE #9: "(1) FOR..."
|-
|244 || 194 || x || y || BONUS: Diamond 2
|-
|245 || 196 || x || y || BONUS: Red Berry
|-
|246 || 198 || x || y || BONUS: Crystal
|-
|247 || 200 || x || y || BONUS: Blue Gem (800)
|-
|248 || 2i || x || y || PLAT: Ceiling Spring
|-
|249 || 29/220 || x || y || BARREL: Headphones
|-
|250 || 220 || x || y || BONUS: Headphones
|-
|251 || 220 || x || y || BONUS: Headphones (falling)
|-
|252 || 221 || x || y || OBJECT: Frozen Duke NukUm (IMPLEMENTED ONLY IN COSMO2!)
|-
|254 || 223 || x || y || BONUS: 3 Bananas (800)
|-
|255 || 0/226 || x || y || CRATE: Alien Raisin
|-
|256 || 226 || x || y || BONUS: Alien Raisin (400)
|-
|257 || 226 || x || y || BONUS: Alien Raisin (falling) (400)
|-
|258 || 0/229 || x || y || CRATE: Brown Pear
|-
|259 || 229 || x || y || BONUS: Brown Pear
|-
|260 || 229 || x || y || BONUS: Brown Pear (falling)
|-
|261 || 0/232 || x || y || CRATE: Alien Chili Pepper
|-
|262 || 232 || x || y || BONUS: Alien Chili Pepper (400)
|-
|263 || 232 || x || y || BONUS: Alien Chili Pepper (falling) (400)
|-
|264 || 233 || x-1 || y || HAZARD: Flame (<-)
|-
|265 || 234 || x || y || DANGER: Flame (->)
|-
|266 || 235 || x || y || MESSAGE: "OUCH!" (Speech bubble)
|-
|267 || 237 || x || y+1 || HAZARD: Leaking Red acid
|-
|268 || 237 || x || y+1 || HAZARD: Dripping Red Acid
|-
|269 || 125 || x || y || HINT GLOBE #10: "(2) EXTRA..."
|-
|270 || 125 || x || y || HINT GLOBE #11: "(3) POINTS,..."
|-
|271 || 125 || x || y || HINT GLOBE #12: "(4) DESTROY..."
|-
|272 || 125 || x || y || HINT GLOBE #13: "(5) HINT..."
|-
|273 || 125 || x || y || HINT GLOBE #14: "(6) GLOBES!!!"
|-
|274 || 125 || x || y || HINT GLOBE #15: "The Clam Plants won't hurt you if their mouths are closed."+Clam Sprite
|-
|275 || 244 || x || y || MESSAGE: "WHOA!" (Speech bubble)
|-
|276 || 245 || x || y || MESSAGE: "UMPH!" (Speech bubble)
|-
|277 || 246 || x || y || MESSAGE: "WOW! 50,000 POINTS!" (Speech bubble)
|-
|278 || 247 || x || y || EXIT: Big Mouth (facing up) (ends the level ONLY IN COSMO2!)
|-
|279 || 248 || x || y || DECO: Normal Smoke Rising
|-
|280 || 249 || x || y || DECO: Big Smoke rising
|-
|281 || 250 || x || y || EXIT: Exits the level when Cosmo is below the position
|-
|282 || 25 || x || y || ENEMY: Green Pruny Cabbage Ball (takes 2 hits)
|-
|283 || 155 || x || y+1 || BONUS: Red Crystal on ceiling
|-
|284 || 125 || x || y || HINT GLOBE #16: "Collect the STARS to advance to BONUS STAGES."
|-
|285 || 125 || x || y || HINT GLOBE #17: "Some creatures require more than one pounce to defeat!"
|-
|286 || 125 || x || y || HINT GLOBE #18: "Cosmo can climb wall's with his suction hands."+CosmoWallSprite
|-
|287 || 125 || x || y || HINT GLOBE #19: (unused)
|-
|288 || 125 || x || y || HINT GLOBE #20: (unused)
|-
|289 || 125 || x || y || HINT GLOBE #21: (unused)
|-
|290 || 125 || x || y || HINT GLOBE #22: (unused)
|-
|291 || 125 || x || y || HINT GLOBE #23: (unused)
|-
|292 || 125 || x || y || HINT GLOBE #24: (unused)
|-
|293 || 125 || x || y || HINT GLOBE #25: (unused)
|-
|294 || 28 || x || y || BONUS: Power Up Module (falling) (health/12800)
|-
|295 || 1 || x || y || BONUS: Star (falling) (200)
|-
|296 || 265 || x || y+3 || EXIT: Game is won when Cosmo is above this position
|}

The hint texts are the messages you get in episode 1, the other episodes have different (and less!) messages. The unused hint globes will animate and can be blown up, but they will not show a message.

== Credits ==

This file format was reverse engineered by [http://archive.shikadi.net/sites/www.geocities.com/dooknookimklassik/ Dave Bollinger]. Most of this info came from the [http://archive.shikadi.net/sites/www.geocities.com/dooknookimklassik/dn2specs.txt Duke II specs on his website], with [[User:Malvineous|Malvineous]] working out which bits to remove to read Cosmo maps. 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!)

Cosmo Level Format

2017-11-23T01:44:35Z

K1n9 Duk3: new info & some new actor types -- will finish this later.

{{Map Infobox
| Type = 2D tile-based
| Layers = 3
| Tile size = 8×8
| Viewport = 304×144
| Games =
{{Game|Cosmo's Cosmic Adventures}}
}}

== File format ==
The file is in this basic layout:

{|class="wikitable"
!Data type!!Description
|-
|UINT16LE iFlags||Flags indicating music, backdrop and other stuff
|-
|UINT16LE iMapWidth||Map width in tiles
|-
|UINT16LE iActorSize||Number of UINT16 values in the actor block
|-
|ACTORDATA actorData[]||Variable-length array of all the actors in the level
|-
|BYTE bgLayer[65528]||The map data for the background layer
|}

The iMapWidth values in the original Cosmo levels is either 64, 128, 256 or 512. The "view window" in the game is 304x144 Pixels, so the minimal map width would be 38. However, the game will ''only'' recognize the values 32, 64, 128, 256, 512, 1024 and 2048. Any other value will not be handled by the game at all, thus leaving a vital variable uninitialized. However, the values 32 and 2048 should never be used in a level, since the width or height of the level would be smaller than the viewport.

The iActorSize values are reliable for all the original Cosmo level files (Version 1.20). Since the game loads the entire actorData array into a block of 65535 bytes, the iActorSize value must be less than 32766. Larger values would lead to memory corruption.

The map data found in the original level files is actually sized 65528 Bytes or 32764 Words, but the game will read it a block of up to 65535 bytes. Each Word entry in this block is divisable by 8 (see [[#Mapping cell values to tiles]]).

=== Level Flags ===

The structure of the bits in the iFlags value is as follows:

[ mmmmm | ppp | yxr | bbbbb ]

m: music index
p: palette animation type
y: y-scrolling backdrop
x: x-scrolling backdrop
r: rain
b: backdrop index

Assuming the iFlags value was read as a UINT16LE, the value can be split like this:

rain = (iFlags & 0x20) != 0;
backdrop = iFlags & 0x1F;
scrollX = (iFlags & 0x40) != 0;
scrollY = (iFlags & 0x80) != 0;
animation = (iFlags >> 8) & 7;
music = (iflags >> 11) & 0x1F;

The indices for music and backdrop refer to an array of filename strings stored in the executable. You can find them by searching for the first filename in each array. For backdrops, the first filename (index: 0) is <tt>BDBLANK.MNI</tt>, for music it's <tt>MCAVES.MNI</tt>. Note that some backdrop files are not used by the games. The complete list is:

{|class="wikitable" style="float: left;"
! Backdrop value !! Filename
|-
| 0 || bdblank.mni
|-
| 1 || bdpipe.mni
|-
| 2 || bdredsky.mni
|-
| 3 || bdrocktk.mni
|-
| 4 || bdjungle.mni
|-
| 5 || bdstar.mni
|-
| 6 || bdwierd.mni
|-
| 7 || bdcave.mni
|-
| 8 || bdice.mni
|-
| 9 || bdshrum.mni
|-
| 10 || bdtechms.mni
|-
| 11 || bdnewsky.mni
|-
| 12 || bdstar2.mni
|-
| 13 || bdstar3.mni
|-
| 14 || bdforest.mni
|-
| 15 || bdmountn.mni
|-
| 16 || bdguts.mni
|-
| 17 || bdbrktec.mni
|-
| 18 || bdclouds.mni
|-
| 19 || bdfutcty.mni
|-
| 20 || bdice2.mni
|-
| 21 || bdcliff.mni
|-
| 22 || bdspooky.mni
|-
| 23 || bdcrystl.mni
|-
| 24 || bdcircut.mni
|-
| 25 || bdcircpc.mni
|-
| 26-31 || ''Unused''
|}

{|class="wikitable" style="float: left;"
! Music value !! Filename
|-
| 0 || mcaves.mni
|-
| 1 || mscarry.mni
|-
| 2 || mboss.mni
|-
| 3 || mrunaway.mni
|-
| 4 || mcircus.mni
|-
| 5 || mtekwrd.mni
|-
| 6 || measylev.mni
|-
| 7 || mrockit.mni
|-
| 8 || mhappy.mni
|-
| 9 || mdevo.mni
|-
| 10 || mdadoda.mni
|-
| 11 || mbells.mni
|-
| 12 || mdrums.mni
|-
| 13 || mbanjo.mni
|-
| 14 || measy2.mni
|-
| 15 || mteck2.mni
|-
| 16 || mteck3.mni
|-
| 17 || mteck4.mni
|-
| 18 || mzztop.mni
|-
| 19-31 || ''Unused''
|}

{|class="wikitable" style="float: left;"
! Animation value !! Use !! Description
|-
| 0 || most levels || no palette changes
|-
| 1 || A4 || random lightning (with thunder soundeffect)
|-
| 2 || C8-C10 || cycling: red -> yellow -> white
|-
| 3 || A7 || cycling: red -> green -> blue
|-
| 4 || A8, B3, B4, B7 || cycling: black -> grey -> white
|-
| 5 || C6, C7 || flashing: red -> magenta -> white
|-
| 6 || C1 || replace dark magenta with black, no animation unless triggered by a bomb actor. (ONLY PRESENT IN COSMO3.EXE.)
|-
| 7 || None || no palette changes
|}

 

=== Background Layer ===

The <tt>bgLayer</tt> block contains the grid/cell data:

{|class="wikitable"
!Data type!!Description
|-
|UINT16LE iMapData[32764]||Actual map data
|}

Each "element" in <tt>iMapData</tt> refers to the foreground and/or background tile used in a single grid cell. The grids are arranged left to right, top to bottom, so the index can be calculated by this formula:

int iIndex = (y * iMapWidth) + x;
iMapData[iIndex] = <new value to set at x,y>

The map data in the original Cosmo level files is a constant 32764 UINT16LE cells long (65528 bytes), and the engine will never read more than 65535 bytes. However, the game calculates the map height using this formula:

int iMapHeight = 32768 / iMapWidth - 1;

Since the width of the map is always a power of 2 (min. 64), you can see that each of the original level files is "missing" 8 Bytes (or 4 Words). That means the last line of the map will always be missing the last 4 tiles. The game ignores that last, incomplete line (hence the -1 in the formula). However, in one level (A8.MNI), there is an actor placed in that last line. Since actors are saved as individual structures instead of a grid, that actor will still be loaded by the game. For editing a level, you should make sure the last line is visible, so that it's possible to place actors in that line or remove them from there. Using a buffer of at least 65536 bytes for the level tiles is highly recommended for this.

==== Mapping cell values to tiles ====

The method of mapping elements in the <tt>iMapData</tt> structure into tiles is fairly straightforward. Each cell value is a pixel index into the tilemap. Imagine the tileset laid out left to right all on the one row. Since each tile is 8x8 pixels, at 16 pixels into the image, the third tile will begin (x = 0 for first tile, x = 8 for second tile, x = 16 for third tile.) Assuming the solid/unmasked tileset graphics are layed out as an 8 pixel wide column, the cell value is essentially a pixel y-coordinate into the solid/unmasked tileset.

Note that in the tileset file, the solid tiles are made up of 2000 4-plane (16-colour) images, and these are followed by 1000 5-plane images (16-colour + transparency.) The game interprets any value smaller than 16000 as an index into the solid/unmasked tileset. Any other value will be treated as an index into the masked tileset (the offset 16000 is subtracted, of course). The cell value will be zero for the first solid tile, it will be eight for the second solid tile, it will be 15992 for the last solid tile, and it will be 16000 for the first masked tile.

This means that if the solid and masked tiles have been treated as separate images, a check will need to be performed so that any cell value below 16000 is loaded from the solid tileset, and any value larger than this is loaded from the masked tileset (after subtracting 16000 from the cell value, to put it at zero for the first masked tile.) However, since the masked tiles consist of five planes, the values for the masked tiles are at multiples of five tiles (tile #0 (x=0) is the first tile, tile #5 (x=40) is the second tile.) The following formula can be used to convert the values into tile numbers once they stray into the masked tile area:

#define COSMO_TS_SOLID_NUMTILES 2000 // 40x25
#define COSMO_TS_MASKED_NUMTILES 1000 // 40x4

tile = cell_value / 8
if (tile > COSMO_TS_SOLID_NUMTILES) {
// Once we're in the masked tileset it counts up in multiples of five planes
tile = COSMO_TS_SOLID_NUMTILES + (tile - COSMO_TS_SOLID_NUMTILES) / 5;
}
// Now 'tile' will be between 0 and 2999 inclusive

As an example of a few tile values:

{|class="wikitable"
! Cell value !! Tile number !! Tileset !! Index !! Comments
|-
| 0 || 0 || N/A || N/A || See through to map backdrop
|-
| 8 || 1 || Solid || 1 || First solid tile, note increment of 8
|-
| 16 || 2 || Solid || 2 || Second solid tile, increment of 8 again
|-
| 15992 || 1999 || Solid || 1999 || Last solid tile
|-
| 16000 || 2000 || Masked || 0 || First masked tile
|-
| 16040 || 2001 || Masked || 1 || Second masked tile, note increment of 40
|-
| 16080 || 2002 || Masked || 2 || Third masked tile, increment of 40 again
|-
| 55960 || 2999 || Masked || 999 || Last masked tile
|-
| 56000 || N/A || N/A || N/A || Should never get a value this size or larger
|}

Note that while the cell value cannot be out of range for the solid tiles/background layer (since any values larger than 16000 will be loaded from the masked tileset) the cell values for the masked tileset have no such restriction. (Although obviously out of range tiles will not be drawn correctly by the engine!)

Another thing to keep in mind is that the game will simply draw the background for any cell value smaller than 80. The first ten tiles in the tileset are never drawn in the game, but they should be drawn by a level editor.

==== Gotchas ====

* The first ten tiles in the solid tileset is used as transparent tiles. The game does not draw these tile, so any cells with this as the background cell will be where the map backdrop shows through. If you wish to draw the map with the backdrop in-place, remember not to draw tile #0 over the top of the backdrop.

* The solid tiles #1 to #8 are used to define a path, along which the platforms move in the game. The path should be laid out in a loop and should never lead to a non-direction tile. If tile #0 is part of the path, the platform will stop moving once it reaches that cell. Any tile larger than #8 will lead to the game reading memory beyond an array boundary, which will result in undefined behavior.

=== Actor data ===

The <tt>actorData</tt> block is in the following format:

{|class="wikitable"
!Data type!!Description
|-
|UINT16LE iType||Type of actor
|-
|UINT16LE iX||X-coordinate of actor (in tile units)
|-
|UINT16LE iY||Y-coordinate of actor (in tile units)
|}

Because the <tt>iActorSize</tt> value in the header is in UINT16s and there are three UINT16s per actor, the number of actors can be obtained quite simply:

iNumActors = iActorSize / 3

This is exactly how the game treats this value.

==== Mapping Actor Types to image indices ====

For the ActorTypes from 31 to 296 (inclusive), you can get an image index from ACTORS.MNI and ACTRINFO.MNI like this:

ImageIndex = ActorType - 31

However, this does not work for every ActorType. Some share the same images (e.g.: normal stars and falling stars), some use flipped versions of other images (like the pink eye plants) and some are invisible in the game. In either case, the index in the ACTRINFO.MNI will be "empty". You will either have to include hard-coded info to draw these, or just draw something else (like the actual ActorType as text).

==== List of Actor Types ====

This is a list of all the actor types that are actually used by the game. Any value not listed here will be ignored by the game.

Limitations:
* Using more than 10 platforms or more than 10 mud fountains (total) in a level will lead to memory corruption.
* There can be up to 199 lights in a level (if there are more, the game will ignore the rest).
* There can be up to 410 actors in a level. Anything with a type value of 31 and above counts as an actor, but invalid/unused types will not take up an actor slot. The game will stop parsing the <tt>actorData</tt> array once after spawning actor #410, ignoring any other data that might be left in the unparsed part of the array, such as platforms, mud fountains, ligths and even Cosmo.

{|class="wikitable"
! Type !! Actor Sprite !! X !! Y !! Description
|-
| 0 || N/A || x || y || Cosmo (Starting position facing right)
|-
| 1 || N/A || x || y || moving platform (fixed path)
|-
| 2 || 79 || x-1 || y-1 || mud fountain 1 (small)
|-
| 3 || 79 || x-1 || y-1 || mud fountain 2 (medium)
|-
| 4 || 79 || x-1 || y-1 || mud fountain 3 (large)
|-
| 5 || 79 || x-1 || y-1 || mud fountain 4 (huge)
|-
| 6 || N/A || x || y || light shining down (left side)
|-
| 7 || N/A || x || y || light shining down (middle)
|-
| 8 || N/A || x || y || light shining down (right side)
|}
{|class="wikitable"
! Type !! Actor Sprite !! X !! Y !! Description
|-
| 31 || 0 || x || y || CRATE: empty
|-
| 32 || 1 || x || y || BONUS: Star (200)
|-
| 33 || 2 || x || y || PLAT: Floor Spring
|-
| 34 || 3 || x || y || HAZARD: Extending Arrow Spear (from right to left)
|-
| 35 || 4 || x-4 || y || HAZARD: Extending Arrow Spear (from left to right)
|-
| 36 || 5 || x || y || HAZARD: Plasma Fireball (from right to left)
|-
| 37 || 5 || x-1 || y || HAZARD: Plasma Fireball (from left to right)
|-
| 38 || 7 || x || y+1 || Blue Switch (on ceiling)
|-
| 39 || 8 || x || y+1 || Red Switch (on ceiling)
|-
| 40 || 9 || x || y+1 || Green Switch (on ceiling)
|-
| 41 || 10 || x || y+1 || Yellow Switch (on ceiling)
|-
| 42 || 11 || x || y || Blue Door
|-
| 43 || 12 || x || y || Red Door
|-
| 44 || 13 || x || y || Green Door
|-
| 45 || 14 || x || y || Yellow Door
|-
| 47 || 16 || x || y || OBJECT: Blue Mobile Trampoline Car
|-
| 48 || 17 || x || y || HAZARD: Non-Retracting Spikes
|-
| 49 || 18 || x || y || HAZARD: Retracting Spikes
|-
| 51 || 20 || x || y || HAZARD: Big Saw Blade (moving up/down)
|-
| 53 || 20 || x || y || HAZARD: Big Saw Blade (moving left/right)
|-
| 55 || 24 || x || y || HAZARD: Activated Bomb
|-
| 56 || 25 || x || y || HAZARD: Green Pruny Cabbage Ball
|-
| 59 || 28 || x || y || BONUS: Power Up (health/12800)
|-
| 60 || 29/28 || x || y || BARREL: Power Up (health/12800)
|-
| 62 || 0/32 || x || y || CRATE: Green Tomato
|-
| 63 || 32 || x || y || BONUS: Green Tomato (falling)
|-
| 64 || 0/33 || x || y || CRATE: Tomato (200)
|-
| 65 || 33 || x || y || BONUS: Tomato (falling)
|-
| 66 || 0/36 || x || y || CRATE: Yellow/Cyan Fruit
|-
| 67 || 36 || x || y || BONUS: Yellow/Cyan Fruit (falling)
|-
| 68 || 0/38 || x || y || CRATE: Cyan Fruit
|-
| 69 || 38 || x || y || BONUS: Cyan fruit (falling)
|-
| 70 || 39 || x || y || OBJECT: Exit Sign (ends level on touch)
|-
| 71 || 41 || x || y || HAZARD: Spear (not moving)
|-
| 72 || 41 || x || y || HAZARD: Spear (coming down from ceiling)
|-
| 73 || 43 || x || y+1 || HAZARD: Leaking Green Acid
|-
| 74 || 43 || x || y+1 || HAZARD: Dripping Green Acid
|-
| 75 || 44 || x || y || ENEMY: Plasma Energy Sprites (Blue Flame-like creatures)
|-
| 76 || 45 || x || y || HAZARD: "Two Tons" Weight going down & up
|-
| 77 || 46 || x || y || ENEMY: Jumping Bulletheads
|-
| 78 || 47 || x || y || ENEMY: Stone Heads (Only drops when Cosmo is close by)
|-
| 79 || 49 || x || y+1 || HAZARD: Big Yellow Spike on ceiling
|-
| 80 || 49 || x || y+1 || HAZARD: Big Yellow Spike on ceiling (falling down)
|-
| 81 || 49i || x || y || HAZARD: Big Yellow Spike on ground
|-
| 82 || 51 || x || y || ENEMY: Ghost
|-
| 83 || 0/135 || x || y || CRATE: Green thing
|-
| 84 || 0/136 || x || y || CRATE: Blue thing
|-
| 85 || 54 || x || y || ENEMY: Angry Moon (blue floating characters)
|-
| 86 || 55 || x || y || ENEMY: Small Red Plant
|-
| 87 || 29/57 || x || y || BARREL: Bomb (100)
|-
| 88 || 57 || x || y || BONUS: Bomb (100)
|-
| 89 || 29/2 || x || y || BARREL: Floor Spring
|-
| 90 || 60 || x || y || OBJECT: switch (1) (Activates moving platform(s))
|-
| 92 || 60 || x || y || OBJECT: switch (2) (Activates Question Mark Block Wall Generator)
|-
| 93 || 62 || x || y || OBJECT: Question Mark Block (Generates a wall when activated by switch)
|-
| 94 || 63 || x || y || HAZARD: Ground Claw Spikes
|-
| 95 || 64 || x || y || OBJECT: Rubber Wall (can blow it up, throws Cosmo backwards when touched)
|-
| 96 || 65 || x || y || ENEMY: Mini Ghost (jumps)
|-
| 97 || 68 || x || y || HAZARD: Flashing ball projectile (Moving South West)
|-
| 98 || 68 || x || y || HAZARD: Flashing ball projectile (Moving South East)
|-
| 99 || 68 || x || y || HAZARD: Flashing ball projectile (Moving South)
|-
|100 || 69 || x || y || CREATURE: Green Roamer Worm
|-
|101 || 70 || x || y || PIPE TRANSIT DIRECTION: Arrow Up
|-
|102 || 71 || x || y || PIPE TRANSIT DIRECTION: Arrow Down
|-
|103 || 72 || x || y || PIPE TRANSIT DIRECTION: Arrow Left
|-
|104 || 73 || x || y || PIPE TRANSIT DIRECTION: Arrow Right
|-
|105 || 75 || x || y || ENEMY: Egg Head (cracks when player is near)
|-
|106 || 75 || x || y || ENEMY: Egg Head (cracks when pounced)
|-
|109 || 78 || x || y || ENEMY: Robotic Spike on ground
|-
|111 || 80 || x || y+2 || ENEMY: Robotic Spike on ceiling
|-
|112 || 0/82 || x || y || CRATE: Burger
|-
|113 || 82 || x || y || BONUS: Burger
|-
|114 || 83 || x || y || ENEMY: Blue/Red Clam Plant on ground
|-
|115 || 83i || x || y+2 || ENEMY: Blue/Red Clam Plant on ceiling
|-
|116 || 85 || x || y+2 || BONUS: Purple Grapes (800)
|-
|117 || 86 || x || y || ENEMY: Blue Ball
|-
|118 || 87 || x || y || HAZARD: Spikes (on left wall)
|-
|119 || 88 || x || y || HAZARD: Retracting Spikes (on left wall)
|-
|120 || 89 || x-3 || y || ENEMY: Spikes (on right wall)
|-
|121 || 90 || x || y || ENEMY: Robot with Blue Vertical Electric Arc
|-
|122 || 91 || x || y || PLAT: Blue Platform (splits open when standing on top)
|-
|123 || 92 || x || y || ENEMY: Spark
|-
|124 || 0/94 || x || y || CRATE: Cyan Dancing Mushroom (400)
|-
|125 || 94 || x || y || BONUS: Cyan Dancing Mushroom (400)
|-
|126 || 95 || x || y || DECO: Pink Eye Plant
|-
|127 || 95i || x || y+1 || DECO: Pink Eye Plant (hanging upside down)
|-
|131 || 29/251 || x || y || BARREL: Cabbage Monster (see type 282)
|-
|132 || 101 || x || y || ENEMY: Big Red Jumper (NOT IMPLEMENTED IN COSMO1!)
|-
|133 || 102 || x || y || ENEMY: BOSS (Purple Alien in Spike-bottomed ship) (NOT IMPLEMENTED IN COSMO2!)
|-
|135 || 105 || x-1 || y+2 || PNEUMATIC PIPES: Exit
|-
|136 || 105 || x-1 || y+2 || PNEUMATIC PIPES: Entrance
|-
|137 || 106 || x || y || ENEMY: Suction-Cup-Legged Alien
|-
|138 || 108 || x || y || OBJECT: Teleporter A
|-
|139 || 108 || x || y || OBJECT: Teleporter B
|-
|140 || 68 || x || y || HAZARD: Flashing ball projectile (Moving West)
|-
|141 || 68 || x || y || HAZARD: Flashing ball projectile (Moving East)
|-
|142 || 112 || x-3 || y || ENEMY: Cyan Spitting Plant (on left wall)
|-
|143 || 111 || x || y || ENEMY: Cyan Spitting Plant (on right wall)
|-
|144 || 113 || x || y || ENEMY: Blue Turret Alien
|-
|145 || 114 || x || y || PLAT: Hoverboard
|-
|146 || 0/138 || x || y || CRATE: pile of green balls
|-
|147 || 0/139 || x || y || CRATE: blue/yellow fruit
|-
|148 || 29/140 || x || y || BARREL: Saxophone-like thing
|-
|149 || 118 || x || y || ENEMY: Red Chomper Alien
|-
|150 || 0/137 || x || y || CRATE: Salad
|-
|151 || 60 || x || y || switch (3) (Activates lights, if actors 6,7, & 8 are present in level.)
|-
|152 || 60 || x || y || switch (4) (Deactivates Actors 153 & 154; Energy Beams)
|-
|153 || 122 || x || y || HAZARD: Vertical Energy Beam (Deactivated by Switch)
|-
|154 || 123 || x || y || HAZARD: Horizontal Energy Beam (Deactivated by Switch)
|-
|155 || 124 || x || y || ENEMY: Pink slug/Worm (Turns to bubbling goo when jumped upon)
|-
|156 || 125 || x || y || HINT GLOBE #0: "These hint globes will help you along your journey. Press the up key to reread them."
|-
|157 || 126 || x || y || ENEMY: Silver Robot (pushes player around)
|-
|158 || 127 || x || y || ENEMY: Security Robot (shoots flashing bullet, can act as moving floor spring)
|-
|159 || 128 || x || y || HAZARD: Bubbling pink goo (see type 155)
|-
|160 || 129 || x || y || PLAT/HAZARD: Dragonfly
|-
|161 || 130 || x || y || Slug Box (explodes and spawns a slug, can only be destroyed safely with bombs)
|-
|165 || 134 || x || y || BONUS: Bottle with red liquid
|-
|166 || 135 || x || y || BONUS: Green thing
|-
|167 || 136 || x || y || BONUS: Blue thing
|-
|168 || 137 || x || y || BONUS: Salad?
|-
|169 || 138 || x || y || BONUS: Pile of green balls
|-
|170 || 139 || x || y || BONUS: Blue/yellow fruit
|-
|171 || 140 || x || y || BONUS: Saxophone-like thing
|-
|172 || 141 || x || y+2 || BONUS: blue thing
|-
|173 || 29/134 || x || y || BARREL: Bottle with red liquid
|-
|174 || 143 || x || y || DECO/BONUS: Satellite (can be destroyed with bombs, spawns a hamburger)
|-
|176 || 145 || x || y || ENEMY: Green Ivy Plant
|-
|177 || 146 || x || y+2 || BONUS: 5 Yellow Grapes (800)
|-
|178 || 147 || x || y || BONUS: Headdress-like object
|-
|179 || 0/147 || x || y || CRATE: with item 178
|-
|180 || 149 || x-4 || y || EXIT: Jaws & Tongue (facing left)
|-
|181 || 150 || x || y || invisible exit marker (go right to exit)
|-
|182 || 151 || x || y || HAZARD: small flame
|-
|183 || 152 || x || y || ENEMY: Big Red Plant (spitting Blue Balls/catapult)
|-
|184 || 153 || x || y || BONUS: Red/green gem
|-
|185 || 154 || x || y || BONUS: Blue Crystal (on ground)
|-
|186 || 155 || x || y || BONUS: Red Crystal (on ground)
|-
|187 || 29/153 || x || y || BARREL: Red/Green Gem
|-
|188 || 29/154 || x || y || BARREL: Blue Crystal
|-
|189 || 29/155 || x || y || BARREL: Red Crystal
|-
|190 || 32 || x || y || BONUS: Green Tomato (floating)
|-
|191 || 34 || x || y || BONUS: Tomato (floating)
|-
|192 || 36 || x || y || BONUS: Yellow/Cyan Fruit (floating) (200)
|-
|193 || 162 || x || y || HAZARD: Clamp Trap
|-
|194 || 163 || x || y || PLAT: Blue Cube (falls down when you walk off)
|-
|195 || 164 || x || y || TRIGGER: "What's happening? Is Cosmo falling to his doom?" (ONLY IN COSMO1!)
|-
|196 || 164 || x || y || TRIGGER: "Is there no end to this pit? An what danger awaits below?!" (ONLY IN COSMO1!)
|-
|197 || 164 || x || y || TRIGGER: Win game (ONLY IN COSMO1!)
|}
198 CRATE: Root (400)
199 BONUS: Root
200 CRATE: 4 Brown Berries (400)
201 BONUS: 4 Brown Berries

203 BONUS: Potato-like vegetable
204 BARREL: Green Gem
205 BONUS: Green Gem
206 BARREL: Diamond (3200)
207 BONUS: Diamond
208 MESSAGE: Floating score effect (100)
209 MESSAGE: Floating score effect (200)
210 MESSAGE: Floating score effect (400)
211 MESSAGE: Floating score effect (800)
212 MESSAGE: Floating score effect (1600)
213 MESSAGE: Floating score effect (3200)
214 MESSAGE: Floating score effect (6400)
215 MESSAGE: Floating score effect (12800)

217 ENEMY: Alien-Eating Space Plant (Exits the current level)
218 ENEMY: Blue Bird
219 OBJECT: Rocket
220 BONUS: Invincibility Cube
221 PLAT: Destructible Pedestal 1 (14 tiles high)
222 PLAT: Destructible Pedestal 2 (20 tiles high)
223 PLAT: Destructible Pedestal 3 (26 tiles high)
224 BARREL: Diamond 2
225 BONUS: Diamond 2 (falling)
226 BARREL: Red Berry
227 BONUS: Red Berry (falling)
228 BARREL: Crystal (800)
229 BONUS: Crystal (falling)
230 BARREL: Blue Gem
231 BONUS: Blue Gem (falling)

233 DECO: Rocket Exhaust
234 EXIT: Teleporter
235 HINT: "Bump head into switch above!"
236 HINT: "The ice in this cave is very, very slippery."
237 HINT: "Use this shield for temporary invincibility."
238 HINT: "You found a secret area!!! Good Job!"
239 HINT: "In hight places look up to find bonus objects."
240 HINT: "Out of Order..."
241 HINT: "This might be a good time to save your game!"
242 HINT: "Press your up key to use the transporter."
243 HINT: "(1) FOR..."
244 BONUS: Diamond 2
245 BONUS: Red Berry
246 BONUS: Crystal
247 BONUS: Blue Gem (800)
248 PLAT: Ceiling Spring
249 BARREL: Headphones
250 BONUS: Headphones
251 BONUS: Headphones (falling)
252 OBJECT: Frozen Duke NukUm

254 BONUS: 3 Bananas (800)
255 CRATE: Alien Raisin
256 BONUS: Alien Raisin (400)

258 CRATE: Brown Pear
259 BONUS: Brown Pear

261 CRATE: Alien Chili Pepper
262 BONUS: Alien Chili Pepper (400)

264 DANGER: Flame (<-)
265 DANGER: Flame (->)
266 MESSAGE: "OUCH!" (Speech bubble)
267 HAZARD: Leaking Red acid
268 HAZARD: Dripping Red Acid
269 HINT: "(2) EXTRA..."
270 HINT: "(3) POINTS,..."
271 HINT: "(4) DESTROY..."
272 HINT: "(5) HINT..."
273 HINT: "(6) GLOBES!!!"
274 HINT: "The Clam Plants won't hurt you if their mouths are closed."+Clam Sprite
275 MESSAGE: "WHOA!" (Speech bubble)
276 MESSAGE: "UMPH!" (Speech bubble)
277 MESSAGE: "WOW! 50,000 POINTS!" (Speech bubble)
278 DECO: Big Mouth (end of E1/start of E2)
279 DECO: Normal Smoke Rising
280 DECO: Big Smoke rising
281 EXIT: Horizontal Exit Marker (Invisible)

283 BONUS: Red Crystal on ceiling
284 HINT: "Collect the STARS to advance to BONUS STAGES."
285 HINT: "Some creatures require more than one pounce to defeat!"
286 HINT: "Cosmo can climb wall's with his suction hands."+CosmoWallSprite

294 BONUS: Power Up Module (falling) (health/12800)
295 BONUS: Star (falling) (200)
296 end of episode 2 trigger?

The hint texts are the messages you get in episode 1, the other episodes have different (and less!) messages. The later hint globes probably don't work in those episodes.

== Credits ==

This file format was reverse engineered by [http://archive.shikadi.net/sites/www.geocities.com/dooknookimklassik/ Dave Bollinger]. Most of this info came from the [http://archive.shikadi.net/sites/www.geocities.com/dooknookimklassik/dn2specs.txt Duke II specs on his website], with [[User:Malvineous|Malvineous]] working out which bits to remove to read Cosmo maps. 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!)

Space Chase

2017-11-09T01:32:39Z

K1n9 Duk3: added PC speaker sound

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

'''Space Chase''' is a platformer written by Safari Software, before they were bought out by [[:Category:Epic Megagames|Epic Megagames]].

== Tools ==

{{BeginFileFormatTools|Type=game}}
{{FileFormatTool
| Name = [http://k1n9duk3.shikadi.net/files/sspextract.zip SSP extractor]
| Platform = Win32
| grp = Extract
| map = No
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [https://pckf.com/viewtopic.php?p=86016#p86016 Stormer]
| Platform = Win32
| grp = Extract
| map = No
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{EndFileFormatTools}}

== Links ==

* [http://www.mobygames.com/game/space-chase-part-one-city-under-siege MobyGames]

{{BeginGameFileList}}
{{GameFile
| Name = *.ssp
| Format = [[SSP Format]]
| KnownFormat = Yes
| Desc = Archive storing game graphics and levels
}}
{{GameFile
| Name = *.pcx
| Format = [[PCX Format]]
| KnownFormat = Yes
| Desc = Game graphics and tiles
}}
{{GameFile
| Name = *.ume *.umf
| Format = [[Space Chase Level Format]]
| KnownFormat = No
| Desc = Game levels
}}
{{GameFile
| Name = *.uma
| Format = ?
| KnownFormat = No
| Desc = Unknown
}}
{{GameFile
| Name = STORM.SSZ
| Format = [[Inverse Frequency Sound format]]
| KnownFormat = Yes
| Desc = PC speaker sound effects
}}
{{GameFile
| Name = *.xmi
| Format = [[XMI Format]]
| KnownFormat = Yes
| Desc = Background music
}}
{{EndGameFileList}}

[[Category:Epic Megagames]]
[[Category:Sidescroller]]

Space Chase

2017-11-09T01:16:01Z

K1n9 Duk3: /* Tools */ both tools are Win32 executables

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

'''Space Chase''' is a platformer written by Safari Software, before they were bought out by [[:Category:Epic Megagames|Epic Megagames]].

== Tools ==

{{BeginFileFormatTools|Type=game}}
{{FileFormatTool
| Name = [http://k1n9duk3.shikadi.net/files/sspextract.zip SSP extractor]
| Platform = Win32
| grp = Extract
| map = No
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [https://pckf.com/viewtopic.php?p=86016#p86016 Stormer]
| Platform = Win32
| grp = Extract
| map = No
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{EndFileFormatTools}}

== Links ==

* [http://www.mobygames.com/game/space-chase-part-one-city-under-siege MobyGames]

{{BeginGameFileList}}
{{GameFile
| Name = *.ssp
| Format = [[SSP Format]]
| KnownFormat = Yes
| Desc = Archive storing game graphics and levels
}}
{{GameFile
| Name = *.pcx
| Format = [[PCX Format]]
| KnownFormat = Yes
| Desc = Game graphics and tiles
}}
{{GameFile
| Name = *.ume *.umf
| Format = [[Space Chase Level Format]]
| KnownFormat = No
| Desc = Game levels
}}
{{GameFile
| Name = *.uma
| Format = ?
| KnownFormat = No
| Desc = Unknown
}}
{{GameFile
| Name = *.xmi
| Format = [[XMI Format]]
| KnownFormat = Yes
| Desc = Background music
}}
{{EndGameFileList}}

[[Category:Epic Megagames]]
[[Category:Sidescroller]]

SSP Format

2017-11-09T01:14:21Z

K1n9 Duk3: Created page with "{{Archive Infobox | MaxFiles = 200 | FAT = Beginning | Names = Yes, 8.3 | Metadata = None | Subdirectories = N | Compressed = N | Encrypted = N | Hidden = Y | Games =..."

{{Archive Infobox
| MaxFiles = 200
| FAT = Beginning
| Names = Yes, 8.3
| Metadata = None
| Subdirectories = N
| Compressed = N
| Encrypted = N
| Hidden = Y
| Games =
{{Game|Space Chase}}
}}
The '''SSP format''' is how most files in the game [[Space Chase]] by Safari Software are stored. Different versions of the game may use different versions of this format, and the earliest known demo version does not use this format at all.

Files that the game expects to find inside the SSP archive must be stored in that archive. The game does not appear to support external files as an alternative.

== File format ==

=== Signature ===

There is no known signature for this format. And to make things worse, there are at least three known versions of the SSP format. And not one of them stores a version number (or anything similar) to identify which version of the format is used.

The only thing that all (known) versions of this format have in common is that they all start with a [[UINT16LE]] that defines how many file entries are used in this file. This value is followed directly by an array of [[UINT32LE]] values that store the size of each file.

This information can be used to calculate the total size of the File Allocation Table (FAT), assuming that the SSP archive has no unused bytes at the end of the file or between the files, and also assuming that there are no overlapping files. Simply sum up the size values of all the ''used'' file entries and subtract the sum from the total size of the SSP file.

Based on the size of the FAT, you can read the actual file entries as described below.

=== FAT Structure ===

All known files in the SSP format use the following layout:

{|class="wikitable"
!Type!!Name!!Description
|-
|UINT16LE||iCount||Number of file entries used
|-
|UINT32LE[]||iSizes||Size of each sub-file
|-
|CHAR[][]||cNames||NULL-terminated name of each sub-file (fixed-length entries, usually padded with NULLs)
|-
|BYTE[]||padding1||usually NULLs
|-
|UINT32LE[]||iOffsets||Offset of each sub-file (relative to the beginning of the sub-file data!)
|-
|BYTE[]||padding2||usually NULLs
|-
||BYTE[]||data||Beginning of the sub-file data
|}

The number of file entries in each array, the length of the file names, and the length of the padding in between the blocks of data varies depending on the version of the game. Known versions of the SSP format are as follows:

{|class="wikitable"
!FAT size!!Max. Entries!!Names Start!!Name Length!!Offsets Start!!Description
|-
|9478||128||514||64||8834||used in v4.00 of Episode 1
|-
|2334||100||402||13||1802||used in v2.14D of Episode 1
|-
|4534||200||802||13||3602||used in v2.00D and v2.02D of Episode 1
|}

The FAT size is also the offset of the beginning of the sub-file data. This value needs to be added to each value in the <tt>iOffsets</tt> array to get the actual offset within the SSP file.

=== Safety Checks ===

* The number of ''used'' file entries should not exceed the maximum allowed by the current version of the SSP format. More than 200 file entries are not allowed in any known version of the format.

* Offset and Size of any ''used'' file entry should never exceed the size of the SSP file minus the FAT size.

While the following is true for all known archives that shipped with the games, these restrictions are not part of the file format per se. The the game will most likely still be able to read these files even if the following conditions are not met.

* The data for the sub-files is usually stored in the same order as the entries in the FAT, so all used entries in the <tt>iOffsets</tt> array should be in ascending order.

* Unused entries, as well as the padding between the blocks, are usually set to NULLs.

* File names should fit the 8.3 naming scheme.

== Tools ==

{{BeginFileFormatTools|Type=game}}
{{FileFormatTool
| Name = [http://k1n9duk3.shikadi.net/files/sspextract.zip SSP extractor]
| Platform = Win32
| grp = Extract
| map = No
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [https://pckf.com/viewtopic.php?p=86016#p86016 Stormer]
| Platform = Win32
| grp = Extract
| map = No
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{EndFileFormatTools}}