ModdingWiki - User contributions [en-gb]

EGAGraph Format

2014-03-02T01:35:11Z

Lemm: /* Misc graphics */ typo

{{Stub}}

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

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

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

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

= File formats =

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

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

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

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

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

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

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

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

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

== Dictionary (EGADICT.xxx) ==

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

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

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

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

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

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

== Main file (EGAGRAPH.xxx) ==

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

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

=== Chunks ===

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

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

== Chunk formats ==

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

=== Picture table ===

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

Divide the decompressed size by 4 to get numpics.

=== Masked picture table ===

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

=== Sprite table ===

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

=== Fonts ===

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

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

=== Pictures (Bitmaps) ===
These follow game fonts. You need to know how many fonts there are before it to know how what chunk number the first picture is (3+NumFonts). In [[Catacomb 3D]] there are 2 fonts.

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

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

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

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

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

These are identical to the picture chunks in every respect, except being masked, they consist of five EGA planes, not four. Some games (E.g [[Catacomb 3D]] make great use of masked pictures, but most games have only one or two. They need information from chunk 1, the masked picture table, to be displayed correctly.

The number of Masked pictures is given in Chunk 1.

=== Sprites ===

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

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

There are usually several hundred sprite chunks, but [[Catacomb 3D]] only has 3 sprite chunks and they are used for the PaddleWar game (Skulls and Bones). The number of sprite chunks is given in chunk 2.

=== 8x8 tiles ===

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

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

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

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

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

=== Misc graphics ===

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

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

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

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

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

=== Game texts ===

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

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

=== Misc files ===

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

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

[[Category:Catacomb 3D]]
[[Category:Catacomb Abyss]]
[[Category:Commander Keen 4-6]]
[[Category:Commander Keen Dreams]]
[[Category:Dangerous Dave 3]]
[[Category:File Formats]]
[[Category:Graphics Files]]

Talk:Monster Bash Sprite Format

2013-11-01T14:47:38Z

Lemm: Arg, typos and unfinished sentences! Sorry; I'm tired.

== Image Format Flags Field ==

After doing some more analysis of the .exe, I can find two functions responsible for drawing sprites. The first draws the "white flashed" sprites by copying the transparency mask to all four graphics planes. The second function, which draws the normal sprites, first applies the mask, and then sets the map mask register based upon the value in the planebit field.

The lower four bytes of the UInt8 "iFlags" field in the image header appear to control the number of shifts. The high-four bytes (particularly bit 6, 0x40) appear to radically alter the manner in which the sprite is drawn. I haven't finished analyzing it yet, but it looks like the "big" sprites have bit 6 set, because the width-optimized drawing code doesn't handle cases larger than 64 pixels wide (8 bytes wide).

For sprites that don't have 0x40 set (which appears to be the majority of them in Monster Bash), then the low bit indicates whether or not the sprite has multiple "shifted" source copies or if the sprite is shifted as it is drawn. If the low bit is not set, then the flags value is either 2, 4, or 8, and this is the number of shifted copies found in memory. In Monster Bash, this only appears to apply to the "rock," which has an iFlags of 0x8, indicating 8 shifts. If the low bit is set, then the flags value is 1, meaning that there is only one copy of the sprite in memory, and it is shifted as it is drawn, allowing big sprites, which would take up too much memory if they were pre-shifted, to be drawn smoothly.

'''At least for the transparency plane, the function of the planeBits only seems to be to indicate the width of the sprite.''' This is evident in the following line of code:

http://pastebin.com/guLjzx5K

We are looking at the start of the function that draws the white-flashed-sprites. You can see that, at E8DF, where we deal with non-0x40-masked sprites, the planebit is loaded into al and then exchanged into bl in the subsequent instruction. At E90A and E911, the game jumps to width-optimized drawing instructions based upon the value of bx. (One jump table is for sprites that are drawn starting at byte-boundaries, which includes pre-shifted sprites and non-shifted sprites that are lucky 1/8th of the time, while the other jump table is for sprites that are drawn off byte-boundaries).

Now looking at how Camoto messes up sprite import:

Here are the first 16 bytes of main_r as analyzed by Wombat. I'm comparing an unmodified DAT file, and one that has been modified by exporting and then importing main_r as a .PNG.

<code>
Unmodified: . FF6A 0201 2818 00F7 FFFF FF0C 0027 0003 
Modified: ... FF6A 0201 2818 00F7 FFFF FF0C 0027 0001 
</code>

You can see that byte 0xF, which is the "plane-bits" of the transparency plane belonging to the frame with Johnny standing to the right, equals 3, meaning that the sprite is three bytes wide. Camoto changes this to 1, for whatever reason. The game draws the sprite as an 8-pixel wide strip of garble, because it thinks that the sprite is 8 pixels wide.

Now in addition to all of that, take a look at E8D9. For sprites that have multiple shifts, there must be an array of word-length offsets that follows the standard 12-byte header, because SI is set based upon which shift is to be drawn. (In this case, the shift number is stored in BX and ES:SI points to the graphics source in conventional memory when drawing commences.) This means that any sprite frame with a flags value of 0x2,0x4,0x8, or 0x42, 0x44, or 0x48 should have an array of words, equal in size to the number of shifts, that slips in between the 12-byte header and the start of the graphics plane.
[[User:Lemm|Lemm]] ([[User talk:Lemm|talk]]) 14:32, 1 November 2013 (GMT)

Talk:Monster Bash Sprite Format

2013-11-01T14:36:34Z

Lemm: /* Image Format Flags Field */

== Image Format Flags Field ==

After doing some more analysis of the .exe, I can find two functions responsible for drawing sprites. The first draws the "white flashed" sprites by copying the transparency mask to all four graphics planes. The second function, which draws the normal sprites, first applies the mask, and then

The lower four bytes of the UInt8 "iFlags" field in the image header appear to control the number of shifts. The high-four bytes (particularly bit 6, 0x40) appear to radically alter the manner in which the sprite is drawn. I haven't finished analyzing it yet, but it looks like the "big" sprites have bit 6 set, because the width-optimized drawing code doesn't handle cases larger than 64 pixels wide (8 bytes wide).

For sprites that don't have 0x40 set (which appears to be the majority of them in Monster Bash), then the low bit indicates whether or not the sprite has multiple "shifted" source copies or if the sprite is shifted as it is drawn. If the low bit is not set, then the flags value is either 2, 4, or 8, and this is the number of shifted copies found in memory. In Monster Bash, this only appears to apply to the "rock," which has an iFlags of 0x8, indicating 8 shifts. If the low bit is set, then the flags value is 1, meaning that there is only one copy of the sprite in memory, and it is shifted as it is drawn, allowing big sprites, which would take up too much memory if they were pre-shifted, to be drawn smoothly.

'''At least for the transparency plane, the function of the planeBits only seems to be to indicate the width of the sprite.''' This is evident in the following line of code:

http://pastebin.com/guLjzx5K

We are looking at the start of the function that draws the white-flashed-sprites. You can see that, at E8DF, where we deal with non-0x40-masked sprites, the planebit is loaded into al and then exchanged into bl in the subsequent instruction. At E90A and E911, the game jumps to width-optimized drawing instructions based upon the value of bx. (One jump table is for sprites that are drawn starting at byte-boundaries, which includes pre-shifted sprites and non-shifted sprites that are lucky 1/8th of the time, while the other jump table is for sprites that are drawn off byte-boundaries).

Now looking at how Camoto messes up sprite import:

Here are the first 16 bytes of main_r as analyzed by Wombat. I'm comparing an unmodified DAT file, and one that has been modified by exporting and then importing main_r as a .PNG.

<code>
Unmodified: . FF6A 0201 2818 00F7 FFFF FF0C 0027 0003 
Modified: ... FF6A 0201 2818 00F7 FFFF FF0C 0027 0001 
</code>

You can see that byte 0xF, which is the "plane-bits" of the frame with Johnny standing to the right, equals 3, meaning that the sprite is three bytes wide. Camoto changes this to 1, for whatever reason. The game draws the sprite as an 8-pixel wide strip of garble, because it thinks that the sprite is 8 pixels wide.

Now in addition to all of that, take a look at E8D9. For sprites that have multiple shifts, there must be an array of word-length offsets that follows the standard 12-byte header, because SI is set based upon which shift is to be drawn. (In this case, the shift number is stored in BX and ES:SI points to the graphics source in conventional memory when drawing commences.) This means that any sprite frame with a flags value of 0x2,0x4,0x8, or 0x42, 0x44, or 0x48 should have an array of words, equal in size to the number of shifts, that slips in between the 12-byte header and the start of the graphics plane.
[[User:Lemm|Lemm]] ([[User talk:Lemm|talk]]) 14:32, 1 November 2013 (GMT)

Talk:Monster Bash Sprite Format

2013-11-01T14:32:16Z

Lemm: Sprite Planebits and why Camoto might be messing up.

== Image Format Flags Field ==

After doing some more analysis of the .exe, I can find two functions responsible for drawing sprites. The first draws the "white flashed" sprites by copying the transparency mask to all four graphics planes. The second function, which draws the normal sprites, first applies the mask, and then

The lower four bytes of the UInt8 "iFlags" field in the image header appear to control the number of shifts. The high-four bytes (particularly bit 6, 0x40) appear to radically alter the manner in which the sprite is drawn. I haven't finished analyzing it yet, but it looks like the "big" sprites have bit 6 set, because the width-optimized drawing code doesn't handle cases larger than 64 pixels wide (8 bytes wide).

For sprites that don't have 0x40 set (which appears to be the majority of them in Monster Bash), then the low bit indicates whether or not the sprite has multiple "shifted" source copies or if the sprite is shifted as it is drawn. If the low bit is not set, then the flags value is either 2, 4, or 8, and this is the number of shifted copies found in memory. In Monster Bash, this only appears to apply to the "rock," which has an iFlags of 0x8, indicating 8 shifts. If the low bit is set, then the flags value is 1, meaning that there is only one copy of the sprite in memory, and it is shifted as it is drawn, allowing big sprites, which would take up too much memory if they were pre-shifted, to be drawn smoothly.

'''At least for the transparency plane, the function of the planeBits only seems to be to indicate the width of the sprite.''' This is evident in the following line of code:

http://pastebin.com/guLjzx5K

We are looking at the start of the function that draws the white-flashed-sprites. You can see that, at E8DF, where we deal with non-0x40-masked sprites, the planebit is loaded into al and then exchanged into bl in the subsequent instruction. At E90A and E911, the game jumps to width-optimized drawing instructions based upon the value of bx. (One jump table is for sprites that are drawn starting at byte-boundaries, which includes pre-shifted sprites and non-shifted sprites that are lucky 1/8th of the time, while the other jump table is for sprites that are drawn off byte-boundaries).

Now looking at how Camoto messes up sprite import:

Here are the first 16 bytes of main_r as analyzed by Wombat. I'm comparing an unmodified DAT file, and one that has been modified by exporting and then importing main_r as a .PNG.

<code>
Unmodified: . FF6A 0201 2818 00F7 FFFF FF0C 0027 0003 
Modified: ... FF6A 0201 2818 00F7 FFFF FF0C 0027 0001 
</code>

You can see that byte 0xF, which is the "plane-bits" of the frame with Johnny standing to the right, equals 3, meaning that the sprite is three bytes wide. Camoto changes this to 1, for whatever reason. The game draws the sprite as an 8-pixel wide strip of garble, because it thinks that the sprite is 8 pixels wide.

Now in addition to all of that, take a look at E8D9. For sprites that have multiple shifts, there must be an array of word-length offsets that follows the standard 12-byte header, because SI is set based upon which shift is to be drawn. (In this case, the shift number is stored in BX and ES:SI points to the graphics source in conventional memory when drawing commences.) This means that any sprite frame with a mask-plane planebits value of 0x2,0x4,0x8, or 0x42, 0x44, or 0x48 should have an array of words, equal in size to the number of shifts, that slips in between the 12-byte header and the start of the graphics plane.
[[User:Lemm|Lemm]] ([[User talk:Lemm|talk]]) 14:32, 1 November 2013 (GMT)

Talk:DAT Format (Monster Bash)

2013-11-01T03:34:34Z

Lemm: /* Unused enemy in MB1 */

== LZW compression ==

Does anyone have another implementation of the deLZW code? I tried porting the code from Gerald Lindsly's homepage to another programming language and I encountered some problems. I think they are related to those awful word-pointer to byte-pointer to word-pointer casts, but I'm not 100% sure. --[[User:K1n9 Duk3|K1n9 Duk3]] 08:24, 10 March 2011 (GMT)

:You could take a look at the [https://github.com/Malvineous/libgamecommon/blob/master/src/lzw.cpp version I used for Camoto] (decompress only) which is extended from [http://warp.povusers.org/EfficientLZW/ EfficientLZW] to work with a couple of games including Monster Bash. This code doesn't use pointers but is less efficient as it uses what are effectively resizable arrays. The Lindsly deLZW code includes the RLE expansion so if you use standard LZW code you'll need to perform the RLE decoding separately. LZW is pretty common so you can probably find an existing implementation in your language of choice. -- [[User:Malvineous|Malvineous]] 11:35, 10 March 2011 (GMT)

::I got my ported code to work (used the wrong operator precedence somewhere), but thanks anyway. --[[User:K1n9 Duk3|K1n9 Duk3]] 15:55, 10 March 2011 (GMT)

== Unused enemy in MB1 ==

It seems that there is code in the Episode 1 .exe for the electrical spark enemy from Episode 2. The six frames that exist between the spear plat and the snake can be used for this enemy. Both the horizontal and vertical versions exist. SparkV occupies the first three frames, while Spark occupies the second triplet. They have enemy type codes of 0x3F and 0x3E, respectively.
[[User:Lemm|Lemm]] ([[User talk:Lemm|talk]]) 08:49, 30 October 2013 (GMT)

: What do you mean "the frames between the spear plat and the snake"? And where are the enemy type codes used? In a level you can place a spear_plat sprite and/or a snake sprite, but they are referenced by name only, as far as I can tell. -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 10:02, 31 October 2013 (GMT)

:: I mean that there are two sprites, named "spark" and "sparkv", each of which contains three frames. Based upon the disassembly, the data for these sprites *should* have been entered, in the DAT file, after the spear_plat and before the snake, but no spark data was included. However, you should be able to place a 3-frame "spark" and a "sparkv" sprite in a level, just as you would any other sprite. [[User:Lemm|Lemm]] ([[User talk:Lemm|talk]]) 03:34, 1 November 2013 (GMT)

Talk:DAT Format (Monster Bash)

2013-10-30T08:49:27Z

Lemm: Unused Enemy in MB1

Talk:Monster Bash

2013-10-25T06:46:35Z

Lemm: Formatting

== Patching Actor and Sprite Structures in the Executable ==

Animation and actor behaviours in Monster Bash are governed by 10-byte action structures, similar to those found in Commander keen Galaxy, but much simpler.

typedef struct action {
void _seg ***left_sprite, _seg ***right_sprite;
uint16_t time;
int (*think)(actor *);
struct action *next;
} action_t;

Actions exist in the data segment, and all pointers are 16 bits. In the data segment, Monster bash stores sprite information in linked list of variable-sized nodes. Each node has the sprite name, a null-terminated list of segment pointers that store the value of the segment where the raw EGA graphics data is for that sprite, an ASCII string with the name of the graphic, and two 16-bit signed integers of unknown function (possibly the sprite "hotspot" x and y coordinates). There is a second array of near pointers in the data segment, with one entry for each sprite that points to the segment pointer in the linked list. If the sprite is cached, then this value is set, otherwise it is null. Finally, the 16-bit left_sprite and right_sprite pointers point to their respective entry in this second array. Thus, the value in the action structure is a near pointer to a near pointer to a segment pointer!

The other fields are much simpler to understand.

* <code>time</code> is the length of animation in x'ths of a second.
* <code>think</code> is the actor behaviour function that is in use for this animation frame
* <code>next</code> is the action structure that the sprite uses when the action timer expires

There is a second array of 6-byte structs that hold animation information for each "group" of frames.

typedef struct {
void _seg ***first_sprite; // same as the action_t field, references first sprite in spritegroup
char *groupname;
int num_frames;
} spritegroup_t;

For whatever reason, the .exe has the names of the spritegroups stored in the data segment.

=== Diving into the .exe to figure out which action belongs to which sprite ===

As an example, I am using the Registered version 2.1 of the first episode. Say we want to find the actions for the green hand. I am using IDA Free v 5.0 to disassemble the .exe (which has been unpacked by UNP.EXE v 4.11. At dseg:3FBC, we find the array of spritegroups. We scroll down until we find the spritegroup that corresponds to the hand.

dseg:4250 spritegroup <offset off_244C2, offset aHand_l, 6> ; "hand_l"
dseg:4256 spritegroup <offset off_244B6, offset aHand_r, 6> ; "hand_r"

Actually, there are two spritegroups for the hand, one for each direction. We see that that left hand sprites start at off_244C2 in the .exe image. Therefore, we want to look for action structures that have off_244C2 in their left_sprite field. One such struct exists at dseg:2DAE. Because all of the hand actions are located next to each other, and all of the right handed values must be between off_244B6 and off_244C0, we can identify which actions belong to the hand.

We know that the first four hand frames are for the walking loop, which would be actions with off_244C2 through off_244C8. The remaining actions likely have to do with the jump sequence, and we can make guesses as to what each action is for based upon the frame field content.

dseg:2DAE ac_hand_walk_0 action <offset off_244C2, offset off_244B6, 50, offset think, \
dseg:2DAE ; DATA XREF: dseg:ac_hand_walk_3�o
dseg:2DAE offset ac_hand_walk_1>
dseg:2DB8 ac_hand_walk_1 action <offset off_244C4, offset off_244B8, 50, offset think, \
dseg:2DB8 ; DATA XREF: dseg:ac_hand_walk_0�o
dseg:2DB8 offset ac_hand_walk_2>
dseg:2DC2 ac_hand_walk_2 action <offset off_244C6, offset off_244BA, 50, offset think, \
dseg:2DC2 ; DATA XREF: dseg:ac_hand_walk_1�o
dseg:2DC2 offset ac_hand_walk_3>
dseg:2DCC ac_hand_walk_3 action <offset off_244C8, offset off_244BC, 50, offset think, \
dseg:2DCC ; DATA XREF: dseg:ac_hand_walk_2�o
dseg:2DCC offset ac_hand_walk_0>
dseg:2DD6 ac_hand_curl_0 action <offset off_244CC, offset off_244C0, 350, offset think_21, \
dseg:2DD6 ; DATA XREF: sub_3931+E2�o
dseg:2DD6 offset ac_hand_curl_1>
dseg:2DE0 ac_hand_curl_1 action <offset off_244CC, offset off_244C0, 0, offset think_83, \
dseg:2DE0 ; DATA XREF: dseg:ac_hand_curl_0�o
dseg:2DE0 offset ac_hand_fly_0>
dseg:2DEA ac_hand_fly_0 action <offset off_244CA, offset off_244BE, 50, offset think_31, \
dseg:2DEA ; DATA XREF: dseg:ac_hand_curl_1�o
dseg:2DEA ; dseg:ac_hand_fly_0�o
dseg:2DEA offset ac_hand_fly_0>
dseg:2DF4 ac_hand_fly_1 action <offset off_244CA, offset off_244BE, 50, offset think_32, \
dseg:2DF4 ; DATA XREF: sub_3931+E7�o
dseg:2DF4 ; dseg:ac_hand_fly_1�o
dseg:2DF4 offset ac_hand_fly_1>
dseg:2DFE ac_hand_fly_2 action <offset off_244C2, offset off_244B6, 300, offset think_31, \
dseg:2DFE ; DATA XREF: dseg:ac_hand_fly_2�o
dseg:2DFE offset ac_hand_fly_2>
dseg:2E08 ac_hand_land_0 action <offset off_244CC, offset off_244C0, 50, offset think_32, \
dseg:2E08 ; DATA XREF: dseg:ac_hand_land_0�o
dseg:2E08 offset ac_hand_land_0>

Finally, it is of use to look at the think functions. These thinks may be used by multiple actors, but some may be specific to one actor.

=== How would this be used for modding? ===

First of all, a modding program would have to output a patch file to update the spritegroup array. MBPATCH can use the %patchfile command to patch a binary file generated by the modding program at the appropriate offset (e.g., dseg:2DAE in Monster Bash 1). As for the modder himself, he would be interested in modifying the action structures. Sprites, animation timing and loops, and behaviours can all be changed.

Talk:Monster Bash

2013-10-25T06:44:54Z

Lemm: Graphics Disassembly Info

Animation and actor behaviours in Monster Bash are governed by 10-byte action structures, similar to those found in Commander keen Galaxy, but much simpler.

typedef struct action {
void _seg ***left_sprite, _seg ***right_sprite;
uint16_t time;
int (*think)(actor *);
struct action *next;
} action_t;

Actions exist in the data segment, and all pointers are 16 bits. In the data segment, Monster bash stores sprite information in linked list of variable-sized nodes. Each node has the sprite name, a null-terminated list of segment pointers that store the value of the segment where the raw EGA graphics data is for that sprite, an ASCII string with the name of the graphic, and two 16-bit signed integers of unknown function (possibly the sprite "hotspot" x and y coordinates). There is a second array of near pointers in the data segment, with one entry for each sprite that points to the segment pointer in the linked list. If the sprite is cached, then this value is set, otherwise it is null. Finally, the 16-bit left_sprite and right_sprite pointers point to their respective entry in this second array. Thus, the value in the action structure is a near pointer to a near pointer to a segment pointer!

The other fields are much simpler to understand.

* <code>time</code> is the length of animation in x'ths of a second.
* <code>think</code> is the actor behaviour function that is in use for this animation frame
* <code>next</code> is the action structure that the sprite uses when the action timer expires

There is a second array of 6-byte structs that hold animation information for each "group" of frames.

typedef struct {
void _seg ***first_sprite; // same as the action_t field, references first sprite in spritegroup
char *groupname;
int num_frames;
} spritegroup_t;

For whatever reason, the .exe has the names of the spritegroups stored in the data segment.

*** Diving into the .exe to figure out which action belongs to which sprite ***

As an example, I am using the Registered version 2.1 of the first episode. Say we want to find the actions for the green hand. I am using IDA Free v 5.0 to disassemble the .exe (which has been unpacked by UNP.EXE v 4.11. At dseg:3FBC, we find the array of spritegroups. We scroll down until we find the spritegroup that corresponds to the hand.

dseg:4250 spritegroup <offset off_244C2, offset aHand_l, 6> ; "hand_l"
dseg:4256 spritegroup <offset off_244B6, offset aHand_r, 6> ; "hand_r"

Actually, there are two spritegroups for the hand, one for each direction. We see that that left hand sprites start at off_244C2 in the .exe image. Therefore, we want to look for action structures that have off_244C2 in their left_sprite field. One such struct exists at dseg:2DAE. Because all of the hand actions are located next to each other, and all of the right handed values must be between off_244B6 and off_244C0, we can identify which actions belong to the hand.

We know that the first four hand frames are for the walking loop, which would be actions with off_244C2 through off_244C8. The remaining actions likely have to do with the jump sequence, and we can make guesses as to what each action is for based upon the frame field content.

dseg:2DAE ac_hand_walk_0 action <offset off_244C2, offset off_244B6, 50, offset think, \
dseg:2DAE ; DATA XREF: dseg:ac_hand_walk_3�o
dseg:2DAE offset ac_hand_walk_1>
dseg:2DB8 ac_hand_walk_1 action <offset off_244C4, offset off_244B8, 50, offset think, \
dseg:2DB8 ; DATA XREF: dseg:ac_hand_walk_0�o
dseg:2DB8 offset ac_hand_walk_2>
dseg:2DC2 ac_hand_walk_2 action <offset off_244C6, offset off_244BA, 50, offset think, \
dseg:2DC2 ; DATA XREF: dseg:ac_hand_walk_1�o
dseg:2DC2 offset ac_hand_walk_3>
dseg:2DCC ac_hand_walk_3 action <offset off_244C8, offset off_244BC, 50, offset think, \
dseg:2DCC ; DATA XREF: dseg:ac_hand_walk_2�o
dseg:2DCC offset ac_hand_walk_0>
dseg:2DD6 ac_hand_curl_0 action <offset off_244CC, offset off_244C0, 350, offset think_21, \
dseg:2DD6 ; DATA XREF: sub_3931+E2�o
dseg:2DD6 offset ac_hand_curl_1>
dseg:2DE0 ac_hand_curl_1 action <offset off_244CC, offset off_244C0, 0, offset think_83, \
dseg:2DE0 ; DATA XREF: dseg:ac_hand_curl_0�o
dseg:2DE0 offset ac_hand_fly_0>
dseg:2DEA ac_hand_fly_0 action <offset off_244CA, offset off_244BE, 50, offset think_31, \
dseg:2DEA ; DATA XREF: dseg:ac_hand_curl_1�o
dseg:2DEA ; dseg:ac_hand_fly_0�o
dseg:2DEA offset ac_hand_fly_0>
dseg:2DF4 ac_hand_fly_1 action <offset off_244CA, offset off_244BE, 50, offset think_32, \
dseg:2DF4 ; DATA XREF: sub_3931+E7�o
dseg:2DF4 ; dseg:ac_hand_fly_1�o
dseg:2DF4 offset ac_hand_fly_1>
dseg:2DFE ac_hand_fly_2 action <offset off_244C2, offset off_244B6, 300, offset think_31, \
dseg:2DFE ; DATA XREF: dseg:ac_hand_fly_2�o
dseg:2DFE offset ac_hand_fly_2>
dseg:2E08 ac_hand_land_0 action <offset off_244CC, offset off_244C0, 50, offset think_32, \
dseg:2E08 ; DATA XREF: dseg:ac_hand_land_0�o
dseg:2E08 offset ac_hand_land_0>

Finally, it is of use to look at the think functions. These thinks may be used by multiple actors, but some may be specific to one actor.

=== How would this be used for modding? ===

First of all, a modding program would have to output a patch file to update the spritegroup array. MBPATCH can use the %patchfile command to patch a binary file generated by the modding program at the appropriate offset (e.g., dseg:2DAE in Monster Bash 1). As for the modder himself, he would be interested in modifying the action structures. Sprites, animation timing and loops, and behaviours can all be changed.

B800 Text

2013-01-05T19:13:09Z

Lemm: /* See also */

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

== File format ==

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

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

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

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

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

== Example ==

As a demonstration, these bytes:

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

Would appear like this:

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

== Tools ==

The following tools are known to work with this format:

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

== See also ==

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

[[Category:File Formats]]
[[Category:Graphics Files]]


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

Crystal Caves Map Format

2011-06-19T03:05:31Z

Lemm: map height

{{NeedMoreInfo}}

The ''Crystal Caves Map Format'' describes a particular section of data within the main [[Crystal Caves]] executable file, where the game levels are stored. Each level is 40 tiles wide and a varying number of tiles high.

== Location ==

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

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

The number of rows for each map is hard-coded into the executable as machine instructions, not as an array of heights for each level. Practically, this makes it very hard to increase a level's height. It is believed that all levels are 24 rows high, with the following exceptions:

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

== Format ==

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

=== Map codes ===

There is currently no known formula to convert map codes into tileset indices. Maps use byte 0x20 for 'no tile' (drawn with some background image), which maps to different images depending on the area within the level, so there must be some other data controlling which background tiles to use in which areas.

==== BlitzMax Code ====

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

<pre>
'Crystal Caves Map Viewer
'by K1n9_Duk3

SuperStrict

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

Local MaxY:Int

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

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

MaxY = y
Forever
CloseFile(in)
Else
End
EndIf

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

SetClsColor(128, 128, 128)

Local CamY:Int
Local Textmode:Byte

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

Select MapTile

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

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

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

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

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

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

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

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

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

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

== Credits ==

The location of the map data was discovered by [[User:Lemm|Lemm]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

[[Category:Crystal Caves]]
[[Category:Map Files]]

Talk:Crystal Caves

2011-06-18T12:23:56Z

Lemm: there i go again, forgetting to sign things

No modding tools exist for Crystal Caves, correct?

Also, it appears that the levels are located in the UNP'd executable starting at seg000:7332 (or $8C30 in the UNP'd exe). I believe tiles are stored as byte values, in pascal strings. Each row of tiles is 40 long, so there is an array of strings of length 41. Also, just looking at the ASCII representation of the hex values, you can clearly see the outline of the main level. Therefore, this should be easily patchable using a CKPATCH like utility.

(2222222222222222222222222222222222222222
(
( Y ÛÜ
( [A
( nn
(Dddddddddddddddddddddddddddddddddddddddn
( ÛÜ
( Y
( [5
( [B
( nn
(z mN z
(z z
(z un z
(z Y Žn z
(zZZZZZZZ[mZZZZZZZZZZZZZZZZZZnnnZZZZZZZz
(lklklklklklklklklkKlkLKlkLKlkLKlkLKk kLk
(k Õ Õ Õ [d L
(l x x ±±±±± l
(LÕ ±±± H ±±±±±±±±±±±±±±±±± ðn ² k
(K ² ðn x ðn ú ³nx²Æk
(kù ±±± [d ³n ±±±± Õ ³n ±±±±±±± L
(lú ² Õ ³n ðn ³n ðn ² l
(Lùù x²x ³n ³n ù ³n ú ³nx² k
(k±±±±±±±±±±±±±±±±±±±±±± ³n ùùú ³n±±VK
(l ðnÕ Õðn ²Õ ±±±±±±±±±±±± k
(kx ³n ³n x² x ² ðn ðn l
(K±±±±± ±±±±±±± ±±±±±±±±²x ³n ³n K
(k ðnÕ Õðn ² ðn Õ ±±±±±±±±±±±± k
(Lx ³n ³n x²x ù ³n x² K
(l±±±±± V ±±±±±±±±±±±±±±±±±±±±±±±±±±±±± k
(k ðn [4n ðn ðn L
(Kx ³n Õ Õ ³n Õ ³n Õ L
(kK ³n ³n ³n k
(lKkLkKklKLklKLKkKlkLKlkLKlkLKlkLKlkLKlkl
(1111111111111111111111111111111111111111

[[User:Lemm|Lemm]] 13:31, 9 December 2009 (GMT)

Nifty. There are a handful of graphics editors for it, but nothing else. This should help with level editing muchly. -- [[User:Draik|Draik]] 05:33, 10 December 2009 (GMT)

:How many versions of Crystal Caves are there? In my unlzexe'd version the level data starts at 0x8CE0 instead. The levels seem to be of varying height though - the map is 36 rows high, most of the levels are 24 rows high but either e1l6 or e1l7 seems to be only 23 rows high. Maybe there's an array somewhere with all the level heights? -- [[User:Malvineous|Malvineous]] 13:25, 9 July 2010 (GMT)

:: Here are my guesstimations based on the look of each level. Map is 36 tiles high, levels 7, 8 and 14 are 23 tiles high, and the rest are 24 tiles high. -- [[User:Malvineous|Malvineous]] 13:43, 9 July 2010 (GMT)

:::Be aware that UNP and Unlzexe don't create the same output on the same input! [[User:Calvero|Calvero]] 11:48, 10 July 2010 (GMT)

:::: Yes that's true, but I'm not sure if there's a way around that either. I believe it's the segment offsets that are different, so perhaps there's a list of these segment offsets in the .exe header that could be used? I wonder whether it's possible to take advantage of this to manually relocate or resize a segment, in order to fit more data in it? Because at the moment the levels could only be edited in-place, there's no way to adjust the level size. -- [[User:Malvineous|Malvineous]] 12:01, 10 July 2010 (GMT)

:: Hehe. There appears to be a setup_level function in the executable (CC1: seg000:B1A9) that takes the level number as an argument. A large switch/case statement loads each row of tiles individually as a string, with each case representing a different level. There appears to be level -2, -1, 0, and 1 to 16 (these are the acceptable cases). The strings are loaded by calling load_map_row (row_number, string*) for EACH string, meaning that the map height is actually encoded in the .exe based on however many calls to the load_map_row function are made. [[User:Lemm|Lemm]] 12:23, 18 June 2011 (GMT)

== Map rendering ==

If anyone has any ideas how to figure out which tile to draw at which map location, do share. I can't see any sort of pattern between map values and an index into the tileset, and randomly changing values in the map yields some very strange results for some values! -- [[User:Malvineous|Malvineous]] 12:17, 19 May 2011 (GMT)

: I think I've found the MacDaddy function that responds to every tile value. The load_map_row function (seg000:25F0) that I mentioned above contains what appears to be a monster switch case statement for all the possible tile values, and possible other tile combinations. The function itself is 0x48F0 (18.6 kB) of mnemonics. Have fun with that one. [[User:Lemm|Lemm]] 12:23, 18 June 2011 (GMT)

== Graphics editors ==

They can be found over at http://spikenexus.toxicsheep.com/pccw/pages/index.php?page=downloads

Talk:Crystal Caves

2011-06-18T12:18:12Z

Lemm: .exe functions (should move this entire discussion to CC map format)

No modding tools exist for Crystal Caves, correct?

Also, it appears that the levels are located in the UNP'd executable starting at seg000:7332 (or $8C30 in the UNP'd exe). I believe tiles are stored as byte values, in pascal strings. Each row of tiles is 40 long, so there is an array of strings of length 41. Also, just looking at the ASCII representation of the hex values, you can clearly see the outline of the main level. Therefore, this should be easily patchable using a CKPATCH like utility.

(2222222222222222222222222222222222222222
(
( Y ÛÜ
( [A
( nn
(Dddddddddddddddddddddddddddddddddddddddn
( ÛÜ
( Y
( [5
( [B
( nn
(z mN z
(z z
(z un z
(z Y Žn z
(zZZZZZZZ[mZZZZZZZZZZZZZZZZZZnnnZZZZZZZz
(lklklklklklklklklkKlkLKlkLKlkLKlkLKk kLk
(k Õ Õ Õ [d L
(l x x ±±±±± l
(LÕ ±±± H ±±±±±±±±±±±±±±±±± ðn ² k
(K ² ðn x ðn ú ³nx²Æk
(kù ±±± [d ³n ±±±± Õ ³n ±±±±±±± L
(lú ² Õ ³n ðn ³n ðn ² l
(Lùù x²x ³n ³n ù ³n ú ³nx² k
(k±±±±±±±±±±±±±±±±±±±±±± ³n ùùú ³n±±VK
(l ðnÕ Õðn ²Õ ±±±±±±±±±±±± k
(kx ³n ³n x² x ² ðn ðn l
(K±±±±± ±±±±±±± ±±±±±±±±²x ³n ³n K
(k ðnÕ Õðn ² ðn Õ ±±±±±±±±±±±± k
(Lx ³n ³n x²x ù ³n x² K
(l±±±±± V ±±±±±±±±±±±±±±±±±±±±±±±±±±±±± k
(k ðn [4n ðn ðn L
(Kx ³n Õ Õ ³n Õ ³n Õ L
(kK ³n ³n ³n k
(lKkLkKklKLklKLKkKlkLKlkLKlkLKlkLKlkLKlkl
(1111111111111111111111111111111111111111

[[User:Lemm|Lemm]] 13:31, 9 December 2009 (GMT)

Nifty. There are a handful of graphics editors for it, but nothing else. This should help with level editing muchly. -- [[User:Draik|Draik]] 05:33, 10 December 2009 (GMT)

:How many versions of Crystal Caves are there? In my unlzexe'd version the level data starts at 0x8CE0 instead. The levels seem to be of varying height though - the map is 36 rows high, most of the levels are 24 rows high but either e1l6 or e1l7 seems to be only 23 rows high. Maybe there's an array somewhere with all the level heights? -- [[User:Malvineous|Malvineous]] 13:25, 9 July 2010 (GMT)

:: Here are my guesstimations based on the look of each level. Map is 36 tiles high, levels 7, 8 and 14 are 23 tiles high, and the rest are 24 tiles high. -- [[User:Malvineous|Malvineous]] 13:43, 9 July 2010 (GMT)

:::Be aware that UNP and Unlzexe don't create the same output on the same input! [[User:Calvero|Calvero]] 11:48, 10 July 2010 (GMT)

:::: Yes that's true, but I'm not sure if there's a way around that either. I believe it's the segment offsets that are different, so perhaps there's a list of these segment offsets in the .exe header that could be used? I wonder whether it's possible to take advantage of this to manually relocate or resize a segment, in order to fit more data in it? Because at the moment the levels could only be edited in-place, there's no way to adjust the level size. -- [[User:Malvineous|Malvineous]] 12:01, 10 July 2010 (GMT)

:: Hehe. There appears to be a setup_level function in the executable (CC1: seg000:B1A9) that takes the level number as an argument. A large switch/case statement loads each row of tiles individually as a string, with each case representing a different level. There appears to be level -2, -1, 0, and 1 to 16 (these are the acceptable cases). The strings are loaded by calling load_map_row (row_number, string*) for EACH string, meaning that the map height is actually encoded in the .exe based on however many calls to the load_map_row function are made.

== Map rendering ==

If anyone has any ideas how to figure out which tile to draw at which map location, do share. I can't see any sort of pattern between map values and an index into the tileset, and randomly changing values in the map yields some very strange results for some values! -- [[User:Malvineous|Malvineous]] 12:17, 19 May 2011 (GMT)

: I think I've found the MacDaddy function that responds to every tile value. The load_map_row function (seg000:25F0) that I mentioned above contains what appears to be a monster switch case statement for all the possible tile values, and possible other tile combinations. The function itself is 0x48F0 (18.6 kB) of mnemonics. Have fun with that one.

== Graphics editors ==

They can be found over at http://spikenexus.toxicsheep.com/pccw/pages/index.php?page=downloads

Talk:Duke Nukem II

2011-03-07T20:56:52Z

Lemm: double slash strings

How many versions of the registered game exist? 3D Realms only offers V1.0 for shareware download, and the purchase page for the registered version gives no indication as to the version.
[[User:Lemm|Lemm]] 06:24, 4 March 2011 (GMT)
: The [http://www.rinkworks.com/apogee/s/4.1.1.shtml Apogee FAQ] only lists the one version - I guess you could ask Joe Siegler on the 3D Realms forums if you expect there to be others. -- [[User:Malvineous|Malvineous]] 11:43, 4 March 2011 (GMT)
: I think you should ask [[User:Litude|Litude]]. He usually knows these kind of things. [[User:Frenkel|Frenkel]] 19:58, 4 March 2011 (GMT)

There are a bunch of text strings in the .exe that start with two slashes (e.g. //APAGE, //FADEIN, etc.). What do these do? [[User:Lemm|Lemm]] 20:56, 7 March 2011 (GMT)

Talk:Duke Nukem II

2011-03-04T06:24:30Z

Lemm: versions?

Talk:Commander Keen 4-6

2010-10-21T08:09:02Z

Lemm: save game format

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

Talk:EGAGraph Format

2010-09-03T20:16:28Z

Lemm: xSPRITES

== xSPRITES.TXT ==

What is the actual content of the sprite table? The following is from the modkeen document, which does not agree with what is posted on the main page of this artice. It would suggest that the "shifts" are stored in here as well? Are they stored somewhere else?

''Episodes 4, 5, and 6 only: This file contains extra information about each sprite. Each line in the file has the sprite number, followed by the four clipping rectangle co-ordinates in square brackets [top, left, bottom, right], followed by the sprite origin in square brackets [top, left], followed by the number of shifts the sprite uses. The origin of the sprite image is the point from which its location is calculated. For example, the hand sprite in Keen 5 (5SPR0291.BMP) has several images. The origin for each of these images is in the centre of the "eye", so that as the hand rotates, the different sprite images all appear to rotate about the eye. The origin coordinates are given in pixels from the top-left corner of the sprite image. The shifts is the number of different copies of the sprite image that are stored in memory, and can be 1, 2, or 4. As a general rule, the more shifts a sprite has, the smoother it moves, but the more memory it takes up. If you are making a very large sprite, you can reduce the number of shifts to save memory. But if you have a small sprite and want it to move more smoothly, increase the number of shifts.''

Also from modkeen source:

typedef struct

{

unsigned short Width;

unsigned short Height;

signed short OrgX;

signed short OrgY;

signed short Rx1, Ry1;

signed short Rx2, Ry2;

unsigned short Shifts;

} SpriteHeadStruct;

Which would make a 9-word structure.

20:16, 3 September 2010 (GMT)

Talk:IMF Format

2010-07-17T22:34:42Z

Lemm: another question about delay

As a note, IMFCreator, as far as I have been able to tell, DOES treat the #0 channel correctly, at least in that I have as yet failed to be able to create an IMF file that uses the #0 channel.

It also creates WOLF3D and Duke 2 files (Come on! It's from the Wolf3D site!) IF the speed is specified in the options menu. (It has seperate options for 280 and 560 Hz, with 700 being the default. You can also set the speed to a custom value.) ~Levellass 20/03/2010

:Oh ok, well as I haven't used IMFCreator I'm only going by what I've heard of other people's experiences. I'll update the table now but please feel free to just make corrections directly in the future if you notice anything like this. Also do you mean it creates Keen and Duke 2 files? Because I already listed it as creating Wolf3D files... -- [[User:Malvineous|Malvineous]] 03:39, 21 March 2010 (GMT)

::I ran some tests on some "complicated" MIDIs and IMFCreator does indeed appear to leave channel #0 free, so I've removed the question mark on that, thanks for prodding me into checking :-) -- [[User:Malvineous|Malvineous]] 04:04, 21 March 2010 (GMT)

Here is the the [[http://files.commanderkeen.org/users/omp/tsrmusic-july-16.zip music TSR]] for Commander Keen Vorticons with source included. I don't know why it lags when playing certain songs like "Make it Tighter." It seems to do this in faster songs where the pitch bend is being used.
[[User:Lemm|Lemm]] 16:41, 17 July 2010 (GMT)

== Delay ==

For the delay, what is meant by the number of cycles? If the delay is 2, does this mean that next two times the interrupt to play the adlib data is called, you don't send any data to the adlib port? (Does that even make sense :p) [[User:Lemm|Lemm]] 08:10, 5 June 2010 (GMT)

: It depends on what your interrupt rate is. For Commander Keen the IMF clock rate is 560Hz, so you will have 560 cycles per second. A delay of two will mean no data is sent for two of these cyles. A delay of 560 would result in one second of silence. -- [[User:Malvineous|Malvineous]] 09:52, 6 June 2010 (GMT)

:: Another question about delays: If a data chunk has a delay of zero, do you wait until the next cycle to play it, or do you keep sending data until you reach a chunk with a delay? Because that is what the music TSR is doing rigth now and perhaps that could be the reason it lags?

== Types ==

I've checked all the IMFs of all the games I have, that is to say every IMF using game except Corridor 7 and Operation Body Count. The type 0s I've seen always skip the first two bytes, and games don't like it when you don't include them. I've been trying to poke around game code to see how it treats the first two bytes, but I've only managed to explore Cosmo and Keen 4-6, for Keen at least as near as I can tell it can't take type 0s at all, simply reading the first two bytes as the length of data to play. (Someone could check this with a Keen engine game like Biomenace or Catacomb 3D)

Also I notice that the Biomenace IMFs have strings in them that seem to give the location of the file, for example xCity.imf has 'c:\bhazard\XCITY.IMF' in its tags. -- [[User:Levellass|Levellass]] 05:55, 6 July 2010 (GMT)

: That's interesting, please post back if you figure out what the two initial zero bytes are for! I always thought that they replaced the length bytes with 00 00 when it was not required, but it seems that chronologically the type-0 format came first, so this wouldn't be the case. It would be interesting to see what happens if you replaced 00 00 with a number that is half the file size - would it be used as the length? (In which case the song should only play to the middle before it loops and starts again.)

: It seems that most type-1 files have extra data at the end, Wolf 3D is another (that's one reason why the IMFs floating around from these games have proper filenames, based on those hints.) As yet nobody knows why the data is there or what it is used for, or even what format it is in. But apparently it was important enough that they wrote the length bytes at the front so the data could be kept in the file... -- [[User:Malvineous|Malvineous]] 06:08, 6 July 2010 (GMT)

::Ok, first up, I don't have a type-0 playing program, so I can't tell what it would do with the first two bytes of a type-0 file. Do you know of a type-0 playing program?

::Second, I've poked Tom Hall about this, apparently there are exactly four tag strings in the 'standard' IMF format ID worked with in this order, a word of unknown use, a 16-byte name string, a 64-byte filename string, and 6 bytes of compiler data. The strings are padded with nuls. (Total 88 bytes) These were put in by the program they used to add IMFs to the sound archive. (Actually copied not from the IMF itself, but taken from some sort of list file and just pasted on to the end of the IMF, some games, especially early ones apparently didn't use this method and so don't have this tag data.)

::He doesn't know where you got the composer thing or the $1A signature, I too am curious as to where that information came from. I've checked all the game files I have and I can see no game that uses it, though I was able to confirm Mr Hall's comments. In theory 'your' format could be used harmlessly in files, since games don't read the tag data at all.

::Oh, and IMf files of duration 0 (All their timer words are 0) crash games or don't play apparently. Can you confirm this? --[[User:Levellass|Endian? What are you on about?]] 13:14, 15 July 2010 (GMT)

::: [[Cosmo's Cosmic Adventures|Cosmo]] is one game that uses type-0 files and is fairly easy to mod for this sort of test. Interesting response from Tom Hall, I'll have to have another look at it. I think perhaps the fields weren't always padded with NULLs (rather random junk data) which is why both myself and Simon Peter (AdPlug author) couldn't figure it out. The composer tag and $1A signature were purely my own invention as I wanted to tag the files I had with their real names (e.g. for Major Stryker which gives the song titles in-game.) I haven't any files with no durations in them, but I am not surprised that it causes problems. I imagine at each "music tick" in the game code it reads everything up to the next delay, so if there are no delays it could get stuck in an endless loop or reach the end of the file on the first read attempt. Not sure what your endian comment is in reference to, but there's an explanation of why it's important on [[File format data types#Big endian vs little endian]]. -- [[User:Malvineous|Malvineous]] 23:08, 15 July 2010 (GMT)

::::Ok then, who's stupid? I'm stupid. After a lot of confusing and checking and some more talk, I have realized I made a few mistakes. This, as near as I understand it is the difference between the two types:

::::Type 0 came first. It consists of nothing but song data, thus filesize is always divisible by 4. The first 4 bytes are often (Though not necessarily) $00 $00 $00 $00 (A minor exception is Cosmo 1's MBANJO.IMF) Mr Hall thinks the game just starts reading from byte 0, not skipping anything, but he can't remember, maybe the first word IS skipped.

::::Type 1 came next, files can be any length because of tags. The first word of the file has a value that divides by 4. Programs that use this type always check the first two bytes THEN go on to play file data. Standard tags added by the compiler add 88 bytes to the file end.

::::This has put a theoretical kink in one of my programs, since it assumes that type-0\type-1 can always be told apart by the first two bytes, but someone would need to deliberately set up a type-0 to be confusing. *Sigh* --[[User:Levellass|Endian? What are you on about?]] 05:26, 16 July 2010 (GMT)

::::: As far as I'm aware, checking the first two bytes is enough to tell the format - all the utilities I've written as well as AdPlug use this method and I'm not aware of any files that don't fit. MBANJO.IMF is fine because the first two bytes are still 0x00 0x00. I don't believe the first word is ever skipped, as some of the software synths print errors about register 0x00 being invalid (so AdPlug and others play it.) I have just tested this by setting the first four bytes in MZZTOP.MNI to 0xB0 0xFF 0x00 0x03 which sets the frequency on channel 0 very high when the first note is played, and inserts a ~2 second delay before the song starts. I can hear this as a click (after a short delay) on the Cosmo 1 main menu. This proves that the game does in fact play the first two bytes and treats the following two as a delay. I guess it is just luck that the first two bytes are always writing 0x00 into the non-existent OPL register 0x00! -- [[User:Malvineous|Malvineous]] 13:32, 16 July 2010 (GMT)

Talk:IMF Format

2010-07-17T16:41:54Z

Lemm: --

As a note, IMFCreator, as far as I have been able to tell, DOES treat the #0 channel correctly, at least in that I have as yet failed to be able to create an IMF file that uses the #0 channel.

It also creates WOLF3D and Duke 2 files (Come on! It's from the Wolf3D site!) IF the speed is specified in the options menu. (It has seperate options for 280 and 560 Hz, with 700 being the default. You can also set the speed to a custom value.) ~Levellass 20/03/2010

:Oh ok, well as I haven't used IMFCreator I'm only going by what I've heard of other people's experiences. I'll update the table now but please feel free to just make corrections directly in the future if you notice anything like this. Also do you mean it creates Keen and Duke 2 files? Because I already listed it as creating Wolf3D files... -- [[User:Malvineous|Malvineous]] 03:39, 21 March 2010 (GMT)

::I ran some tests on some "complicated" MIDIs and IMFCreator does indeed appear to leave channel #0 free, so I've removed the question mark on that, thanks for prodding me into checking :-) -- [[User:Malvineous|Malvineous]] 04:04, 21 March 2010 (GMT)

Here is the the [[http://files.commanderkeen.org/users/omp/tsrmusic-july-16.zip music TSR]] for Commander Keen Vorticons with source included. I don't know why it lags when playing certain songs like "Make it Tighter." It seems to do this in faster songs where the pitch bend is being used.
[[User:Lemm|Lemm]] 16:41, 17 July 2010 (GMT)

== Delay ==

For the delay, what is meant by the number of cycles? If the delay is 2, does this mean that next two times the interrupt to play the adlib data is called, you don't send any data to the adlib port? (Does that even make sense :p) [[User:Lemm|Lemm]] 08:10, 5 June 2010 (GMT)

: It depends on what your interrupt rate is. For Commander Keen the IMF clock rate is 560Hz, so you will have 560 cycles per second. A delay of two will mean no data is sent for two of these cyles. A delay of 560 would result in one second of silence. -- [[User:Malvineous|Malvineous]] 09:52, 6 June 2010 (GMT)

== Types ==

I've checked all the IMFs of all the games I have, that is to say every IMF using game except Corridor 7 and Operation Body Count. The type 0s I've seen always skip the first two bytes, and games don't like it when you don't include them. I've been trying to poke around game code to see how it treats the first two bytes, but I've only managed to explore Cosmo and Keen 4-6, for Keen at least as near as I can tell it can't take type 0s at all, simply reading the first two bytes as the length of data to play. (Someone could check this with a Keen engine game like Biomenace or Catacomb 3D)

Also I notice that the Biomenace IMFs have strings in them that seem to give the location of the file, for example xCity.imf has 'c:\bhazard\XCITY.IMF' in its tags. -- [[User:Levellass|Levellass]] 05:55, 6 July 2010 (GMT)

: That's interesting, please post back if you figure out what the two initial zero bytes are for! I always thought that they replaced the length bytes with 00 00 when it was not required, but it seems that chronologically the type-0 format came first, so this wouldn't be the case. It would be interesting to see what happens if you replaced 00 00 with a number that is half the file size - would it be used as the length? (In which case the song should only play to the middle before it loops and starts again.)

: It seems that most type-1 files have extra data at the end, Wolf 3D is another (that's one reason why the IMFs floating around from these games have proper filenames, based on those hints.) As yet nobody knows why the data is there or what it is used for, or even what format it is in. But apparently it was important enough that they wrote the length bytes at the front so the data could be kept in the file... -- [[User:Malvineous|Malvineous]] 06:08, 6 July 2010 (GMT)

::Ok, first up, I don't have a type-0 playing program, so I can't tell what it would do with the first two bytes of a type-0 file. Do you know of a type-0 playing program?

::Second, I've poked Tom Hall about this, apparently there are exactly four tag strings in the 'standard' IMF format ID worked with in this order, a word of unknown use, a 16-byte name string, a 64-byte filename string, and 6 bytes of compiler data. The strings are padded with nuls. (Total 88 bytes) These were put in by the program they used to add IMFs to the sound archive. (Actually copied not from the IMF itself, but taken from some sort of list file and just pasted on to the end of the IMF, some games, especially early ones apparently didn't use this method and so don't have this tag data.)

::He doesn't know where you got the composer thing or the $1A signature, I too am curious as to where that information came from. I've checked all the game files I have and I can see no game that uses it, though I was able to confirm Mr Hall's comments. In theory 'your' format could be used harmlessly in files, since games don't read the tag data at all.

::Oh, and IMf files of duration 0 (All their timer words are 0) crash games or don't play apparently. Can you confirm this? --[[User:Levellass|Endian? What are you on about?]] 13:14, 15 July 2010 (GMT)

::: [[Cosmo's Cosmic Adventures|Cosmo]] is one game that uses type-0 files and is fairly easy to mod for this sort of test. Interesting response from Tom Hall, I'll have to have another look at it. I think perhaps the fields weren't always padded with NULLs (rather random junk data) which is why both myself and Simon Peter (AdPlug author) couldn't figure it out. The composer tag and $1A signature were purely my own invention as I wanted to tag the files I had with their real names (e.g. for Major Stryker which gives the song titles in-game.) I haven't any files with no durations in them, but I am not surprised that it causes problems. I imagine at each "music tick" in the game code it reads everything up to the next delay, so if there are no delays it could get stuck in an endless loop or reach the end of the file on the first read attempt. Not sure what your endian comment is in reference to, but there's an explanation of why it's important on [[File format data types#Big endian vs little endian]]. -- [[User:Malvineous|Malvineous]] 23:08, 15 July 2010 (GMT)

::::Ok then, who's stupid? I'm stupid. After a lot of confusing and checking and some more talk, I have realized I made a few mistakes. This, as near as I understand it is the difference between the two types:

::::Type 0 came first. It consists of nothing but song data, thus filesize is always divisible by 4. The first 4 bytes are often (Though not necessarily) $00 $00 $00 $00 (A minor exception is Cosmo 1's MBANJO.IMF) Mr Hall thinks the game just starts reading from byte 0, not skipping anything, but he can't remember, maybe the first word IS skipped.

::::Type 1 came next, files can be any length because of tags. The first word of the file has a value that divides by 4. Programs that use this type always check the first two bytes THEN go on to play file data. Standard tags added by the compiler add 88 bytes to the file end.

::::This has put a theoretical kink in one of my programs, since it assumes that type-0\type-1 can always be told apart by the first two bytes, but someone would need to deliberately set up a type-0 to be confusing. *Sigh* --[[User:Levellass|Endian? What are you on about?]] 05:26, 16 July 2010 (GMT)

::::: As far as I'm aware, checking the first two bytes is enough to tell the format - all the utilities I've written as well as AdPlug use this method and I'm not aware of any files that don't fit. MBANJO.IMF is fine because the first two bytes are still 0x00 0x00. I don't believe the first word is ever skipped, as some of the software synths print errors about register 0x00 being invalid (so AdPlug and others play it.) I have just tested this by setting the first four bytes in MZZTOP.MNI to 0xB0 0xFF 0x00 0x03 which sets the frequency on channel 0 very high when the first note is played, and inserts a ~2 second delay before the song starts. I can hear this as a click (after a short delay) on the Cosmo 1 main menu. This proves that the game does in fact play the first two bytes and treats the following two as a delay. I guess it is just luck that the first two bytes are always writing 0x00 into the non-existent OPL register 0x00! -- [[User:Malvineous|Malvineous]] 13:32, 16 July 2010 (GMT)

Talk:IMF Format

2010-07-17T15:21:23Z

Lemm: tsr music HELP

As a note, IMFCreator, as far as I have been able to tell, DOES treat the #0 channel correctly, at least in that I have as yet failed to be able to create an IMF file that uses the #0 channel.

It also creates WOLF3D and Duke 2 files (Come on! It's from the Wolf3D site!) IF the speed is specified in the options menu. (It has seperate options for 280 and 560 Hz, with 700 being the default. You can also set the speed to a custom value.) ~Levellass 20/03/2010

:Oh ok, well as I haven't used IMFCreator I'm only going by what I've heard of other people's experiences. I'll update the table now but please feel free to just make corrections directly in the future if you notice anything like this. Also do you mean it creates Keen and Duke 2 files? Because I already listed it as creating Wolf3D files... -- [[User:Malvineous|Malvineous]] 03:39, 21 March 2010 (GMT)

::I ran some tests on some "complicated" MIDIs and IMFCreator does indeed appear to leave channel #0 free, so I've removed the question mark on that, thanks for prodding me into checking :-) -- [[User:Malvineous|Malvineous]] 04:04, 21 March 2010 (GMT)

Here is the the [[http://files.commanderkeen.org/users/omp/tsrmusic-july-16.zip music TSR]] for Commander Keen Vorticons with source included. I don't know why it lags when playing certain songs like "Make it Tighter."

== Delay ==

For the delay, what is meant by the number of cycles? If the delay is 2, does this mean that next two times the interrupt to play the adlib data is called, you don't send any data to the adlib port? (Does that even make sense :p) [[User:Lemm|Lemm]] 08:10, 5 June 2010 (GMT)

: It depends on what your interrupt rate is. For Commander Keen the IMF clock rate is 560Hz, so you will have 560 cycles per second. A delay of two will mean no data is sent for two of these cyles. A delay of 560 would result in one second of silence. -- [[User:Malvineous|Malvineous]] 09:52, 6 June 2010 (GMT)

== Types ==

I've checked all the IMFs of all the games I have, that is to say every IMF using game except Corridor 7 and Operation Body Count. The type 0s I've seen always skip the first two bytes, and games don't like it when you don't include them. I've been trying to poke around game code to see how it treats the first two bytes, but I've only managed to explore Cosmo and Keen 4-6, for Keen at least as near as I can tell it can't take type 0s at all, simply reading the first two bytes as the length of data to play. (Someone could check this with a Keen engine game like Biomenace or Catacomb 3D)

Also I notice that the Biomenace IMFs have strings in them that seem to give the location of the file, for example xCity.imf has 'c:\bhazard\XCITY.IMF' in its tags. -- [[User:Levellass|Levellass]] 05:55, 6 July 2010 (GMT)

: That's interesting, please post back if you figure out what the two initial zero bytes are for! I always thought that they replaced the length bytes with 00 00 when it was not required, but it seems that chronologically the type-0 format came first, so this wouldn't be the case. It would be interesting to see what happens if you replaced 00 00 with a number that is half the file size - would it be used as the length? (In which case the song should only play to the middle before it loops and starts again.)

: It seems that most type-1 files have extra data at the end, Wolf 3D is another (that's one reason why the IMFs floating around from these games have proper filenames, based on those hints.) As yet nobody knows why the data is there or what it is used for, or even what format it is in. But apparently it was important enough that they wrote the length bytes at the front so the data could be kept in the file... -- [[User:Malvineous|Malvineous]] 06:08, 6 July 2010 (GMT)

::Ok, first up, I don't have a type-0 playing program, so I can't tell what it would do with the first two bytes of a type-0 file. Do you know of a type-0 playing program?

::Second, I've poked Tom Hall about this, apparently there are exactly four tag strings in the 'standard' IMF format ID worked with in this order, a word of unknown use, a 16-byte name string, a 64-byte filename string, and 6 bytes of compiler data. The strings are padded with nuls. (Total 88 bytes) These were put in by the program they used to add IMFs to the sound archive. (Actually copied not from the IMF itself, but taken from some sort of list file and just pasted on to the end of the IMF, some games, especially early ones apparently didn't use this method and so don't have this tag data.)

::He doesn't know where you got the composer thing or the $1A signature, I too am curious as to where that information came from. I've checked all the game files I have and I can see no game that uses it, though I was able to confirm Mr Hall's comments. In theory 'your' format could be used harmlessly in files, since games don't read the tag data at all.

::Oh, and IMf files of duration 0 (All their timer words are 0) crash games or don't play apparently. Can you confirm this? --[[User:Levellass|Endian? What are you on about?]] 13:14, 15 July 2010 (GMT)

::: [[Cosmo's Cosmic Adventures|Cosmo]] is one game that uses type-0 files and is fairly easy to mod for this sort of test. Interesting response from Tom Hall, I'll have to have another look at it. I think perhaps the fields weren't always padded with NULLs (rather random junk data) which is why both myself and Simon Peter (AdPlug author) couldn't figure it out. The composer tag and $1A signature were purely my own invention as I wanted to tag the files I had with their real names (e.g. for Major Stryker which gives the song titles in-game.) I haven't any files with no durations in them, but I am not surprised that it causes problems. I imagine at each "music tick" in the game code it reads everything up to the next delay, so if there are no delays it could get stuck in an endless loop or reach the end of the file on the first read attempt. Not sure what your endian comment is in reference to, but there's an explanation of why it's important on [[File format data types#Big endian vs little endian]]. -- [[User:Malvineous|Malvineous]] 23:08, 15 July 2010 (GMT)

::::Ok then, who's stupid? I'm stupid. After a lot of confusing and checking and some more talk, I have realized I made a few mistakes. This, as near as I understand it is the difference between the two types:

::::Type 0 came first. It consists of nothing but song data, thus filesize is always divisible by 4. The first 4 bytes are often (Though not necessarily) $00 $00 $00 $00 (A minor exception is Cosmo 1's MBANJO.IMF) Mr Hall thinks the game just starts reading from byte 0, not skipping anything, but he can't remember, maybe the first word IS skipped.

::::Type 1 came next, files can be any length because of tags. The first word of the file has a value that divides by 4. Programs that use this type always check the first two bytes THEN go on to play file data. Standard tags added by the compiler add 88 bytes to the file end.

::::This has put a theoretical kink in one of my programs, since it assumes that type-0\type-1 can always be told apart by the first two bytes, but someone would need to deliberately set up a type-0 to be confusing. *Sigh* --[[User:Levellass|Endian? What are you on about?]] 05:26, 16 July 2010 (GMT)

::::: As far as I'm aware, checking the first two bytes is enough to tell the format - all the utilities I've written as well as AdPlug use this method and I'm not aware of any files that don't fit. MBANJO.IMF is fine because the first two bytes are still 0x00 0x00. I don't believe the first word is ever skipped, as some of the software synths print errors about register 0x00 being invalid (so AdPlug and others play it.) I have just tested this by setting the first four bytes in MZZTOP.MNI to 0xB0 0xFF 0x00 0x03 which sets the frequency on channel 0 very high when the first note is played, and inserts a ~2 second delay before the song starts. I can hear this as a click (after a short delay) on the Cosmo 1 main menu. This proves that the game does in fact play the first two bytes and treats the following two as a delay. I guess it is just luck that the first two bytes are always writing 0x00 into the non-existent OPL register 0x00! -- [[User:Malvineous|Malvineous]] 13:32, 16 July 2010 (GMT)

Talk:Crystal Caves

2010-06-16T21:42:46Z

Lemm:

Talk:IMF Format

2010-06-05T08:10:37Z

Lemm:

Talk:Crystal Caves

2009-12-09T14:28:22Z

Lemm:

Talk:Crystal Caves

2009-12-09T14:13:08Z

Lemm:

No modding tools exist for Crystal Caves, correct?

Also, it appears that the levels are located in the UNP'd executable starting at seg000:7332. I believe tiles are stored as ASCII values, in pascal strings. Each row of tiles is 40 long, so there is an array of strings of length 41. Also, just looking at the ASCII representation of the hex values, you can clearly see the outline of the main level.

[[User:Lemm|Lemm]] 13:31, 9 December 2009 (GMT)

Talk:Crystal Caves

2009-12-09T13:41:56Z

Lemm:

No modding tools exist for Crystal Caves, correct?
Also, it appears that the levels are located in the UNP'd executable starting at 7332h
[[User:Lemm|Lemm]] 13:31, 9 December 2009 (GMT)

Talk:Crystal Caves

2009-12-09T13:31:30Z

Lemm: Created page with 'No modding tools exist for Crystal Caves, correct? ~~~~'

No modding tools exist for Crystal Caves, correct?
[[User:Lemm|Lemm]] 13:31, 9 December 2009 (GMT)

User:Lemm

2009-10-31T14:06:13Z

Lemm: Created page with 'wat'

wat

Talk:Id Software RLEW compression

2009-10-31T14:04:42Z

Lemm: Created page with 'In Keen Dreams, it seems that Word2 is copied, Word 1 number of times. --~~~~'

In Keen Dreams, it seems that Word2 is copied, Word 1 number of times.
--[[User:Lemm|Lemm]] 14:04, 31 October 2009 (GMT)

Talk:GameMaps Format

2009-10-31T12:42:54Z

Lemm: Created page with 'The values in that table are also good for Keen Dreams, except for the !ID! tag.'

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

GameMaps Format

2009-10-31T12:38:31Z

Lemm: /* Compression in GAMEMAPS */

The map data for [[Commander Keen 4-6]] is mainly stored in the <tt>GAMEMAPS.CKx</tt> file. This stores all the maps of the levels used in the game. The GAMEMAPS file is read and decompressed using data stored in the <tt>MAPHEAD.CKx</tt> file. The file's start is easily located as it always begins with the word $ABCD followed by several dwords and a lot of blank space. In the 1.4 versions of Keen 4-6 (Dumped executable) the file starts at the following:

Keen 4: $24830
Keen 5: $25990
Keen 6: $25080
(Keen D: $1FA50)

== Map headers ==

In Keen, as in most games, the <tt>MAPHEAD</tt> file is 402 bytes long, consisting of a word and 100 level dwords.

The first word is the flag for [[RLEW compression]], used to compress the <tt>GAMEMAPS</tt> file. By default this is $ABCD (This can be changed.). The remaining dwords point to the headers of each level in the <tt>GAMEMAPS</tt> file. (Nonexistent levels have a dword, value of -1 so this fills most of the file.) The file thus has space for 256 levels.

== GAMEMAPS Format ==

The structure of the <tt>GAMEMAPS</tt> file is disordered due to the fact that the level headers and level data can be located in any place in any order. The usual structure consists of a variable string of TED settings ('TEDv1.0...') followed by the levels in no particular order. Each level usually consists of the level header followed by three planes of data, though not always.

The TED settings are unimportant and can usually be ignored. (Though in some cases TED may use them.)

=== Levels in GAMEMAPS ===

The header for each level that is pointed to by MAPHEAD is 42 bytes long:

0 4 Offset in GAMEMAPS to beginning of compressed plane 0 data
4 4 Offset in GAMEMAPS to beginning of compressed plane 1 data
8 4 Offset in GAMEMAPS to beginning of compressed plane 2 data
12 2 Length of compressed plane 0 data (in bytes)
14 2 Length of compressed plane 1 data (in bytes)
16 2 Length of compressed plane 2 data (ib bytes)
18 2 Width of level (in tiles)
20 2 Height of level (in tiles)
22 16 Internal name for level (used only by editor, not displayed in-game. null-terminated)
38 4 Signature "!ID!"
42 x Level data, three planes RLEW and Carmack compressed

The presence of the level name and the signature are not required by the Keen engine to play the level. Plane 0 is the 'background' plane, plane 1 is the 'foreground' plane, and plane 2 is the 'info' plane. Each is compressed separately, as described below.

=== Compression in GAMEMAPS ===

Each plane is compressed with two successive compression algorithms. The first is [[RLEW compression]], identical to that used in [[Commander Keen 1-3]], except that the magic word (Flag.) is different. (It is specified in the MAPHEAD file, rather than always being xFEFE.) The second is [[Carmack compression]].

The order of compression is RLEW followed by Carmack. One must also keep in mind that each compression algorithm outputs as its first word the length of the uncompressed data. So in the GAMEMAPS file for a particular plane of a particular level, the first word is the number of bytes in the RLEW-compressed data, and the first word of the RLEW-compressed data is the number of bytes in the uncompressed data.

(Note: In Keen Dreams, Huffman Compression is used in place of Carmack Compression. An array of bytes at $1FBE2 in the executable contains the lengths of the compressed level headers.)

== Utilities ==

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

== Notes ==

This format was reverse engineered by Andrew Durdin (adurdin).

The format is used by other games as well, including [[Bio Menace]], [[Catacomb 3D]], [[Dangerous Dave 3]], [[Dave Goes Nutz]], and [[Wolfenstein 3D]]

GameMaps Format

2009-10-31T12:36:36Z

Lemm:

The map data for [[Commander Keen 4-6]] is mainly stored in the <tt>GAMEMAPS.CKx</tt> file. This stores all the maps of the levels used in the game. The GAMEMAPS file is read and decompressed using data stored in the <tt>MAPHEAD.CKx</tt> file. The file's start is easily located as it always begins with the word $ABCD followed by several dwords and a lot of blank space. In the 1.4 versions of Keen 4-6 (Dumped executable) the file starts at the following:

Keen 4: $24830
Keen 5: $25990
Keen 6: $25080
(Keen D: $1FA50)

== Map headers ==

In Keen, as in most games, the <tt>MAPHEAD</tt> file is 402 bytes long, consisting of a word and 100 level dwords.

The first word is the flag for [[RLEW compression]], used to compress the <tt>GAMEMAPS</tt> file. By default this is $ABCD (This can be changed.). The remaining dwords point to the headers of each level in the <tt>GAMEMAPS</tt> file. (Nonexistent levels have a dword, value of -1 so this fills most of the file.) The file thus has space for 256 levels.

== GAMEMAPS Format ==

The structure of the <tt>GAMEMAPS</tt> file is disordered due to the fact that the level headers and level data can be located in any place in any order. The usual structure consists of a variable string of TED settings ('TEDv1.0...') followed by the levels in no particular order. Each level usually consists of the level header followed by three planes of data, though not always.

The TED settings are unimportant and can usually be ignored. (Though in some cases TED may use them.)

=== Levels in GAMEMAPS ===

The header for each level that is pointed to by MAPHEAD is 42 bytes long:

0 4 Offset in GAMEMAPS to beginning of compressed plane 0 data
4 4 Offset in GAMEMAPS to beginning of compressed plane 1 data
8 4 Offset in GAMEMAPS to beginning of compressed plane 2 data
12 2 Length of compressed plane 0 data (in bytes)
14 2 Length of compressed plane 1 data (in bytes)
16 2 Length of compressed plane 2 data (ib bytes)
18 2 Width of level (in tiles)
20 2 Height of level (in tiles)
22 16 Internal name for level (used only by editor, not displayed in-game. null-terminated)
38 4 Signature "!ID!"
42 x Level data, three planes RLEW and Carmack compressed

The presence of the level name and the signature are not required by the Keen engine to play the level. Plane 0 is the 'background' plane, plane 1 is the 'foreground' plane, and plane 2 is the 'info' plane. Each is compressed separately, as described below.

=== Compression in GAMEMAPS ===

Each plane is compressed with two successive compression algorithms. The first is [[RLEW compression]], identical to that used in [[Commander Keen 1-3]], except that the magic word (Flag.) is different. (It is specified in the MAPHEAD file, rather than always being xFEFE.) The second is [[Carmack compression]].

The order of compression is RLEW followed by Carmack. One must also keep in mind that each compression algorithm outputs as its first word the length of the uncompressed data. So in the GAMEMAPS file for a particular plane of a particular level, the first word is the number of bytes in the RLEW-compressed data, and the first word of the RLEW-compressed data is the number of bytes in the uncompressed data.

(Note: In Keen Dreams, Huffman Compression is used in place of Carmack Compression. An array of bytes at $1FBE2 in the executable contains the lengths of the compressed data.)

== Utilities ==

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

== Notes ==

This format was reverse engineered by Andrew Durdin (adurdin).

The format is used by other games as well, including [[Bio Menace]], [[Catacomb 3D]], [[Dangerous Dave 3]], [[Dave Goes Nutz]], and [[Wolfenstein 3D]]