ModdingWiki - User contributions [en-gb]

Talk:Catacomb Map Format

2012-05-07T17:15:13Z

Eros: Oops...

What is missing for this page? I can provide nearly anything. A screenshot? A spritesheet of the tileset? Whatever you need. - [[User:Eros|Eros]] 12:35, 6 May 2012 (GMT)
: Looks like just a sample level image is all that's remaining. Are you able to get one showing the full 64x64 level in its initial state, with enemies etc. in their start places? If not a game screenshot will do for the time being, preferably cropped to remove the status bar etc. and showing just the level itself. -- [[User:Malvineous|Malvineous]] 02:47, 7 May 2012 (GMT)
:: Malvineous, do you mean something like this? http://www.vgmaps.com/Atlas/PC/index.htm#Catacomb [[User:Frenkel|Frenkel]] 16:49, 7 May 2012 (GMT)
::: I uploaded a picture of level 1 that you created Frenkel, It's a little too big, Malvineous, perhaps you can make it a thumbnail? - [[User:Eros|Eros]] 17:15, 7 May 2012 (GMT)

File:Catacomb Map Format.png

2012-05-07T17:04:00Z

Eros: Catacomb level 1. Provided by Frenkel

[[Catacomb]] level 1.

Provided by [[User:Frenkel|Frenkel]]

Talk:Catacomb Map Format

2012-05-06T12:35:12Z

Eros: What do you need?

What is missing for this page? I can provide nearly anything. A screenshot? A spritesheet of the tileset? Whatever you need. - [[User:Eros|Eros]] 12:35, 6 May 2012 (GMT)

User talk:Malvineous

2012-05-06T03:54:42Z

Eros: /* Catacomb */ oops

== Wolfenstein 3D -> Wolfenstein 3-D ==
I've corrected the infamous 3D tyop in the names of several Wolf3D-related pages; can you please delete the following ones?

[[:Category:Wolfenstein 3D]] -> Superseded by [[:Category:Wolfenstein 3-D]]<br>
[[:Image:Wolfenstein_3D.png]] -> Superseded by [[:Image:Wolfenstein_3-D.png]]

Thanks :) --De Zeurkous (zeurkous@zeurcomp.nichten.info), Thu Nov 22 08:18:42 UTC 2007

:Haha, you've certainly been busy. Don't forget that this wiki isn't meant to be an encyclopaedia of the games, its main purpose is documenting the file formats and editing tools that can be used with the games, as opposed to how the games behave without any mods, or what they might be called if you forget to change the title screen :-) -- [[User:Malvineous|Malvineous]] 11:14, 22 November 2007 (GMT)

::Nah, I haven't forgotten. As we're reinventing the wheel for a semi-virgin wiki, the naming and something static like the cheats seemed like a good place to start :) --De Zeurkous (zeurkous@nichten.info), Thu Nov 22 12:20:04 UTC 2007

== Jill of the Jungle palette ==

Hi, I'm currently working on a level viewer for [[Jill of the Jungle]] (maybe an editor later on). Some of the information I found here has been very useful, but there's one thing I'm a bit stuck on. On the [[SHA Format]] page it says:
:''Each array item contains 4 unsigned bytes, representing CGA, EGA and VGA, respectivley, and then a null value. [...] Each byte maps to the index of a colour in the palette. If there are no colours required, the tile set uses the default colours.''
However, it doesn't say anywhere where the palette can be found. Is it stored in the EXE file? I hope you can help me on this :)

Regards, [[User:Spinal|Spinal]] 13:00, 2 March 2008 (GMT)

:Unfortunately I didn't write the JotJ SHA page, and I haven't yet had the time to figure this out. For Xargon I've taken the quick and dirty route and used a screenshot from within DOSBox as the source of the palette, until I can figure out where the palette is located. If you find this out, don't forget to update the page! :-) -- [[User:Malvineous|Malvineous]] 22:02, 2 March 2008 (GMT)

::Hey Spinal, sorry, I wrote the [[SHA Format]] page, so that was probably my bad. I wasn't able to find the palette either. I assume it's in the .EXE, however I spent a fair bit of time manually mapping it using a Wombat tool (http://www.szevvy.com/node/3). I was also writing a level viewer (initally in XHTML which turned out to be too slow, so then I moved to Flash 9). I tried to email you my findings, but the email bounced. I'm not sure if they were 100% accurat, which is why I never added them to the documentation.

::Hey Malvineous, it seems the Jill - [[DMA Format]] page has been removed. Do you have a log of what happened to it? I'm sure it existed at some point.

::- [[User:dheim|Daniel]] 20:00, 5 March 2008

:::I don't ever remember seeing a DMA page - certainly there's nothing in the wiki logs about it being deleted or renamed. Maybe you started working on it but never got around to saving it? Or is it one of the Xargon pages that shares the same format as Jill? (by the way, you can type <nowiki>~~~~</nowiki> to automatically put in the signature in these messages.) -- [[User:Malvineous|Malvineous]] 11:28, 5 March 2008 (GMT)

::::Sorry, it must have been the stuff in the [[SHA Format]] page that I was thinking of. I may have added the link to the [[DMA Format]] page, and never expanded on it. - [[User:Dheim|Daniel]] 02:46, 6 March 2008 (GMT)

:::::Hi guys. Sorry for the mistake, I mixed up the authors of the SHA and level formats. I've written a level viewer in PHP the last week, by using static images instead of getting them from the actual files. This causes some problems for episode 2, which uses a different palette, but besides that it works great :) When everything is done I'll upload the maps to my server and the tile/object lists to this wiki.
:::::@Daniel: strange that it bounced, I confirmed my address so it should be working fine... You can mail it to spinal -at- zanderz -dot- net. Also, I saw on your Wombat page that you "have a vague idea of how to do" [[Hocus Pocus]]. Could you share your findings on this wiki? I'd love to make maps, or even a level viewer/editor for that game :) -- [[User:Spinal|Spinal]] 00:32, 8 March 2008 (GMT)
:Okay, with help of [[User:Dheim|Daniel]] who send me the palette I found it! I'll put my findings on [[Jill of the Jungle palette]]. -- [[User:Spinal|Spinal]] 15:36, 13 March 2008 (GMT)

== Halloween Harry/Alien Carnage ==

Hi Malvineous. Thanks for your edits on the GMF article! I notice you mentioned there exist versions of the game which don't require exploding a BNK to get at the game data. What does the directory structure look like for the version you have? I'm working on a map viewer (which will become a map editor at some point) and would like it to be able to work on whatever versions are out there. Thanks for any info. -[[User:Duckthing|Duckthing]] 04:41, 11 December 2010 (GMT)

: Hi Duckthing - no worries, Halloween Harry has long been an interest of mine, but my map editor sadly needs a lot more work before I can begin reverse engineering more file formats so I'm glad you've made a start! AFAIK technically Halloween Harry has no compression, but for whatever reason (probably listed in the Apogee FAQ) they decided to swap episodes 1 and 3, compress the BNK file and then re-release it under the name Alien Carnage. You can download all available versions (including registered versions since the game was released as freeware in 2007) from [http://www.classicdosgames.com/game/Alien_Carnage.html RGB Classic Games]. BTW not sure if you noticed but I also posted a couple of things on the GMF article's talk/discussion page. -- [[User:Malvineous|Malvineous]] 06:08, 11 December 2010 (GMT)

:: Thank you! Working with the uncompressed version will keep things less complicated. I did notice the GMF discussion you added, but haven't had a chance to really go through it yet. -- [[User:Duckthing|Duckthing]] 06:41, 11 December 2010 (GMT)

::: No worries. If you're running Linux or MacOSX you should be able to compile [[Camoto|libgamearchive]] which will let you copy files in and out of the BNK files. This is a library so it's also possible to use it in your own program for accessing and editing the map files while they're still inside the BNK, for instance. (BTW the 'minor' tickbox should only be used when the edit does not affect the information on the page - e.g. fixing a typo or a broken URL. If you are changing the actual content on a page it is never a minor edit!) -- [[User:Malvineous|Malvineous]] 07:51, 11 December 2010 (GMT)

== Dangerous Dave ==

Working on this, does anyone have any info on the formats? The EGA graphics are 84KB and external, but CGA and VGA graphics unrelated to them are in the 174KB executable, apparently uncompressed, I don't know how this is possible. I've found the levels and partially reverse engineered the format (The first 1000 bytes, a 100x10 array of tiles.) but each level is followed by ~280 bytes of variable and unknown data I assume is sprites. I have a list of internal files in the executable, looks like most of it is non-game code. Any help would be appreciated. -[[User:Levellass|Endian? What are you on about?]] 06:03, 12 December 2010 (GMT)

: Hmm, interesting. All I can suggest for the levels is - as you're probably already familiar with - changing the values in a hex editor then loading the game to see what happens. I would suspect that all the graphics would be in a similar format, so if there are any headers or structures used in the EGA graphics files perhaps they're duplicated for CGA/VGA? Also John Romero seems pretty accessible, perhaps you could ask him directly? Failing that, randomly writing data into the .exe until the images change could be used as a last resort! -- [[User:Malvineous|Malvineous]] 12:09, 12 December 2010 (GMT)

: Ha, that was easier than I expected - uncompressed VGA data is easy to find with a good hex editor ;-) [http://www.shikadi.net/pics/ddave-vga-hexdump.png This looks like it] -- [[User:Malvineous|Malvineous]] 12:17, 12 December 2010 (GMT)

: Ok that was only the menu graphics. At offset 0xC629 there's some sort of offset table which looks very similar to the contents of EGADAVE.DAV but there are extra bytes dotted all over the place - perhaps it's RLE encoded? Actually just before that there's the number 0x6CAA. If you go a bit less than 0x6CAA bytes after this you end up with another table, which to me suggests that 0x6CAA is the decompressed size of that first table. -- [[User:Malvineous|Malvineous]] 13:01, 12 December 2010 (GMT)

:If I remember it correctly, the VGA sprites and tiles are RLE compressed and it's not too hard to decompress them. The positions of the enemies in the levels on the other hand are still a mystery to me. [[User:Calvero|Calvero]] 20:43, 12 December 2010 (GMT)

: Looking at the levels, which directly follow the VGA palette, they seem to contain 256 bytes of header data, then the 100x10 tiles, then eight bytes of lead-out data. Then the next level's 256 bytes of header, 100x10 tiles, then eight bytes of lead-out. Although I say "level", the first "level" seems to contain both level 1 and 2, and this seems to be the way it works in the game - in some levels you can see through to others. I'm not sure what the 256 bytes of header data are for, but some levels have FF FF 00 00 repeated which seems to indicate two uint16 fields which are blanked out for those levels. -- [[User:Malvineous|Malvineous]] 13:15, 13 December 2010 (GMT)

::First up, levels; where does level 1 start? It's possible I'm reading the start of a level as the previous level's end, I looked for the start of tile data, which I assumed, like Keen 1, would be the level start.

::Next, palette; I'm assuming, as you said, it is located just before the level data?

::There is VGA and CGA graphics in the executable, plus headers, but the bulk of graphics for CGA and VGA I haven't been able to locate. If the data is RLE compressed I should think it would use either Keen 1-3 fullscreen or Jazz Jackrabbit tile RLE, both of which I know well. I'll look into both of these options, cheers! -[[User:Levellass|Endian? What are you on about?]] 12:03, 20 December 2010 (GMT)

:::I've found the VGA and CGA data for the menu graphics. It looks like the CGA data is stored in a series of 1-bit-per-pixel (monochrome) images. Or it could be EGA data with the planes split out (e.g. red plane for all images, then green plane for all images, etc.) I think I found three planes which means it's probably EGA, as CGA would have a max of two planes. I've also found the font graphics, this looks like 4bpp/16 colour EGA data. Haven't seen level graphics yet. I've successfully modded the levels with a hex editor (putting the jetpack everywhere) so now I've finally looked at all the levels! The creatures are definitely not stored in the 100x10 tile data. Putting random bytes in there revealed that the values are indices into the image files, because if you put the value in for fire it will animate, and the following three or so values show up as still frames from the fire animation.

:::The VGA palette starts at 0x26B0A (I updated the main DDave page with this) + 768 bytes leads straight onto the start of level 1 at 0x26E0A. So at 0x26E0A there are 256 bytes of data, then 100x10 tiles, then 24 bytes of footer data. Some of this data (perhaps footer data) might be the level start coordinates, because Dave doesn't always start the level at the same place (e.g. the warp level when you climb the tree on level 5 and jump off the edge of the screen.) -- [[User:Malvineous|Malvineous]] 12:24, 20 December 2010 (GMT)

:::I think I've found all the files so far, I've updated [[Dangerous Dave]] with the offsets of the files, including what appears to be CGA and VGA tiles. I'm not sure what sort of format they're in though, it looks like they might be compressed (and so the offsets in that list might be off by ~4, as I may have cut off the decompressed-size field.) I've also updated the map format page, I think it's pretty much fully reverse engineered now. -- [[User:Malvineous|Malvineous]] 05:13, 21 December 2010 (GMT)

== Noahs Ark 3D and IMFs ==

Been poking around Noah's Ark 3D, an adaption of the Wolfenstein game and found a few interesting things which I'm hoping to confirm.

First, the game uses MID files, not IMF files for music, second, the MIDI files have an extra word at the start of the file giving the file length. Third, the code uses the first word of the midi file as the length of data to read from the file and put into memory to play. After poking around a bit in Wolfenstein and Keen I believe this is the same with IMF files, that is, ALL IMF files are type 0 as it were and the type 1s are read just like type 0s by the games (The first word is read as the amount of IMF data to copy into memory to play, this is then read as type 0.) I'm not quite sure what this does for the two types since type 1 is would essentially be a type 0 with a header and footer that are part of the AUDIO.xxx format, much like PC\adlib sounds can have the huffman lengths at the start. Are there any games that use 'individual' type 1 IMFs (Even if included as part of a group file. All I've seen are games like cosmo, where non-AUDIO IMFs are type 0.)

Should there be a Noah's Ark 3D page and should we add the midi note to the AUDIO format page? It seems that the format can hold any type of music file the game can read, not just IMFs. -- Levellass

: Yes it is known that the type-1 header might really be part of the AUDIO.xxx format but alas there were many type-1 files floating around the place (incorrectly extracted, you could argue) before this was realised, so the format variant is here to stay. It does have some advantages though (like tagging files with the song title) but I'm not sure whether anyone has figured out definitively whether the header (and footer, in the case of the Wolf3D files) belongs to the IMF or the AUDIO file. I guess you'd have to browse the game source code and see how the game uses the data to know for sure.

: As far as the MIDI goes, I believe the AUDIO.xxx file is just a container file like any other, capable of supporting any data at all. It's up to the game to decide how to use it. If anything this makes me think it would fit better if the AUDIO.xxx article was merely documenting the structure, with links to actual audio formats like PC SFX, Adlib SFX, IMF and MIDI and notes about which games make use of which formats.

: Oh and yes, by all means create a page for the new game. -- [[User:Malvineous|Malvineous]] 08:41, 3 February 2011 (GMT)

== Sound Files category ==

I don’t know why there’s a Sound Files category and also an Audio Files category... it seems redundant. I left those categories the way they are though.

Also, the [[File format data types]] page needs some signed ints, but I didn’t know what naming convention you wanted to use. I described something as an [[INT16LE]] on [[BMC Format]]. [[User:Yellowantphil|Yellowantphil]] 20:12, 11 September 2011 (GMT)

: Not sure about the Sound vs Audio - I use the term 'audio' to mean both sound and music, but you're right, if there are separate sound and music categories we don't really need an audio one as well. Feel free to update. [[INT16LE]] is perfectly fine too! I added a note to the data types page. -- [[User:Malvineous|Malvineous]] 22:30, 11 September 2011 (GMT)

== GamePage template ==

Should the GamePage template add the page to its own category? It seems a little odd that [[Wacky Wheels]] is not in the Wacky Wheels category. [[User:Yellowantphil|Yellowantphil]] 04:51, 16 September 2011 (GMT)
: I decided against this because there is a link to the game's page in the category intro at the top of the page. It seemed unnecessary having another link in amongst all the other pages. This was also because the game page was really only meant to be a summary, there wasn't supposed to be a huge amount of detail on it, only links to other pages with the detail (which then would appear in the category list.) I would imagine that, eventually, [[Wacky Wheels]] would be tweaked to move a lot of the content onto subpages. -- [[User:Malvineous|Malvineous]] 12:58, 16 September 2011 (GMT)

== Scope of the wiki ==

I don’t know how extensive you want the information to be on ModdingWiki... I added a few lists of audio and graphics files a while ago, and there will probably be other information that I’ll find out that’s potentially helpful for level editing but not directly related to it. I can move some information to my website if it starts to become out of scope for your wiki. I also sometimes end up documenting everything imaginable... there’s some minutiae on my website and possibly on your wiki that I ought to go through and delete. [[User:Yellowantphil|Yellowantphil]] 05:28, 10 October 2011 (GMT)

:Hmm, that's a difficult one - I'm always in favour of documenting more rather than less. Generally speaking if it's related to a game and it would help either a programmer writing a utility or a someone trying to change a game manually then it should be documented. About the only thing that comes to mind that's over documenting is when some small calculation is expressed in a couple of different programming languages, but I've left that in so people can just copy it rather than trying to figure it out from the text. But the [[Wacky Wheels]] page is probably the gold standard for what all wiki pages should look like :-) Do you have anything in particular you're unsure of whether it would fit here? -- [[User:Malvineous|Malvineous]] 10:07, 10 October 2011 (GMT)

::I was mainly thinking of the list of VOC files on [[Wacky Wheels Music and Sound Effects]] and the list of <tt>*.sp</tt> files on [[Wacky Wheels Graphics Formats]]. I have an expanded list of the <tt>*.sp</tt> files on my computer but it isn’t finished yet. I guess there isn’t all that much more Wacky Wheels information to be added to this wiki though. There is still some modding information on my website that ought to be moved over here, so that would take up another page or two. I’ve been lazy about doing Wacky Wheels stuff lately, but I might find some time for it this weekend.

::By the way, I guess that guy from Cascadia Games emailed you. It’s pretty interesting that WW might become an iPhone app. He told me that he was going to be using his own game engine, which sounds a lot easier than trying to get a hold of the WW source code and porting it. —[[User:Yellowantphil|Yellowantphil]] 16:46, 15 October 2011 (GMT)

::: I was going to say the list of VOCs might be overkill, but then the list of .sp files might be useful. To be honest, it's the sort of thing that you could probably omit if you were feeling lazy, but likewise I don't mind at all if you choose to include it, so since it's already there I'm happy to keep it.

::: Yes I did get an e-mail from Cascadia, I was going to pass along your details but it sounds like you're already aware of it! Using their own engine might make it a bit smoother than the original, as the jerkiness of turning is my only criticism of the game. -- [[User:Malvineous|Malvineous]] 00:14, 16 October 2011 (GMT)

== Wacky Wheels ==

Basically all of the WW modding information from my website is here now. I moved one page when I realized it should probably be capitalized to match the rest of the pages on this site... you can delete the redirect at [[Wacky Wheels high score files]] if you want to.

Now, I need to remove most of the modding information from my website and refer people here. Then we’ll have reached the glorious future where all WW modding information is in one place. I’m going to keep those two text files of notes on my website though—the information in them is disorganized and I think not 100% accurate, but they might have some information that isn’t here yet.

By the way, how’s Camoto going? I’m planning to use it to make a new WW level, but I won’t have time for it for a few more months. —[[User:Yellowantphil|Yellowantphil]]

: Sounds good! Thanks for all the effort you've put in by moving it across. I think Wacky Wheels is now the most completely documented game on the wiki! Also can't hurt leaving your own info up - sometimes it's nice to go back to the original source if something is unclear. Camoto's going well, but unfortunately I haven't had much time to work on it over the last few weeks. You probably won't be able to make much of a level until I add in the ability to select a tile from the tileset, but that's in progress and hopefully will be ready by the time you are! Keep me posted when you do start your level(s?) -- [[User:Malvineous|Malvineous]] 12:22, 2 February 2012 (GMT)

::Well, as I was reading some of the information on my website, I noticed that it isn’t written very well. I wrote those pages back when I had very little experience programming. Anyway, I’m planning to redesign my website soon, and this will save me from having to rewrite a few of those pages.

::The tile editor in Camoto as it is now is still certainly useful—I can add new tile types to a level using a binary editor and then move them around in Camoto. I think that it shouldn’t be too hard to make a new WW level using the Gimp and Camoto plus some binary editing. I recall having some problems with the route editor for the computer players, but I didn’t look into it at the time—I’ll let you know when I’m working with Camoto again, and I’ll try to come up with some useful bug reports or fixes if I run into problems. —[[User:Yellowantphil|Yellowantphil]] 14:06, 2 February 2012 (GMT)

== Catacomb ==

Hey [[User:Malvineous|Malvineous]], do you know anyone who has properly read the [[Inverse_Frequency_Sound_format|Inverse Sound Frequency]] file format and got the sound playing? I'm struggling with some fine details in my game. Sounds play near what they should sound like, but the sound quality is all crackly and some sounds play totally incorrect. I followed a basic [http://web.archive.org/web/20000818033701/http://www.dd.chalmers.se/~f98anga/projects/keen/sounds2raw.c code sample] by Anders Gavare. Does your tool support this? Interested in helping me figure this out? My current code is available at [https://code.google.com/p/cataclone/source/browse/trunk/src/catacomb/catacomb_sound.c catacomb_sound.c] - [[User:Eros|Eros]] 11:57, 5 May 2012 (GMT)
: Should this be moved to my talk page? - [[User:Eros|Eros]] 11:59, 5 May 2012 (GMT)
:: Probably best to keep it on my talk page if you want me to respond in a timely manner :-) I based my old utility off Anders' one too, but it's been a long time since I looked at the code. My latest utility doesn't support sound effects yet. I know Levellass has written a few utilities to play and edit those sound files, so I think your best bet would probably be to post over at the [http://www.keenmodding.org Keen:Modding] forum. Do note that PC Speaker effects do sound crackly at the best of times, though! Also make sure you've got the right audio format (8-bit vs 16-bit, signed vs unsigned) - I remember some inconsistencies there causing some very distorted results for me. I love the name 'Cataclone' - does your code compile under Linux? -- [[User:Malvineous|Malvineous]] 13:21, 5 May 2012 (GMT)
::: I currently compile the code using Code::Blocks with GCC 4.6 -std=gnu99. It *should* compile under Linux. But I haven't tested that out yet. [[Catacomb]] sounds also have flags attached to each one, It's not exactly the same specification as what it says @ the [[Inverse_Frequency_Sound_format|Inverse Sound Frequency]] format page. Perhaps the flags would make a difference to the sounds? I have the sound setup @ [https://code.google.com/p/cataclone/source/browse/trunk/src/sound_manager.c sound_manager.c] in the sound_manager_init() method. I use AUDIO_S16 (signed 16-bit) @ 22050 Hz with 2 channels. I have not added support for the priority of the sounds yet, I plan on doing that after I get them playing properly.
::: I found some information on the [[ROTT]] sound format here: [http://src.gnu-darwin.org/ports/games/rottdc/work/rottdc-1.0-2/rott/_rt_soun.h _rt_soun.h]. This format should be similar to Catacomb as ROTT was developed by [[Apogee]] using the [[Doom]] engine. Here are the flags for the sounds that they define:
#define SD_OVERWRITE 0x01
#define SD_WRITE 0x02
#define SD_LOOP 0x04
#define SD_PITCHSHIFTOFF 0x08
#define SD_PLAYONCE 0x10
::: There are also many other sound files for ROTT: [http://src.gnu-darwin.org/ports/games/rottdc/work/rottdc-1.0-2/rott/rt_sound.c], [http://src.gnu-darwin.org/ports/games/rottdc/work/rottdc-1.0-2/rott/rt_sound.h], [http://src.gnu-darwin.org/ports/games/rottdc/work/rottdc-1.0-2/rott/snd_reg.h], [http://src.gnu-darwin.org/ports/games/rottdc/work/rottdc-1.0-2/rott/snd_shar.h], [http://src.gnu-darwin.org/ports/games/rottdc/work/rottdc-1.0-2/rott/sndcards.h]
:::: I tried it last night and I was able to get it to compile (after a few changes, like using '/' instead of '\' in a couple of #includes) but all I got was a black window and a beep sound, then nothing. How far advanced is the project? Should I expect more than that? I would expect small variations in the file formats between games, but I would be surprised if the core sound data has changed over time. -- [[User:Malvineous|Malvineous]] 02:38, 6 May 2012 (GMT)
::::: On Windows, you can run around the levels, collide with walls, collect items, etc... I still need to implement monsters, AI and power shots. However, that beep means that the sounds playing. (see line 71 in main.c: catacomb_sounds_play("foundsound");). I just committed the catacomb_data.h file. Update it accordingly, you should now see much more than a black screen.
:::::: Oh wow, that works really well now! I see what you mean by the sounds. You might have to output the PCM data to a .wav/.raw file and look at it in a sound editor to see what's going on. It sounds like there might be wrapping or something going on. Also some sounds (like being blocked by a door) play multiple times over the top of themselves. I guess this is what you meant by priority not being implemented (although maybe you wouldn't need to handle priority if you can play multiple sounds at the same time, unlike the real PC Speaker.) One suggestion - if you do decide to support Linux, abstract the calls that open files so that they search for filenames instead - that way you don't have to rename all the Catacomb files to be uppercase, since Linux has a case-sensitive filesystem and most filenames are usually all lowercase. -- [[User:Malvineous|Malvineous]] 03:42, 6 May 2012 (GMT)
::::::: I have exported the raw data to a file, then imported the raw data into Audacity using various settings. All of them sound like they do in the game, crackly and sometimes distorted. I really think its some sort of post FX used by the flags. As for files, I'll code some sort of SafeFileOpen, SafeFileClose functions like the id codebase that open files regardless of case when i get around to implementing the Linux version. - [[User:Eros|Eros]] 03:54, 6 May 2012 (GMT)

User talk:Malvineous

2012-05-06T03:53:41Z

Eros: /* Catacomb */ sweet

User talk:Malvineous

2012-05-06T02:45:27Z

Eros: /* Catacomb */ Added missing data.

User talk:Malvineous

2012-05-06T01:41:42Z

Eros: /* Catacomb */ More sound info

ROTT

2012-05-06T01:34:40Z

Eros: Added ROTT redirect to Rise_of_the_Triad

#REDIRECT [[Rise_of_the_Triad]]

User talk:Malvineous

2012-05-06T01:30:46Z

Eros: /* Catacomb */

User talk:Malvineous

2012-05-05T11:59:35Z

Eros: /* Catacomb */ my talk page?

User talk:Malvineous

2012-05-05T11:57:21Z

Eros: Inverse Sound Frequency help?

User talk:Eros

2012-05-05T11:05:14Z

Eros: Ok

Hi Eros - just a quick request - can you leave the section headings as normal case? You keep converting them into title case, which makes them different to all the other pages in the wiki :-) -- [[User:Malvineous|Malvineous]] 11:03, 5 May 2012 (GMT)
: Yeah, realized that too after looking at some Wikipedia pages. I'll stop now. -- [[User:Eros|Eros]] 11:05, 5 May 2012 (GMT)

Inverse Frequency Sound format

2012-05-05T09:21:39Z

Eros: Yes, from the start of the file.

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

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

== File format ==

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

=== Header ===

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

=== Sound definitions ===

This structure is repeated once per sound.

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT16LE]] || offset || Offset of the sound from the beginning of the file.
|-
| [[UINT8]] || priority || Whether or not sound will be interrupted by another sound if said sound starts playing while the first is. Sounds can only be interrupted by sounds that have an equal or higher value of this. 255 is max, 0 is inadvisable.
|-
| [[UINT8]] || flags || If a sound is a 'placeholder' to be ignored, this is 1, if it is a proper sound it is 8.
|-
| [[char]][12] || name || Null-padded sound name
|}

=== Sound data ===

Sound data is divided into words (UINT16LE), with the word value being inversely proportional to the sound frequency. Each word is around 1/64th of a second of tone and most files contain a few seconds of sound. The value $FFFF signals the end of a sound and most values are between the range $0100-$5000. $0000 is silence.

Later games use a similar format for PC and Adlib sounds, the sound data is in bytes with values of 0-255, the loss of fine-tuning being attributable to the lesser role of PC sounds and the Adlib format. The [[AudioT Format]] also has a totally different way of reading the sounds, and contains music.

== Notes ==

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

[[Category:All file formats]]
[[Category:Audio Files]]

[[Category:Catacomb]]
[[Category:Commander Keen 1-3]]
[[Category:Cosmo's Cosmic Adventures]]
[[Category:Dangerous Dave]]
[[Category:Dangerous Dave in Copyright Infringement]]
[[Category:Dangerous Dave 2]]
[[Category:Duke Nukem]]
[[Category:Duke Nukem II]]
[[Category:Hovertank 3-D]]
[[Category:Math Rescue]]
[[Category:Major Stryker]]
[[Category:Monster Bash]]
[[Category:Paragon]] 
[[Category:Pickle Wars]]
[[Category:Realms of Chaos]] 
[[Category:Rescue Rover]]
[[Category:Shadow Knights]]
[[Category:Slordax]]
[[Category:Word Rescue]]
[[Category:Xenopods]]

BNK Format (Halloween Harry)

2012-05-05T09:10:57Z

Eros: Added links to data types.

{{Stub}}

The '''BNK (Bank) group format''' is the format used by [[Halloween Harry]] to store a number of related game files. The format is trivial, being a collection of concurrent file chunks. Each BNK file has an associated FAT (Fila Allocation Table) file that provides quick access to the filenames, offset in the BNK file and size of the files stored in the BNK file. The FAT file however is usually not necessary to read data from the BNK file, all required information can be obtained by simply scanning said BNK file.

Files in the BNK file may or may not be compressed. This depends on what version of the BNK format is being used.

== File format ==

=== Signature ===

Each ''file entry'' begins with a signature, so the very first file entry's signature can be used to verify the main file in in .BNK format. This means at offset zero, there should be a character of code 0x04, followed by the four characters "-ID-" (see ''file entry'' below for more details.)

{|class="wikitable"
!Data type!!Description
|-
|[[BYTE]] cSignature[5]||"\x04-ID-" (not NULL-terminated)
|}

Note that there are two versions of the .BNK format - the original [[Halloween Harry]] version (with no compression) and the later [[Alien Carnage]] version (with compression.) The version can be detected by using the following method:

# Read in the first file header (see ''file entry'' below), in Halloween Harry format (i.e. pretend the ''iDecompressedSize'' field was not present.)
# Use that information to jump to the second file within the main .BNK file.
# Check for the "-ID-" signature at the start of the second file entry. If it's there (at the expected offset), then it's a non-compressed Halloween Harry .BNK file.
# If the "-ID-" signature is missing, try again four bytes further in (making up for the ''iDecompressedSize'' field that we ignored in the first step.)
# If the "-ID-" signature is now present, it's a compressed Alien Carnage .BNK file.
# If the "-ID-" signature still can't be found, it's not a valid .BNK file :-)
# It is also possible to determine the type by looking at the *.FAT file length. A length divisible by 21 is HH format, one divisible by 25 is AC format.

=== FAT format ===

An external file (with the same name as the BNK file but with a .FAT extension) stores a summary of the files in the BNK file. It also stores file offsets for quick access. This file is not necessary to read the BNK archive (since the filenames are stored in both places) however it can provide a faster alternative for listing files compared to scanning through the entire BNK file. Of course if a BNK file is to be modified, then the FAT file will also need to be updated.

A FAT entry consists of a filename, offset and size.

{|class="wikitable"
!Data type!!Description
|-
|[[UINT8]] iNameLength||Length of the filename
|-
|[[char]] cFilename[12]||Filename, 12 chars long, but the name itself is only iNameLength characters long. Not NULL-terminated.
|-
|[[UINT32LE]] iFileOffset||Offset of the file from the start of the BNK
|-
|[[UINT32LE]] iFileSize||Size of the file in bytes
|-
|[[UINT32LE]] iDecompressedSize||''Alien Carnage only:'' Size of the file in bytes, once it has been decompressed (this field is not present in Halloween Harry) - ''TODO: Confirm this is where it is stored in AC''
|-
|}

The very first file entry is at offset zero, and the above structure is repeated back-to-back until there are no more files. The offset given for each file is to the start of the file data itself, just after the header (in other words, the offset points to <tt>cData</tt> in the structure below.)

=== File entry ===

Each file entry in the BNK is similar to the entry in the external FAT file, with the addition of a signature and the omission of the offset, and of course the actual file data as well.

{|class="wikitable"
!Data type!!Description
|-
|[[BYTE]] cSignature[5]||"\x04-ID-" (not NULL-terminated)
|-
|[[UINT8]] iNameLength||Length of the filename
|-
|[[char]] cFilename[12]||Filename, 12 chars long, but the name itself is only iNameLength characters long. Not NULL-terminated.
|-
|[[UINT32LE]] iFileSize||Size of the file in bytes
|-
|[[UINT32LE]] iDecompressedSize||''Alien Carnage only:'' Size of the file in bytes, once it has been decompressed (this field is not present in Halloween Harry)
|-
|[[BYTE]] cData[iFileSize]||File data
|-
|}

The very first file entry is at offset zero, and the above structure is repeated back-to-back until there is no more data in the .BNK file.

=== Compression format ===

TODO (this is available from programs like ACEXTRACT)

== Tools ==

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

== Credits ==

This file format was reverse engineered by [[User:Malvineous|Malvineous]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

[[Category:Halloween Harry]]
[[Category:File Formats]]
[[Category:Group Files]]
[[Category:Group Files with embedded FAT]]
[[Category:Group Files with external FAT]]

Raw CGA Data

2012-05-05T08:53:08Z

Eros: /* Interlaced CGA data */ Added table. May need revising.

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

== Linear CGA data ==

For CGA tiles, one byte stores the color information for four pixels. Since the tile has 64 pixels (8×8), each tile takes up 16 bytes.

There are four possible combinations of 2 bits (2^2). The actual colors for each pixel depend on the active CGA palette, of which there are three basic ones. See [[wp:Color Graphics Adapter]] for details. Every game can use the four color palette differently. [[Catacomb]] uses color palette 1 with high intensity.

This data represents one tile from Catacomb:
FF FF FF FF FD 7F F6 9F F6 9F FD 7F FF FF FF FF

Expanded into bits for an 8×8 tile:
11 11 11 11 11 11 11 11
11 11 11 11 11 11 11 11
11 11 11 01 01 11 11 11
11 11 01 10 10 01 11 11
11 11 01 10 10 01 11 11
11 11 11 01 01 11 11 11
11 11 11 11 11 11 11 11
11 11 11 11 11 11 11 11

With color palette 1i, each pair of bits represents a different color:
{| class="wikitable"
!Bits!!Color
|-
|00
|style="color: white; background-color: #000000" | black
|-
|01
|style="color: black; background-color: #55FFFF" | light cyan
|-
|10
|style="color: black; background-color: #FF55FF" | light magenta
|-
|11
|style="color: black; background-color: #FFFFFF" | white
|}

Resulting Image (actual size):
[[File:catacomb_cgatile.png]]
Resulting Image (8× the size):
[[File:catacomb_cgatile_hd.png]]

== Interlaced CGA Data ==

<table class="wikitable" style="float: right; margin: 1em;">
<caption align="bottom">Offsets into file data</caption>
<tr>
<th rowspan="2">Line (Y)</th>
<th rowspan="2">Plane</th>
<th colspan="4">Column (X)</th>
</tr>
<tr>
<th>0-3</th>
<th>4-7</th>
<th>8-11</th>
<th>12-15</th>
</tr>
<tr>
<td>0</td>
<td>0</td>
<td style="background-color: #000000; color: white;">00</td>
<td style="background-color: #000000; color: white;">01</td>
<td style="background-color: #000000; color: white;">02</td>
<td style="background-color: #000000; color: white;">03</td>
</tr>
<tr>
<td>1</td>
<td>1</td>
<td style="background-color: #FFFFFF; color: black;">10</td>
<td style="background-color: #FFFFFF; color: black;">11</td>
<td style="background-color: #FFFFFF; color: black;">12</td>
<td style="background-color: #FFFFFF; color: black;">13</td>
</tr>
<tr>
<td>2</td>
<td>0</td>
<td style="background-color: #000000; color: white;">04</td>
<td style="background-color: #000000; color: white;">05</td>
<td style="background-color: #000000; color: white;">06</td>
<td style="background-color: #000000; color: white;">07</td>
</tr>
<tr>
<td>3</td>
<td>1</td>
<td style="background-color: #FFFFFF; color: black;">14</td>
<td style="background-color: #FFFFFF; color: black;">15</td>
<td style="background-color: #FFFFFF; color: black;">16</td>
<td style="background-color: #FFFFFF; color: black;">17</td>
</tr>
<tr>
<td>4</td>
<td>0</td>
<td style="background-color: #000000; color: white;">08</td>
<td style="background-color: #000000; color: white;">09</td>
<td style="background-color: #000000; color: white;">0A</td>
<td style="background-color: #000000; color: white;">0B</td>
</tr>
<tr>
<td>5</td>
<td>1</td>
<td style="background-color: #FFFFFF; color: black;">18</td>
<td style="background-color: #FFFFFF; color: black;">19</td>
<td style="background-color: #FFFFFF; color: black;">1A</td>
<td style="background-color: #FFFFFF; color: black;">1B</td>
</tr>
<tr>
<td>6</td>
<td>0</td>
<td style="background-color: #000000; color: white;">0C</td>
<td style="background-color: #000000; color: white;">0D</td>
<td style="background-color: #000000; color: white;">0E</td>
<td style="background-color: #000000; color: white;">0F</td>
</tr>
<tr>
<td>7</td>
<td>1</td>
<td style="background-color: #FFFFFF; color: black;">1C</td>
<td style="background-color: #FFFFFF; color: black;">1D</td>
<td style="background-color: #FFFFFF; color: black;">1E</td>
<td style="background-color: #FFFFFF; color: black;">1F</td>
</tr>
</table>

This arrangement stores the image data in two halves - even lines and odd lines.

It is essentially two black-and-white (1bpp) images one after the other, each half the height of the total picture. The first image is drawn on lines 0, 2, 4, etc. and the second image is drawn on lines 1, 3, 5, etc. to produce the final picture. Each row of data is in the same arrangement as [[#Linear CGA data]] above.

A 16×8 image in this arrangement is described in the table on the right. The byte at index <tt>00</tt> contains the first eight-pixels in the image, and the byte at offset <tt>15</tt> contains the second four pixels on the fourth line.

=== Full-Screen Images ===

<table class="wikitable" style="float: left; margin: 2 auto;">
<caption align="bottom">Full Screen [[PIC Format|PIC]] Image Format</caption>
<tr><th>File Offset</th><th>Size</th><th>Description</th><tr>
<tr><td>0x0000</td><td>0x1F40</td><td>Pixel data (even lines)</td></tr>
<tr style="background-color: #DEDEDE;"><td>0x1F40</td><td>0x00C0</td><td>Padding Block</td></tr>
<tr><td>0x2000</td><td>0x1F40</td><td>Pixel data (odd lines)</td></tr>
<tr style="background-color: #DEDEDE;"><td>0x3F40</td><td>0x00C0</td><td>Padding Block</td></tr>
</table>

Many full screen CGA images store their data in interlaced format, so that they can be loaded directly into video memory without any additional processing. In some of these cases however, the data is loaded in one operation for the entire image rather than two operations (one per plane.)

This is significant because in 320×200 mode, each plane occupies 8000 bytes of memory, leading to 16000 bytes for the entire image. However because the planes are aligned in CGA memory, the second plane actually starts at offset 8192 into memory, not at offset 8000.

This means that file formats which load an image in a single operation will have 192 bytes of padding between the planes (and possibly 192 bytes after the last plane), which should be ignored when processing the image.

A quick way to tell is to look at the image size. If it is 16000 bytes, it contains two planes with no padding, and if it is 16192 or 16384 bytes then it contains padding between planes.

<br style="clear: both;"/>

== CGA palettes ==

<table class="wikitable" style="float: right; margin: 1em;">
<caption align="bottom">RGB values of CGA palettes</caption>
<tr>
<th rowspan="2">Colour index</th>
<th colspan="6">Palette</th>
</tr>
<tr>
<th>0</th>
<th>0i</th>
<th>1</th>
<th>1i</th>
<th>2</th>
<th>2i</th>
</tr>
<tr>
<td>0</td>
<td colspan="6" style="background-color: #000000; color: white; text-align: center;">Application-specific (default #000000)</td>
</tr>
<tr>
<td>1</td>
<td style="background-color: #00AA00; color: white;">#00AA00</td>
<td style="background-color: #55FF55; color: black;">#55FF55</td>
<td style="background-color: #00AAAA; color: white;">#00AAAA</td>
<td style="background-color: #55FFFF; color: black;">#55FFFF</td>
<td style="background-color: #00AAAA; color: white;">#00AAAA</td>
<td style="background-color: #55FFFF; color: black;">#55FFFF</td>
</tr>
<tr>
<td>2</td>
<td style="background-color: #AA0000; color: white;">#AA0000</td>
<td style="background-color: #FF5555; color: black;">#FF5555</td>
<td style="background-color: #AA00AA; color: white;">#AA00AA</td>
<td style="background-color: #FF55FF; color: black;">#FF55FF</td>
<td style="background-color: #AA0000; color: white;">#AA0000</td>
<td style="background-color: #FF5555; color: black;">#FF5555</td>
</tr>
<tr>
<td>3</td>
<td style="background-color: #AA5500; color: white;">#AA5500</td>
<td style="background-color: #FFFF55; color: black;">#FFFF55</td>
<td style="background-color: #AAAAAA; color: white;">#AAAAAA</td>
<td style="background-color: #FFFFFF; color: black;">#FFFFFF</td>
<td style="background-color: #AAAAAA; color: white;">#AAAAAA</td>
<td style="background-color: #FFFFFF; color: black;">#FFFFFF</td>
</tr>
</table>

The actual RGB values that correspond to each colour value depend on the palette in use by the game. This table lists the RGB values for all the CGA palettes.

[[Category:Articles]]
[[Category:File Formats]]

Talk:Raw CGA Data

2012-05-05T08:31:58Z

Eros: More info?

: Should we add the information for full screen images from the [[PIC Format]] page? The Location | Size | Description chart would be nice (formatted into a table of course). [[User:Eros|Eros]] 08:31, 5 May 2012 (GMT)

Raw CGA Data

2012-05-05T08:14:17Z

Eros: /* Linear CGA data */ Added preview for high quality version.

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

== Linear CGA data ==

For CGA tiles, one byte stores the color information for four pixels. Since the tile has 64 pixels (8×8), each tile takes up 16 bytes.

There are four possible combinations of 2 bits (2^2). The actual colors for each pixel depend on the active CGA palette, of which there are three basic ones. See [[wp:Color Graphics Adapter]] for details. Every game can use the four color palette differently. [[Catacomb]] uses color palette 1 with high intensity.

This data represents one tile from Catacomb:
FF FF FF FF FD 7F F6 9F F6 9F FD 7F FF FF FF FF

Expanded into bits for an 8×8 tile:
11 11 11 11 11 11 11 11
11 11 11 11 11 11 11 11
11 11 11 01 01 11 11 11
11 11 01 10 10 01 11 11
11 11 01 10 10 01 11 11
11 11 11 01 01 11 11 11
11 11 11 11 11 11 11 11
11 11 11 11 11 11 11 11

With color palette 1i, each pair of bits represents a different color:
{| class="wikitable"
!Bits!!Color
|-
|00
|style="color: white; background-color: #000000" | black
|-
|01
|style="color: black; background-color: #55FFFF" | light cyan
|-
|10
|style="color: black; background-color: #FF55FF" | light magenta
|-
|11
|style="color: black; background-color: #FFFFFF" | white
|}

Resulting Image (actual size):
[[File:catacomb_cgatile.png]]
Resulting Image (8× the size):
[[File:catacomb_cgatile_hd.png]]

== Planar CGA data ==

<table class="wikitable" style="float: right; margin: 1em;">
<caption align="bottom">Offsets into file data</caption>
<tr>
<th rowspan="2">Pixels</th>
<th colspan="4">Plane</th>
</tr>
<tr>
<th>0</th>
<th>1</th>
</tr>
<tr>
<td>(0,0) to (7,0)</td>
<td style="background-color: #000000; color: white;">00</td>
<td style="background-color: #FFFFFF; color: black;">10</td>
</tr>
<tr>
<td>(8,0) to (15,0)</td>
<td style="background-color: #000000; color: white;">01</td>
<td style="background-color: #FFFFFF; color: black;">11</td>
</tr>
<tr>
<td>(0,1) to (7,1)</td>
<td style="background-color: #000000; color: white;">02</td>
<td style="background-color: #FFFFFF; color: black;">12</td>
</tr>
<tr>
<td>(8,1) to (15,1)</td>
<td style="background-color: #000000; color: white;">03</td>
<td style="background-color: #FFFFFF; color: black;">13</td>
</tr>
<tr>
<td>(0,2) to (7,2)</td>
<td style="background-color: #000000; color: white;">04</td>
<td style="background-color: #FFFFFF; color: black;">14</td>
</tr>
<tr>
<td>(8,2) to (15,2)</td>
<td style="background-color: #000000; color: white;">05</td>
<td style="background-color: #FFFFFF; color: black;">15</td>
</tr>
<tr>
<td>(0,3) to (7,3)</td>
<td style="background-color: #000000; color: white;">06</td>
<td style="background-color: #FFFFFF; color: black;">16</td>
</tr>
<tr>
<td>(8,3) to (15,3)</td>
<td style="background-color: #000000; color: white;">07</td>
<td style="background-color: #FFFFFF; color: black;">17</td>
</tr>
<tr>
<td>(0,4) to (7,4)</td>
<td style="background-color: #000000; color: white;">08</td>
<td style="background-color: #FFFFFF; color: black;">18</td>
</tr>
<tr>
<td>(8,4) to (15,4)</td>
<td style="background-color: #000000; color: white;">09</td>
<td style="background-color: #FFFFFF; color: black;">19</td>
</tr>
<tr>
<td>(0,5) to (7,5)</td>
<td style="background-color: #000000; color: white;">0A</td>
<td style="background-color: #FFFFFF; color: black;">1A</td>
</tr>
<tr>
<td>(8,5) to (15,5)</td>
<td style="background-color: #000000; color: white;">0B</td>
<td style="background-color: #FFFFFF; color: black;">1B</td>
</tr>
<tr>
<td>(0,6) to (7,6)</td>
<td style="background-color: #000000; color: white;">0C</td>
<td style="background-color: #FFFFFF; color: black;">1C</td>
</tr>
<tr>
<td>(8,6) to (15,6)</td>
<td style="background-color: #000000; color: white;">0D</td>
<td style="background-color: #FFFFFF; color: black;">1D</td>
</tr>
<tr>
<td>(0,7) to (7,7)</td>
<td style="background-color: #000000; color: white;">0E</td>
<td style="background-color: #FFFFFF; color: black;">1E</td>
</tr>
<tr>
<td>(8,7) to (15,7)</td>
<td style="background-color: #000000; color: white;">0F</td>
<td style="background-color: #FFFFFF; color: black;">1F</td>
</tr>
</table>

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

It is essentially two black-and-white (1bpp) images one after the other. Combining the bits for each pixel produce a value between 0 and 3 inclusive, which are then used as an index into the palette.

A 16×8 image in this arrangement is described in the table on the right. The bytes at indices <tt>00</tt> and <tt>10</tt> together provide values for the first eight pixels in the image.

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

=== Full-screen images ===

Many full screen CGA images store their data in planar format, so that they can be loaded directly into video memory without any additional processing. In some of these cases however, the data is loaded in one operation for the entire image rather than two operations (one per plane.)

This is significant because in 320×200 mode, each plane occupies 8000 bytes of memory, leading to 16000 bytes for the entire image. However because the planes are aligned in CGA memory, the second plane actually starts at offset 8192 into memory, not at offset 8000.

This means that file formats which load an image in a single operation will have 192 bytes of padding between the planes (and possibly 192 bytes after the last plane), which should be ignored when processing the image.

A quick way to tell is to look at the image size. If it is 16000 bytes, it contains two planes with no padding, and if it is 16192 or 16384 bytes then it contains padding between planes.
<br style="clear: both;"/>

== CGA palettes ==

<table class="wikitable" style="float: right; margin: 1em;">
<caption align="bottom">RGB values of CGA palettes</caption>
<tr>
<th rowspan="2">Colour index</th>
<th colspan="6">Palette</th>
</tr>
<tr>
<th>0</th>
<th>0i</th>
<th>1</th>
<th>1i</th>
<th>2</th>
<th>2i</th>
</tr>
<tr>
<td>0</td>
<td colspan="6" style="background-color: #000000; color: white; text-align: center;">Application-specific (default #000000)</td>
</tr>
<tr>
<td>1</td>
<td style="background-color: #00AA00; color: white;">#00AA00</td>
<td style="background-color: #55FF55; color: black;">#55FF55</td>
<td style="background-color: #00AAAA; color: white;">#00AAAA</td>
<td style="background-color: #55FFFF; color: black;">#55FFFF</td>
<td style="background-color: #00AAAA; color: white;">#00AAAA</td>
<td style="background-color: #55FFFF; color: black;">#55FFFF</td>
</tr>
<tr>
<td>2</td>
<td style="background-color: #AA0000; color: white;">#AA0000</td>
<td style="background-color: #FF5555; color: black;">#FF5555</td>
<td style="background-color: #AA00AA; color: white;">#AA00AA</td>
<td style="background-color: #FF55FF; color: black;">#FF55FF</td>
<td style="background-color: #AA0000; color: white;">#AA0000</td>
<td style="background-color: #FF5555; color: black;">#FF5555</td>
</tr>
<tr>
<td>3</td>
<td style="background-color: #AA5500; color: white;">#AA5500</td>
<td style="background-color: #FFFF55; color: black;">#FFFF55</td>
<td style="background-color: #AAAAAA; color: white;">#AAAAAA</td>
<td style="background-color: #FFFFFF; color: black;">#FFFFFF</td>
<td style="background-color: #AAAAAA; color: white;">#AAAAAA</td>
<td style="background-color: #FFFFFF; color: black;">#FFFFFF</td>
</tr>
</table>

The actual RGB values that correspond to each colour value depend on the palette in use by the game. This table lists the RGB values for all the CGA palettes.

[[Category:Articles]]
[[Category:File Formats]]

File:Catacomb cgatile hd.png

2012-05-05T08:13:40Z

Eros: Used for example on how to read CGA data. One of the first tiles in the Catacomb CGA tile-set. Higher quality for clarity.

Used for example on how to read CGA data.

One of the first tiles in the [[Catacomb]] CGA tile-set.

Higher quality for clarity.

Raw CGA Data

2012-05-05T08:02:16Z

Eros: /* Linear CGA data */ Changed to 1i for consistency.

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

== Linear CGA data ==

For CGA tiles, one byte stores the color information for four pixels. Since the tile has 64 pixels (8×8), each tile takes up 16 bytes.

There are four possible combinations of 2 bits (2^2). The actual colors for each pixel depend on the active CGA palette, of which there are three basic ones. See [[wp:Color Graphics Adapter]] for details. Every game can use the four color palette differently. [[Catacomb]] uses color palette 1 with high intensity.

This data represents one tile from Catacomb:
FF FF FF FF FD 7F F6 9F F6 9F FD 7F FF FF FF FF

Expanded into bits for an 8×8 tile:
11 11 11 11 11 11 11 11
11 11 11 11 11 11 11 11
11 11 11 01 01 11 11 11
11 11 01 10 10 01 11 11
11 11 01 10 10 01 11 11
11 11 11 01 01 11 11 11
11 11 11 11 11 11 11 11
11 11 11 11 11 11 11 11

With color palette 1i, each pair of bits represents a different color:
{| class="wikitable"
!Bits!!Color
|-
|00
|style="color: white; background-color: #000000" | black
|-
|01
|style="color: black; background-color: #55FFFF" | light cyan
|-
|10
|style="color: black; background-color: #FF55FF" | light magenta
|-
|11
|style="color: black; background-color: #FFFFFF" | white
|}

Resulting Image: [[File:catacomb_cgatile.png]]

== Planar CGA data ==

<table class="wikitable" style="float: right; margin: 1em;">
<caption align="bottom">Offsets into file data</caption>
<tr>
<th rowspan="2">Pixels</th>
<th colspan="4">Plane</th>
</tr>
<tr>
<th>0</th>
<th>1</th>
</tr>
<tr>
<td>(0,0) to (7,0)</td>
<td style="background-color: #000000; color: white;">00</td>
<td style="background-color: #FFFFFF; color: black;">10</td>
</tr>
<tr>
<td>(8,0) to (15,0)</td>
<td style="background-color: #000000; color: white;">01</td>
<td style="background-color: #FFFFFF; color: black;">11</td>
</tr>
<tr>
<td>(0,1) to (7,1)</td>
<td style="background-color: #000000; color: white;">02</td>
<td style="background-color: #FFFFFF; color: black;">12</td>
</tr>
<tr>
<td>(8,1) to (15,1)</td>
<td style="background-color: #000000; color: white;">03</td>
<td style="background-color: #FFFFFF; color: black;">13</td>
</tr>
<tr>
<td>(0,2) to (7,2)</td>
<td style="background-color: #000000; color: white;">04</td>
<td style="background-color: #FFFFFF; color: black;">14</td>
</tr>
<tr>
<td>(8,2) to (15,2)</td>
<td style="background-color: #000000; color: white;">05</td>
<td style="background-color: #FFFFFF; color: black;">15</td>
</tr>
<tr>
<td>(0,3) to (7,3)</td>
<td style="background-color: #000000; color: white;">06</td>
<td style="background-color: #FFFFFF; color: black;">16</td>
</tr>
<tr>
<td>(8,3) to (15,3)</td>
<td style="background-color: #000000; color: white;">07</td>
<td style="background-color: #FFFFFF; color: black;">17</td>
</tr>
<tr>
<td>(0,4) to (7,4)</td>
<td style="background-color: #000000; color: white;">08</td>
<td style="background-color: #FFFFFF; color: black;">18</td>
</tr>
<tr>
<td>(8,4) to (15,4)</td>
<td style="background-color: #000000; color: white;">09</td>
<td style="background-color: #FFFFFF; color: black;">19</td>
</tr>
<tr>
<td>(0,5) to (7,5)</td>
<td style="background-color: #000000; color: white;">0A</td>
<td style="background-color: #FFFFFF; color: black;">1A</td>
</tr>
<tr>
<td>(8,5) to (15,5)</td>
<td style="background-color: #000000; color: white;">0B</td>
<td style="background-color: #FFFFFF; color: black;">1B</td>
</tr>
<tr>
<td>(0,6) to (7,6)</td>
<td style="background-color: #000000; color: white;">0C</td>
<td style="background-color: #FFFFFF; color: black;">1C</td>
</tr>
<tr>
<td>(8,6) to (15,6)</td>
<td style="background-color: #000000; color: white;">0D</td>
<td style="background-color: #FFFFFF; color: black;">1D</td>
</tr>
<tr>
<td>(0,7) to (7,7)</td>
<td style="background-color: #000000; color: white;">0E</td>
<td style="background-color: #FFFFFF; color: black;">1E</td>
</tr>
<tr>
<td>(8,7) to (15,7)</td>
<td style="background-color: #000000; color: white;">0F</td>
<td style="background-color: #FFFFFF; color: black;">1F</td>
</tr>
</table>

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

It is essentially two black-and-white (1bpp) images one after the other. Combining the bits for each pixel produce a value between 0 and 3 inclusive, which are then used as an index into the palette.

A 16×8 image in this arrangement is described in the table on the right. The bytes at indices <tt>00</tt> and <tt>10</tt> together provide values for the first eight pixels in the image.

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

=== Full-screen images ===

Many full screen CGA images store their data in planar format, so that they can be loaded directly into video memory without any additional processing. In some of these cases however, the data is loaded in one operation for the entire image rather than two operations (one per plane.)

This is significant because in 320×200 mode, each plane occupies 8000 bytes of memory, leading to 16000 bytes for the entire image. However because the planes are aligned in CGA memory, the second plane actually starts at offset 8192 into memory, not at offset 8000.

This means that file formats which load an image in a single operation will have 192 bytes of padding between the planes (and possibly 192 bytes after the last plane), which should be ignored when processing the image.

A quick way to tell is to look at the image size. If it is 16000 bytes, it contains two planes with no padding, and if it is 16192 or 16384 bytes then it contains padding between planes.
<br style="clear: both;"/>

== CGA palettes ==

<table class="wikitable" style="float: right; margin: 1em;">
<caption align="bottom">RGB values of CGA palettes</caption>
<tr>
<th rowspan="2">Colour index</th>
<th colspan="6">Palette</th>
</tr>
<tr>
<th>0</th>
<th>0i</th>
<th>1</th>
<th>1i</th>
<th>2</th>
<th>2i</th>
</tr>
<tr>
<td>0</td>
<td colspan="6" style="background-color: #000000; color: white; text-align: center;">Application-specific (default #000000)</td>
</tr>
<tr>
<td>1</td>
<td style="background-color: #00AA00; color: white;">#00AA00</td>
<td style="background-color: #55FF55; color: black;">#55FF55</td>
<td style="background-color: #00AAAA; color: white;">#00AAAA</td>
<td style="background-color: #55FFFF; color: black;">#55FFFF</td>
<td style="background-color: #00AAAA; color: white;">#00AAAA</td>
<td style="background-color: #55FFFF; color: black;">#55FFFF</td>
</tr>
<tr>
<td>2</td>
<td style="background-color: #AA0000; color: white;">#AA0000</td>
<td style="background-color: #FF5555; color: black;">#FF5555</td>
<td style="background-color: #AA00AA; color: white;">#AA00AA</td>
<td style="background-color: #FF55FF; color: black;">#FF55FF</td>
<td style="background-color: #AA0000; color: white;">#AA0000</td>
<td style="background-color: #FF5555; color: black;">#FF5555</td>
</tr>
<tr>
<td>3</td>
<td style="background-color: #AA5500; color: white;">#AA5500</td>
<td style="background-color: #FFFF55; color: black;">#FFFF55</td>
<td style="background-color: #AAAAAA; color: white;">#AAAAAA</td>
<td style="background-color: #FFFFFF; color: black;">#FFFFFF</td>
<td style="background-color: #AAAAAA; color: white;">#AAAAAA</td>
<td style="background-color: #FFFFFF; color: black;">#FFFFFF</td>
</tr>
</table>

The actual RGB values that correspond to each colour value depend on the palette in use by the game. This table lists the RGB values for all the CGA palettes.

[[Category:Articles]]
[[Category:File Formats]]

File:Catacomb cgatile.png

2012-05-02T13:11:59Z

Eros: Added more information

Used for example on how to read CGA data.

One of the first tiles in the [[Catacomb]] CGA tile-set.

Raw CGA Data

2012-05-02T13:09:10Z

Eros: Added placeholder section

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

== 2bpp Linear CGA Tile Data ==

For CGA tiles, one byte stores the color information for four pixels. Since the tile has 64 pixels (8×8), each tile takes up 16 bytes.

There are four possible combinations of 2 bits (2^2). The actual colors for each pixel depend on the active CGA palette, of which there are three basic ones. See [[wp:Color Graphics Adapter]] for details. Every game can use the four color palette differently. [[Catacomb]] uses color palette 1 with high intensity.

This data represents one tile from Catacomb:
FF FF FF FF FD 7F F6 9F F6 9F FD 7F FF FF FF FF

Expanded into bits for an 8×8 tile:
11 11 11 11 11 11 11 11
11 11 11 11 11 11 11 11
11 11 11 01 01 11 11 11
11 11 01 10 10 01 11 11
11 11 01 10 10 01 11 11
11 11 11 01 01 11 11 11
11 11 11 11 11 11 11 11
11 11 11 11 11 11 11 11

With color palette 1, each pair of bits represents a different color:
{| class="wikitable"
!Bits!!Color
|-
|00
|style="color: white; background-color: #000000" | black
|-
|01
|style="color: black; background-color: #55FFFF" | light cyan
|-
|10
|style="color: black; background-color: #FF55FF" | light magenta
|-
|11
|style="color: black; background-color: #FFFFFF" | white
|}

Resulting Image: [[File:catacomb_cgatile.png]]

== 2bpp Non-Linear CGA PIC Data ==

{{TODO|Add information from [[PIC Format]] here?}}

[[Category:Articles]]
[[Category:Graphics Files]]
[[Category:Catacomb 3D]]
[[Category:File Formats]]

Raw CGA Data

2012-05-02T12:44:49Z

Eros: Added table with colors.

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

== 2bpp Linear CGA Tile Data ==

For CGA tiles, one byte stores the color information for four pixels. Since the tile has 64 pixels (8×8), each tile takes up 16 bytes.

There are four possible combinations of 2 bits (2^2). The actual colors for each pixel depend on the active CGA palette, of which there are three basic ones. See [[wp:Color Graphics Adapter]] for details. Every game can use the four color palette differently. [[Catacomb]] uses color palette 1 with high intensity.

This data represents one tile from Catacomb:
FF FF FF FF FD 7F F6 9F F6 9F FD 7F FF FF FF FF

Expanded into bits for an 8×8 tile:
11 11 11 11 11 11 11 11
11 11 11 11 11 11 11 11
11 11 11 01 01 11 11 11
11 11 01 10 10 01 11 11
11 11 01 10 10 01 11 11
11 11 11 01 01 11 11 11
11 11 11 11 11 11 11 11
11 11 11 11 11 11 11 11

With color palette 1, each pair of bits represents a different color:
{| class="wikitable"
!Bits!!Color
|-
|00
|style="color: white; background-color: #000000" | black
|-
|01
|style="color: black; background-color: #55FFFF" | light cyan
|-
|10
|style="color: black; background-color: #FF55FF" | light magenta
|-
|11
|style="color: black; background-color: #FFFFFF" | white
|}

Resulting Image: [[File:catacomb_cgatile.png]]

[[Category:Articles]]
[[Category:Graphics Files]]
[[Category:Catacomb 3D]]
[[Category:File Formats]]

Catacomb Tileset Format

2012-05-02T12:37:36Z

Eros: Linking 2bpp linear.

{{Tileset Infobox
| Hardware1 = CGA
| Hardware2 = EGA
| MaxTiles = Unlimited
| Palette = Default CGA/EGA
| Names = N
| TileMinSize = 8×8
| TileMaxSize = 8×8
| NumPlanes = 4
| PlaneArrangement = CGA: [[2bpp linear]], EGA: [[Raw EGA data#Graphic-planar EGA data|Graphic-planar]]
| HasTransparency = N
| HasHitmap = N
| Metadata = None
| Subtilesets = N
| Compressed = N
| Hidden = N
| Game1 = Catacomb
| Game2 = Catacomb II
}}
The '''Catacomb Tileset Format''' is used in both [[Catacomb]] and [[Catacomb II]] to store 8×8 pixel tiles used for drawing the game levels. The format can be used to store both CGA and EGA data, with each type stored in separate files named <tt>CGACHARS.xxx</tt> and <tt>EGACHARS.xxx</tt>. This format is similar to the font data in the [[XGAPics Format|xGAPICS]] files, which obsoleted the xGACHARS format in later games.

[[Catacomb II]] uses the tiles from <tt>xGAPICS.CA2</tt> to draw text onto the screen, not the ones from <tt>xGACHARS.CA2</tt>. {{TODO|What does this mean? The xGACHARS file should be used for drawing text in a level.}}

== File format ==

The file contains raw graphics data and has no header, so you'll need to calculate the number of tiles yourself.

For the CGA, one byte stores the color information for four pixels. Since the tile has 64 pixels (8×8), each tile takes up 16 bytes.

For the EGA, one byte can only store two pixels (regardless of the plane's order), so you need 32 bytes per tile. This gives you the following two formulae to calculate the tile count:

num_ega_tiles = filesize / 32
num_cga_tiles = filesize / 16

For the CGA version, reading the CHARS is exactly the same ([[2bpp linear]]) as reading the font tiles from the CGAPICS file.

The EGA version is a bit different. In EGAPICS, you have one huge data block for each EGA plane ([[Raw_EGA_data|planar EGA data]]), where each block/plane contains data for all images. In the EGACHARS file, each tile has its own four planes, self contained within the 32 bytes for each tile ([[Raw_EGA_data#Graphic-planar_EGA_data|graphic-planar EGA data]]). This means you can read one single tile without having to scan through the whole file to get to the start of each plane.

== Notes ==

This file format was reverse engineered by [[User:K1n9_Duk3|K1n9_Duk3]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

King's Bounty Graphics Format

2012-05-02T12:34:48Z

Eros: Linking 2bpp linear.

[[King's Bounty]] stores all its graphics in external files in this format, packed into group files.

The CGA & EGA graphic files (4 and 16 colors) have the ".4" and ".16" extensions (<tt>title.4, title.16</tt>) and are kept in the <tt>416.CC</tt> file.

The VGA graphic files (256 colors) have the ".256" extension (<tt>title.256</tt>) and are kept in the <tt>256.CC</tt> file, except for <tt>endpic.256</tt>, which is kept in <tt>416.CC</tt> for some reason.

== Compression ==

All files are compressed as described in the [[CC Format]].

== File structure ==

The file starts with the number of chunks (graphics) in the file, followed by a number of values giving the offset of each chunk and a mask/color key offset.

If a graphic doesn't have a mask (background tile, title screen), the offset for the mask is 0x0000.

=== Header ===

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||count||Number of images in the file
|-
|struct Entry||entries[]||Array of image and mask offsets
|}

=== Graphic Entry ===

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||offset||Offset from start of file to image data
|-
|[[UINT16LE]]||mask_offset||Offset from start of file to mask data (0 if no mask)
|}

For VGA images, '''mask_offset''' points somewhere inside the image data, specifying which pixel should be treated as the color key.

== Image formats ==

=== Images ===

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||width||Image width, also pitch
|-
|[[UINT16LE]]||height||Image height
|-
|[[BYTE]]||data[]||Image data
|}

==== CGA ====

CGA data is [[2bpp linear]].

The actual colours for each pixel depend on the active CGA palette, the game allows up to 8 choices. See [[wp:Color Graphics Adapter]] for details.

==== EGA ====

Unlike many other DOS games, EGA data is linear too, 4bpp this time.

==== VGA ====

The VGA data is standard 8bpp single-plane data. The palette can be found in <tt>MCGA.DRV</tt> file, at offset <tt>0x032D</tt>. It's in [[VGA Palette|classic VGA format]] (6-bit RGB).

=== Masks ===

Masks are always linear 1bpp '''without''' the width and height data (the values of the actual image are used). Masks do not exist for VGA graphics, color keys are used instead (see above).

== Credits ==
Devised by the openkb project with best regards to the modding community.

[[Category: King's Bounty]]
[[Category: File Formats]]
[[Category: Graphics Files]]

Catacomb Tileset Format

2012-05-02T12:33:21Z

Eros: Linking 2bpp linear.

{{Tileset Infobox
| Hardware1 = CGA
| Hardware2 = EGA
| MaxTiles = Unlimited
| Palette = Default CGA/EGA
| Names = N
| TileMinSize = 8×8
| TileMaxSize = 8×8
| NumPlanes = 4
| PlaneArrangement = CGA: [[2bpp linear]], EGA: [[Raw EGA data#Graphic-planar EGA data|Graphic-planar]]
| HasTransparency = N
| HasHitmap = N
| Metadata = None
| Subtilesets = N
| Compressed = N
| Hidden = N
| Game1 = Catacomb
| Game2 = Catacomb II
}}
The '''Catacomb Tileset Format''' is used in both [[Catacomb]] and [[Catacomb II]] to store 8×8 pixel tiles used for drawing the game levels. The format can be used to store both CGA and EGA data, with each type stored in separate files named <tt>CGACHARS.xxx</tt> and <tt>EGACHARS.xxx</tt>. This format is similar to the font data in the [[XGAPics Format|xGAPICS]] files, which obsoleted the xGACHARS format in later games.

[[Catacomb II]] uses the tiles from <tt>xGAPICS.CA2</tt> to draw text onto the screen, not the ones from <tt>xGACHARS.CA2</tt>. {{TODO|What does this mean? The xGACHARS file should be used for drawing text in a level.}}

== File format ==

The file contains raw graphics data and has no header, so you'll need to calculate the number of tiles yourself.

For the CGA, one byte stores the color information for four pixels. Since the tile has 64 pixels (8×8), each tile takes up 16 bytes.

For the EGA, one byte can only store two pixels (regardless of the plane's order), so you need 32 bytes per tile. This gives you the following two formulae to calculate the tile count:

num_ega_tiles = filesize / 32
num_cga_tiles = filesize / 16

For the CGA version, reading the CHARS is exactly the same as reading the font tiles from the CGAPICS file.

The EGA version is a bit different. In EGAPICS, you have one huge data block for each EGA plane ([[Raw_EGA_data|planar EGA data]]), where each block/plane contains data for all images. In the EGACHARS file, each tile has its own four planes, self contained within the 32 bytes for each tile ([[Raw_EGA_data#Graphic-planar_EGA_data|graphic-planar EGA data]]). This means you can read one single tile without having to scan through the whole file to get to the start of each plane.

== Notes ==

This file format was reverse engineered by [[User:K1n9_Duk3|K1n9_Duk3]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

Dangerous Dave Tileset Format

2012-05-02T12:32:23Z

Eros: Linking 2bpp linear.

Apart from the interface graphics (menu, font, etc.) [[Dangerous Dave]] stores its graphics in three files in this format. The EGA graphics are stored externally in <tt>EGADAVE.DAV</tt>, while the CGA and VGA graphics are stored internally in <tt>DAVE.EXE</tt>.

These graphics in this format are the tiles and sprites, and most images used in-level. As Dangerous Dave is an early game, it does not always employ compression and uses a primitive method of storing the [[Raw EGA data]] in the file.

== Compression ==

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

The data is compressed using [[Keen 1-3 RLE compression]].

== File structure ==

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

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

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

== Image formats ==

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

11001001 (0xC9)

Would translate as four pixels of the following values:

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

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

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

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

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

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

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

== Credits ==

This file format and the EGA + VGA graphics were reverse engineered by [[User:Levellass|Levellass]], and the RLE algorithm and CGA graphics were reverse engineered by [[User:Malvineous|Malvineous]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

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

Linear CGA

2012-05-02T12:30:44Z

Eros: Set up redirect for 2bpp linear.

#REDIRECT [[Raw_CGA_Data#2bpp Linear CGA Tile Data]]

Raw CGA Data

2012-05-02T12:30:02Z

Eros: Renamed section

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

== 2bpp Linear CGA Tile Data ==

For CGA tiles, one byte stores the color information for four pixels. Since the tile has 64 pixels (8×8), each tile takes up 16 bytes.

There are four possible combinations of 2 bits (2^2). Therefore there are four possible colors in the [https://en.wikipedia.org/wiki/Color_Graphics_Adapter#Standard_graphics_modes CGA palette]. Every game can use the four color palette differently. [[Catacomb]] uses color palette 1 with high intensity.

This data represents one tile from Catacomb:
FF FF FF FF FD 7F F6 9F F6 9F FD 7F FF FF FF FF

Expanded into bits for an 8×8 tile:
11 11 11 11 11 11 11 11
11 11 11 11 11 11 11 11
11 11 11 01 01 11 11 11
11 11 01 10 10 01 11 11
11 11 01 10 10 01 11 11
11 11 11 01 01 11 11 11
11 11 11 11 11 11 11 11
11 11 11 11 11 11 11 11

With color palette 1, each pair of bits represents a different color:
00 = black
01 = cyan
10 = magenta
11 = white

Resulting Image: [[File:catacomb_cgatile.png]]

[[Category:Articles]]
[[Category:Graphics Files]]
[[Category:Catacomb 3D]]
[[Category:File Formats]]

Raw CGA data

2012-05-02T12:28:46Z

Eros: moved Raw CGA data to Raw CGA Data: Capitalization

#REDIRECT [[Raw CGA Data]]

Raw CGA Data

2012-05-02T12:28:46Z

Eros: moved Raw CGA data to Raw CGA Data: Capitalization

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

== 2bpp CGA tile data ==

For CGA tiles, one byte stores the color information for four pixels. Since the tile has 64 pixels (8×8), each tile takes up 16 bytes.

There are four possible combinations of 2 bits (2^2). Therefore there are four possible colors in the [https://en.wikipedia.org/wiki/Color_Graphics_Adapter#Standard_graphics_modes CGA palette]. Every game can use the four color palette differently. [[Catacomb]] uses color palette 1 with high intensity.

This data represents one tile from Catacomb:
FF FF FF FF FD 7F F6 9F F6 9F FD 7F FF FF FF FF

Expanded into bits for an 8×8 tile:
11 11 11 11 11 11 11 11
11 11 11 11 11 11 11 11
11 11 11 01 01 11 11 11
11 11 01 10 10 01 11 11
11 11 01 10 10 01 11 11
11 11 11 01 01 11 11 11
11 11 11 11 11 11 11 11
11 11 11 11 11 11 11 11

With color palette 1, each pair of bits represents a different color:
00 = black
01 = cyan
10 = magenta
11 = white

Resulting Image: [[File:catacomb_cgatile.png]]

[[Category:Articles]]
[[Category:Graphics Files]]
[[Category:Catacomb 3D]]
[[Category:File Formats]]

File:Catacomb cgatile.png

2012-05-02T12:24:59Z

Eros: Used for example.

Used for example.

Raw CGA Data

2012-05-02T12:24:28Z

Eros: First version of CGA 2bpp tile data.

Dangerous Dave Level format

2012-05-01T13:39:17Z

Eros: Linking UNLZEXE

{{NeedMoreInfo}}
{{Map Infobox
| Type = 2D tile-based
| Layers = 1
| Tile size = 16×16
| Viewport = 320×160
| Game1 = Dangerous Dave
}}

[[Dangerous Dave]] stores its levels consecutively in the executable starting at offset $26E0A (after [[UNLZEXE]]'ing.) Each level is 1280 bytes long.

== Level structure ==

Each level is stored in the following structure:

{|class="wikitable"
!Data type!!Description
|-
|[[BYTE]] path[256]||Path data
|-
|[[BYTE]] tiles[100*10]||Tile data, left to right, top to bottom
|-
|[[BYTE]] padding[24]||Unused
|}

The 1000 bytes of tile data are followed by 24 bytes of unused data to bring the chunk up to a nice round 1024 bytes.

=== Path data ===

This block of data is used to specify a path for creatures to follow. It is an array of up to 128 X,Y coordinate pairs, with each pair being a signed 8-bit integer (so two bytes * 128 pairs == 256 bytes max.) Each value dictates the number of pixels the creature should move in both the X and Y direction. The end of the path is signified by storing 0xEA in both coordinates, and upon reaching this point the path repeats from the beginning. An example path might be

05 03 FB FD EA EA

Which means:

05 03 # Move five pixels to the right and three pixels down
FB FD # Move five pixels left and three pixels up, i.e. return to the original position
EA EA # End of path

This would cause the creature to oscillate between two points. (Since the values are signed, 0xFF == -1, 0xFE == -2, etc.)

Since the paths consist of relative movement instructions, a path that does not return the creature to its starting point at termination will cause the creature to gradually migrate off the edge of the level, as the misalignment accumulates after each loop iteration. However this could be used for creative effect, as the creature will then reappear at the opposite edge of the level.

It appears that only one path can be defined in each level, and all creatures follow it the same (although as the path consists of relative movement instructions, the creatures can trace out the same path at different locations in the level.)

=== Tile data ===
[[Image:ddave-level01-vga.png|thumb|480px|Level 1 with VGA tiles. Often two levels are stored in the one file.]]

The level consists of 1000 bytes of tile data, one byte per tile arranged in a 100x10 array.

The byte values are indices into the [[Dangerous Dave Graphics Format|tileset]], so a byte of value 0x02 means tile number 2 should be drawn in that location (with tile number 0 being the first image in the tileset.) Tile number 0 is actually a black square, so a byte value of 0x00 is used for empty space the player can walk in.

=== Constants ===

Both the player starting point and the creatures which appear in each level are hard coded as follows, with (0,0) being the top-left corner of the level and (99,9) being the lower right tile:

{|class="wikitable"
! Level !! Level chunk !! Start !! Creatures
|-
| 1 || 1 || (2,8) || None
|-
| 2 || 2 || (1,8) || None
|-
| 3 || 3 || (2,5) || Spiders at (44,4) and (59,4) - each spider is ~2x2 tiles in size
|-
| 4 || 4 || (1,5) || TODO
|-
| 5 || 5 || (2,8) || 3x Suns at TODO
|-
| 6 || 6 || (2,8) || TODO (Bones)
|-
| 7 || 7 || (1,2) || TODO (UFOs)
|-
| 8 || 8 || (2,8) || TODO
|-
| 9 || 9 || (6,1) || TODO
|-
| 10 || 10 || (2,8) || TODO
|-
| 5 warp || 2 || (51,0) || None
|-
| 8 warp || 6 || (71,0) || None / shares with level 6
|-
| 9 warp || 7 || (80,0) || TODO
|-
| 10 warp || 1 || (20,0) || None
|}

The level chunk is the "file" the level appears in (because some levels share the same files.)

== Credits ==

The initial investigation and tile data documentation was done by [[User:Levellass|Levellass]], with [[User:Malvineous|Malvineous]] discovering how the path data works. 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:Dangerous Dave]]

GameMaps Format

2012-05-01T13:37:57Z

Eros: Linking UNLZEXE

The GameMaps format is how the levels in a number of [[Id Software]] games is stored. The filenames and compression varies somewhat across different games but all files stored in this format were produced by the program [[TED5]] or a close analogue.

There are three main varieties of the GameMaps format, uncompressed, [[Carmack compression|carmackized]], and [[Huffman Compression|huffman compressed]]. Each variation has its own file naming scheme and pattern of external\internal files.

There are two main components to the format, the game maps proper, which contain the game level data and the map headers, which contain both the locations of the start of level data in the game maps file and the tile info for the game.

== Structure of uncompressed data ==

The uncompressed format is used by several games including [[Bio Menace]] and [[Wolfenstein 3D]]. In this format map data is stored in <tt>MAPTEMP.xxx</tt> and map headers in <tt>MAPTHEAD.xxx</tt> this is the format saved by [[TED5]] when maps are being edited and can be directly accessed and edited by this utility, allowing changes to be made to the game.

Note that filenames differ and that Wolfenstein 3D uses <tt>GAMEMAPS.WLx</tt> and <tt>MAPHEAD.xxx</tt> files to store data. The main indicator of this format being used is that in the unaltered game the map header file is external.

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

=== Map headers ===

0 2 Magic word Magic word for [[RLEW compression]]
2 400 Level ptr 100 4-byte pointers to start of level 0-99 data in game maps file
402 ??? Tileinfo Tileinfo data

The map header file is of varying length and contains three main types of data. The first is the magic word or flag used for RLEW compression, it is always $ABCD. The second is 100 level pointers which give the location of the start of level data in the game maps file, relative to the start of that file. A value of 0 indicates no level. The third is the tileinfo data, tile properties for each tile used in level creation. (These are masked and unmasked and either 8x8, 16x16 or 32x32)

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

=== Game maps ===

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

Chunks are ordered by the map header file, which will point to the level header chunks which in turn contain pointers to the other chunks used by that level. It is possible the string at the start of the file is to avoid the possibility of a level header at the start of the file which would be read as not existing.

All data in game maps file is in the form of words (Or in the case of pointers, dwords.)

=== Level headers ===

The header for each level that is pointed to by MAPHEAD is 42 bytes long and RLEW compressed, though this is difficult to see since the data is so short and nonrepetitive. For the offsets to level planes a value of 0 indicates the plane does not exist.

Plane 1 is background using unmasked tiles, plane 2 is foreground and uses masked tiles. Plane 3 is sprite or info. Levels must contain c background plane and usually an infoplane.

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 (in 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)

== Carmack compression ==

[[Carmack compression]] is the method used to compress later Id Software games, when file size was an issue. It is the most efficient and complex compression method and was created specifically to work with the word structure of the game maps file. The compression is detailed on its [[Carmack compression|own page.]]

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

== Huffman compression ==

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

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

There will be two internal files for this format, the map header and the huffman dictionary (which is always the first dictionary in the executable.) The map header format is also slightly different, being 502 bytes long, the extra 100 bytes being the length of the compressed level headers in the game maps data (These can be ignored when decompressing since huffman data can be read until the decompressed level header's fixed size is reached.)

== Location of internal files ==

Game maps are always external, but in the case of compression the map header file is stored internally in the executable. Executables are themselves compressed wither with LZEXE or PKLite. Once decompressed it is a trivial task to find the map header file as it will start with the word $ABCD For level editing purposes only the first 402 (or 502) bytes of the file needs to be extracted, though it is possible to read the maphead file to calculate its length.

The following addresses are in the locations in the [[UNLZEXE|decompressed]] executables for the start of the Map header files. Values are different for different versions.

TODO: Add all known versions of all games.

External files
Biomenace
Blake Stone 2: Planet Strike
Corridor 7 Demo
Noahs Ark 3D
Operation Body Count
Spear of Destiny
Wolfenstein 3D

Internal files:
Catacomb 3-D (1.00): $1C570 from start of file CAT3D.EXE (after file is UNLZEXE)
Catacomb 4 Abyss (1.13): $1C510 from start of file CATABYSS.EXE (after file is UNLZEXE)
Catacomb 5 Armageddon (1.01a): $1D900 from start of file CATARMA.EXE (after file is UNLZEXE)
Catacomb 6 Apocalypse (1.00b): $1DD50 from start of file CATAPOC.EXE (after file is UNLZEXE)
Corridor 7 CD (): $30D50 from start of file CORR7CD.EXE (file is not compressed)
Corridor 7 Floppy (): $24BF0 from start of file C7.EXE (file is not compressed)
Keen 4 (Special Demo): (file is PKLite compressed)
Keen 4 (1.4): $24830
Keen 5 (1.4): $25990
Keen 6 (1.4): $25080
(Keen D (1.13): $1FA50)

== 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]], [[Blake Stone]], [[Catacomb 3D]], [[Catacomb Abyss]], [[Corridor 7]], [[Dangerous Dave 3]], [[Dave Goes Nutz]], [[Noah's Ark 3D]], [[Operation Body Count]], [[Spear of Destiny]], and [[Wolfenstein 3D]].

[[Category:File Formats]]
[[Category:Map Files]]

Dangerous Dave

2012-05-01T13:33:51Z

Eros: Linking UNLZEXE

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

Dangerous Dave is the first installment in the popular Dangerous Dave series, preceding [[Dangerous Dave 2]] (And [[Dangerous Dave in Copyright Infringement|DDiCI]].)

In this installment Dave navigates the lair of his nemesis, looking for the ten special trophies he needs to steal, and get out alive. The game features ten levels plus bonus areas and separate CGA, EGA and VGA graphics.

== File formats ==

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

* [[B800 Text]] - 4000-byte internal files are text screens shown at exit.
* [[Commander Keen EGA Header]] Some EGA graphics are stored internally and use this.
* [[Dangerous Dave Level format]] - Levels are stored in the executable.
* [[Dangerous Dave Graphics Format]] - Format of the CGA/EGA/VGA graphics.
** [[VGA Palette]] - standard 6-bit VGA palette of 768 bytes starting at offset 0x26B0A
* [[Dave Score format]] - Scores are stored in <tt>SCORES.DAV</tt>
* [[Inverse Frequency Sound format]] - the sound file is stored internally and uses Apogees 'inverse frequency' sound format. It begins at offset 0x1C4E0 in <tt>DAVE.EXE</tt>
* [[Raw EGA data]] <tt>EGADAVE.DAV</tt> is EGA data, stored in an unusual fashion, but some data stored in the executable is closer to standard EGA format.
* Text is contained in the executable, which can be uncompressed with [[UNLZEXE]].

== dave.exe ==

When decompressed with unlzexe, <tt>dave.exe</tt> contains the following data:

{|class="wikitable"
! Offset !! Description
|-
| 0x0b4ff || Unknown data
|-
| 0x0c620 || [[Dangerous Dave Graphics Format|CGA tiles]]
|-
| 0x120f0 || [[Dangerous Dave Graphics Format|VGA tiles]]
|-
| 0x1c4e0 || [[Inverse Frequency Sound format|PC speaker sound effects]]
|-
| 0x1d780 || CGA font + menu graphics
|-
| 0x1ea40 || EGA font + menu graphics
|-
| 0x20ec0 || VGA font + menu graphics
|-
| 0x26b0a || [[VGA Palette]]
|-
| 0x26e0a || [[Dangerous Dave Level format|Levels]] (10 @ 1280 bytes each)
|}

== Graphics ==

Dave can use CGA, EGA and VGA graphics, with the default being the best card available. All of the CGA and VGA graphics are stored internally, while the EGA graphics are stored in an external file, and have no relation to the CGA/VGA graphics (i.e. the game will work fine in CGA or VGA mode even if <tt>EGADAVE.DAV</tt> is missing.) The font and menu graphics (for CGA/VGA and EGA) are all stored in the main .exe file (as it is still possible to press F2 to change in and out of EGA mode with a missing/corrupted <tt>EGADAVE.DAV</tt> file.)

== Tools ==

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

[[Category:Softdisk]]

Crystal Caves Map Format

2012-05-01T13:32:41Z

Eros: Linking UNLZEXE

{{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. In addition, some maps can use data from other maps (in most cases the first or the last row) or use two data-rows to produce a single row on the map. Practically, this makes it very hard to increase a level's height and causes a lot of restrictions to modifying the maps. The levels (not counting Intro and Finale) are all sized 40 x 24 tiles and it is believed that each level uses 24 rows of data, with the following exceptions:

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

== Format ==

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

=== Map codes ===

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

LZEXE

2012-05-01T13:31:52Z

Eros: Linking UNLZEXE.

'''LZEXE''' is a utility that compresses an executable file into a smaller, self-extracting form. It was used in most early id and [[Apogee]] games, and many others. LZEXE compressed executables can be unpacked by a few different utilities, the most widely used being [[UNLZEXE]].

An LZEXE compressed executable can be recognized by the presence of the tag "LZ" at offset 0x1C in the .EXE file, followed by a version number that is either "09" or "91". Such executables must be decompressed before any useful inspection or hacking of the .EXE can take place.

Note that some programs change the LZ91 signature to disguise the fact that LZEXE has been used. If there are four sensible-looking characters at the same offset there's a good chance the file has been compressed with LZEXE and had its signature changed. Luckily most decompression utilities don't look at this so they can decompress the file anyway.

[[Category:Utilities]]

Rescue Rover

2012-05-01T13:29:54Z

Eros: Linking UNLZEXE

{{Stub}}
{{GamePage|Rescue Rover}}

Rescue Rover is a puzzle game by the [[ID Software]] group for [[Softdisk]] publishing, released in 1991. It is the first in a 2-part game series featuring Roger and his faithful dog Rover. It's a whimsical arcade/puzzle game that pits you against evil Robots while you try to rescue Rover from their clutches. The second part, released the same year was [[Rescue Rover 2]], based on similar formats to the [[Commander Keen Dreams]] game.

== File formats ==

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

* [[Commander Keen 1-3 Level format]] - <tt>LEVELxx.ROV</tt> are game levels.
* [[Commander Keen EGA Header]] the EGA header is used to read graphics files.
* [[EGA Font format]] <tt>EGAFONT0.ROV</tt> stores monochrome font used in the game
* [[Inverse Frequency Sound format]] - <tt>SOUNDS.ROV</tt> sotes the game sounds.
* [[Rescue Rover Saved game format]] <tt>SAVEx.ROV</tt> store the game's save files. They are 38 bytes long.
* [[SHL data]] - The start menu is in this format
* [[PIC Format#PIC format version 2|PIC format version 2]] - all files that have "PIC" in their name (e.g. <tt>TITLEPIC.ROV</tt>) are in this format, compressed with [[RLEW compression#RLEB compression|RLEB compression]]
* [[Raw EGA data#Planar EGA data|Full-screen planar EGA]] Most graphics are in this format, compressed or rearranged in various ways. Sprites, tiles (two files) and fonts are all stored in separate files.
* [[Keen 1-3 RLE compression]] This is used to compress the ending and previews screens and is a modified form of RLE.
* Text is contained in the executable, the executable is compressed with [[LZW compression]], and can be uncompressed with [[UNLZEXE]].

== Notes ==

The game was produced before [[Commander Keen 1-3]] but uses almost identical, though less efficient formats for nearly all its files.

== Related Links ==
* [[Commander Keen 1-3]]
* [[Rescue Rover 2]]

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

UNLZEXE

2012-05-01T13:28:48Z

Eros: Changed LZW link to LZW_compression

{{Tool Infobox
| Platform = DOS, Windows, Linux
| Release = 1990-05-17 (v0.5)
| Homepage = [http://sourceforge.net/projects/clonekeenplus/ sourceforge.net]
| Download = [http://sourceforge.net/projects/clonekeenplus/files/Tools/unlzexe/ sourceforge.net]
| Edit1 = Extraction
}}

UNLZEXE is a program that decompresses [[LZW_compression|LZW compressed]] executables. It is notably used to decompress [[Commander_Keen_1-3]] or [[Catacomb]] executables before they can be patched. There is a 16-bit and 32/64-bit version available.

{{TODO|Linking to the original project page (if it still exists) instead of the SourceForge one}}

== Usage ==
=== DOS Version ===
If using the old, 16-bit version, you can simply drag-and-drop the compressed executable onto UNLZEXE. Successful decompression is heralded by the creation of a .OLZ file (Which contains the old, compressed file.) This works on most windows systems up to Windows Vista. Otherwise it must be run in DOSBox using the following commands:

Z:\>mount c "C:\the directory\the game is in"
Z:\>c:
C:\>unlzexe keen1.exe

=== x86 / x64 Linux or Windows Versions ===

In those versions you don't need DOSBox or mount anything. Just the following:

unlzexe file.exe

It will generate file.exenew which is the extracted version.
You can also use the drag and drop method here on any windows version!

NOTE: 64-bit Windows versions should be able to use the Win32 version.

== Links ==

* [http://keenmodding.org/viewtopic.php?t=1310 32/64 bit thread on keen:modding]
* [http://sourceforge.net/projects/clonekeenplus/files/Tools/unlzexe/win32/unlzexe081.zip/download Download 32/64-bit Windows Version]
* [http://sourceforge.net/projects/clonekeenplus/files/Tools/unlzexe/linux64/unlzexe081.zip/download Download 64-bit Linux Version]
* [http://sourceforge.net/projects/clonekeenplus/files/Tools/unlzexe/linux32/unlzexe081.zip/download Download 32-bit Linux Version]
* [http://files.commanderkeen.org/users/ceilick/UNLZEXE.EXE Download 16-bit version]
{{TODO|Link to the source code}}

[[Category:Extraction_tools]]
[[Category:Modding Tools]]

Dangerous Dave in Copyright Infringement

2012-05-01T13:27:36Z

Eros: Linking UNLZEXE

{{Stub}}

{{GamePage}}

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

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

== File formats ==

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

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

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

==Notes==

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

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

LZW Compression

2012-05-01T13:27:22Z

Eros: Linking UNLZEXE

LZW compression is a common form of compression used in some early games to compress data and by most early games to compress their executables. It is notable in being one of the first compression methods to not compress on the byte level (Along with [[Huffman Compression]]) and for its efficiency.

The basic concept for LZW is universal, though the implementations differ. In essence it compresses data by replacing strings of data with a 'codeword' that represents them. The flexibility of this approach is that what each code word stands for is 'built up' as the data is compressed/decompressed.

At the start the compressing/decompressing program is given a 'dictionary' of about 256 codewords, each 9 bits long and representing the strings $00-$FF (Plus possibly some reserved values.)

0000 - 00 (character)
0001 - 01 (character)
...
00FE - FE (character)
00FF - FF (character)
0100 - Reserved for errors...
0101 - Reserved for end of compressed data...
0102 - (not set)
0103 - (not set)

Code words are 9 bits long until the dictionary is $1FF entries long, then they become 10 bit until $3FF, then 11 bits and so on. In some implementations the size of the dictionary is limited. [[Commander Keen 1-3]] for example limits itself to 4096 entries (Up to 12 bit codes) to save memory.

== Deconding ==

The decoding algorithm:

1 At the start the dictionary contains all possible roots;
2 cW := the first code word in the codestream (it denotes a root);
3 output the string.cW to the charstream;
4 pW := cW;
5 cW := next code word in the codestream;
6 Is the string.cW present in the dictionary?
a if it is,
i output the string.cW to the charstream;
ii P := string.pW;
iii C := the first character of the string.cW;
iv add the string P+C to the dictionary;
b if not,
i P := string.pW;
ii C := the first character of the string.pW;
iii output the string P+C to the charstream
iv add the string P+C to the dictionary (now it corresponds to the cW);
7 Are there more code words in the codestream?
a if yes, go back to step 4;
b if not, END.

== Executables ==

Many executables are LZW compressed in an interesting way. They consist of a decompressor and the compressed executable. When run, the decompressor extracts the executable, then runs it. [[UNLZEXE]] can be used to extract the decompressed executables from this which will run perfectly with other game files. It can be obtained here: http://www.dosclassics.com/download/198

== An example ==

[[Commander Keen 1-3]] uses its own implementation of the Lempel-Ziv-Welch ([[LZW compression]]) to compress the <tt>EGALATCH</tt> and <tt>EGASPRIT</tt> files in episode 1 (It can also be used in episodes 2 and 3, but isn't.)

The important points here is the limited size of the dictionary and the fact that entries $100 and $101 are reserved (The first to indicate an error in compression, the second to indicate end of compressed data.) The following data is taken from the EGALATCH file from Keen 1. We will decompress it.

0000 80 D3 01 00 0C 00 00 40 - A0 70 31 E9 F8 F8 78 38
0010 08 08 00 07 FC 39 FF 04 - 5E 41 E1 30 B3 C4 5A 2F

In this implementation the first 6 bytes are ignored (They are the decompressed data size and an executable variable.) The first code word encountered is 000000000 (First 9 bits) and thus outputs the string $00 (First dictionary entry.) This has set us up to step 4 and now things work slightly differently.

The second code word is 100000010 (Next 9 bits) which is entry $102. Since this entry is NOT found in the dictionary yet, we will create this entry then output it. Entry $102 is created by taking the previous codeword's string adding to it the first byte of that string. In this case the previous codewrode's (0) string is $00. $00 + $00 is $00 $00 Entry $102 thus represents the string $00 $00

The next code word is 100000011 which is entry $103, which again doesn't exist. Entry $103 is created just like with $102, except now since the previous codeword is $00 $00, entry $103 is $00 $00 $00

The next code word is again $103, this IS found in the dictionary and is outputted ($00 $00 $00) however we now create dictionary entry $104 just like $103. (It is $00 $00 $00 $00)

The next code word is $3B. It is outputted and entry $105 created ($00 $00 $00 $00 $3B)

In this manner more and more dictionary entries are created, representing longer and longer strings. Because of this, many games have built-in limits for how big the dictionary can get. (For example Keen 1 limits itself to 12 bit codes, that is, the dictionary is not increased in size after 4096 entries.)

== Source code ==

Some example code is available in various languages showing how to decompress (and in some cases compress) files using the Keen's LZW algorithm.

=== QuickBasic ===

<source lang="qbasic">
DECLARE FUNCTION READBITS% (FILE AS INTEGER, NUMBITS AS INTEGER)
DECLARE SUB LZWDECOMPRESS (INNAME AS STRING, OUTNAME AS STRING)
DECLARE SUB LZWOUTPUT (FILE AS INTEGER, DIC AS INTEGER, CHAR AS INTEGER)
'
' KEEN1 Compatible LZW Decompressor (Lempel-Ziv-Welch)
' - by Napalm with thanks to Adurdin's work on ModKeen
'
' This source is Public Domain
'
'

' Allocate dictionary
DIM LZDIC(0 TO 4095) AS INTEGER
DIM LZCHR(0 TO 4095) AS INTEGER

' Test Function
LZWDECOMPRESS "EGALATCH.CK1", "EGALATCH.DAT"

SUB LZWDECOMPRESS (INNAME AS STRING, OUTNAME AS STRING)
SHARED LZDIC() AS INTEGER, LZCHR() AS INTEGER
DIM INFILE AS INTEGER, OUTFILE AS INTEGER, I AS INTEGER
DIM BITLEN AS INTEGER, CURPOS AS INTEGER
DIM CW AS INTEGER, PW AS INTEGER, C AS INTEGER, P AS INTEGER
DIM CHECK AS INTEGER

' Open files for input and output
INFILE = FREEFILE
OPEN INNAME FOR BINARY ACCESS READ AS INFILE
OUTFILE = FREEFILE
OPEN OUTNAME FOR BINARY ACCESS WRITE AS OUTFILE
SEEK INFILE, 7

' Fill dictionary with starting values
FOR I = 0 TO 4095
LZDIC(I) = -1
IF I < 256 THEN
LZCHR(I) = I
ELSE
LZCHR(I) = -1
END IF
NEXT I

' Decompress input stream to output stream
BITLEN = 9
CURPOS = 258
CW = READBITS(INFILE, BITLEN)
LZWOUTPUT OUTFILE, LZDIC(CW), LZCHR(CW)

WHILE CW <> &H100 AND CW <> &H101
PW = CW
CW = READBITS(INFILE, BITLEN)
IF CW <> &H100 AND CW <> &H101 THEN
P = PW
CHECK = (LZCHR(CW) <> -1)

IF CHECK THEN
TMP = CW
ELSE
TMP = PW
END IF
WHILE LZDIC(TMP) <> -1
TMP = LZDIC(TMP)
WEND
C = LZCHR(TMP)

IF CHECK THEN
LZWOUTPUT OUTFILE, LZDIC(CW), LZCHR(CW)
ELSE
LZWOUTPUT OUTFILE, P, C
END IF

IF CURPOS < 4096 THEN
LZDIC(CURPOS) = P
LZCHR(CURPOS) = C
CURPOS = CURPOS + 1
IF CURPOS = (2 ^ BITLEN - 1) AND BITLEN < 12 THEN
BITLEN = BITLEN + 1
END IF
END IF

END IF
WEND

' Close files
CLOSE OUTFILE
CLOSE INFILE
END SUB

SUB LZWOUTPUT (FILE AS INTEGER, DIC AS INTEGER, CHAR AS INTEGER)
SHARED LZDIC() AS INTEGER, LZCHR() AS INTEGER
DIM LZSTK(0 TO 127) AS STRING * 1
DIM X AS INTEGER, SP AS INTEGER
DIM LDIC AS INTEGER, LCHAR AS INTEGER

LCHAR = CHAR
LDIC = DIC
SP = 0
X = 1

DO
IF SP >= 128 THEN
PRINT "LZW: Stack Overflow!"
END
END IF
LZSTK(SP) = CHR$(LCHAR)
SP = SP + 1
IF LDIC <> -1 THEN
LCHAR = LZCHR(LDIC)
LDIC = LZDIC(LDIC)
ELSE
X = 0
END IF
LOOP WHILE X

WHILE SP <> 0
SP = SP - 1
PUT FILE, , LZSTK(SP)
WEND
END SUB

FUNCTION READBITS% (FILE AS INTEGER, NUMBITS AS INTEGER)
STATIC BITDAT AS STRING * 1, BITPOS AS INTEGER
DIM BITVAL AS INTEGER, BIT AS INTEGER

BITVAL = 0
FOR BIT = (NUMBITS - 1) TO 0 STEP -1
IF BITPOS = 0 THEN
GET FILE, , BITDAT
BITPOS = 7
ELSE
BITPOS = BITPOS - 1
END IF
IF ASC(BITDAT) AND 2 ^ BITPOS THEN
BITVAL = BITVAL OR 2 ^ BIT
END IF
NEXT BIT

READBITS% = BITVAL
END FUNCTION
</source>

=== FreeBasic ===

This code does not suffer from the 64K memory limit imposed by QuickBasic and so is less efficient, but runs faster. It can be compiled with FreeBasic compiler using the -lan=qb switch. Aside from memory concerns, all code here is compatible with QuickBasic.

The code before the subroutine is used to make a string containing the bit expansion of all values from 0 to 255. The subroutine takes a filename, reads the entire file into memory then expands each bit of data to a byte using the aforesaid string as Basic cannot deal with bits directly. cw$ is codeword, pw$ is the previous codeword, lun is the lowest dictionary entry that is empty, p is the location in the compressed data stream and bl is the length of codes in bits (Starting at nine bits increasing to 12)

The dictionary is set before decompression. The first 258 are the starting dictionary, the remainder are cleared. (It is vital to reset the dictionary for each file) An error occurs if entry 256 is found in the data, 'distrupt' is printed when the newest dictionary entry is not the lowest possible entry (This shouldn't happen but is possible.) Decompression ends at encountering entry 257, or when there is no more data to read.

<source lang="qbasic">
DECLARE SUB LZWDEC (lfn AS STRING)

x$ = ""
FOR l = 0 TO 255
IF (l AND 128) > 0 THEN x$ = x$ + "1" ELSE x$ = x$ + "0"
IF (l AND 64) > 0 THEN x$ = x$ + "1" ELSE x$ = x$ + "0"
IF (l AND 32) > 0 THEN x$ = x$ + "1" ELSE x$ = x$ + "0"
IF (l AND 16) > 0 THEN x$ = x$ + "1" ELSE x$ = x$ + "0"
IF (l AND 8) > 0 THEN x$ = x$ + "1" ELSE x$ = x$ + "0"
IF (l AND 4) > 0 THEN x$ = x$ + "1" ELSE x$ = x$ + "0"
IF (l AND 2) > 0 THEN x$ = x$ + "1" ELSE x$ = x$ + "0"
IF (l AND 1) > 0 THEN x$ = x$ + "1" ELSE x$ = x$ + "0"
NEXT l
LZEDEC "EGALATCH.CK1"
END

'_________________________________________________
SUB LZWDEC (lfn AS STRING) ' Decompress LZW data
'_________________________________________________
DIM lzw(0 TO 4095) AS STRING
PRINT lfn; " is LZW compressed, decompressing...";
OPEN folder + lfn FOR BINARY AS #9
y$ = SPACE$(LOF(9))
GET #9, 1, y$
CLOSE #9
z$ = ""
FOR l = 7 TO LEN(y$)
z$ = z$ + MID$(x$, (ASC(MID$(y$, l, 1)) * 8) + 1, 8)
NEXT l

bl = 9
lun = 258
p = 1
cw$ = ""
y$ = ""
FOR l = 0 TO 4095
IF l < 256 THEN lzw(l) = CHR$(l) ELSE lzw(l) = ""
NEXT l
DO
IF lun = 511 THEN bl = 10
IF lun = 1023 THEN bl = 11
IF lun = 2047 THEN bl = 12
pw$ = cw$
u$ = MID$(z$, p, bl)
p = p + bl
y = 0
FOR l = 1 TO bl
IF MID$(u$, bl - l + 1, 1) = "1" THEN y = y + (2 ^ (l - 1))
NEXT l
IF y = 256 THEN
PRINT "LZW error in Keen data!"
OPEN "ERROR.DAT" FOR OUTPUT AS #9
PRINT #9, y$;
CLOSE
END
END IF
IF y = 257 THEN EXIT DO
IF cw$ = "" THEN
cw$ = lzw(y)
y$ = y$ + cw$
ELSE
IF lun < 4096 THEN
IF lzw(y) = "" THEN
cw$ = pw$ + LEFT$(pw$, 1)
lzw(y) = cw$
y$ = y$ + cw$
IF y <> lun THEN PRINT "Disrupt!"
lun = y + 1
ELSE
cw$ = lzw(y)
y$ = y$ + cw$
lzw(lun) = pw$ + LEFT$(cw$, 1)
lun = lun + 1
END IF
ELSE
IF lzw(y) = "" THEN
y$ = y$ + cw$
ELSE
cw$ = lzw(y)
y$ = y$ + cw$
END IF
END IF
END IF
LOOP WHILE p < LEN(z$)
IF y = 257 THEN PRINT "done" ELSE PRINT "out of data."
OPEN folder + LEFT$(lfn, 4) + extq FOR OUTPUT AS #9
PRINT #9, y$;
CLOSE #9
END SUB
</source>
----

[[Category:Commander Keen 1-3]]
[[Category:File Formats]]
[[Category:Compressed Files]]

Dangerous Dave 2

2012-05-01T13:25:20Z

Eros: Linking UNLZEXE

{{Stub}}

{{GamePage}}

Dangerous Dave 2, also known as Dangerous Dave in the Haunted Mansion (DDitHM)is the second installment of the popular Dangerous Dave series (Third if [[Dangerous Dave in Copyright Infringement|DDiCI]] is counted.) Following [[Dangerous Dave]] and preceding [[Dangerous Dave 3]]: Dave's Risky Rescue.

In this installment Dave must rescue his younger brother Delbert from the Haunted Mansion. The game was severely cut down to fit onto a floppy disk and meet the release date, and so lacks appreciable story elements. The game was made utilizing a modified version of the [[Commander Keen 1-3]] engine and thus uses many formats similar to Keen, though usually with more advanced compression.

== File formats ==

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

* [[B800 Text]] - 4000-byte internal files are text screens shown at exit.
* [[Commander Keen 1-3 Level format]] - <tt>LEVELxx.DD2</tt> are game levels.
* [[Commander Keen EGA Header]] the EGA header is stored internally and is used to read graphics files.
* [[Dave 2 Tileinfo format]] - information about the properties of tiles are stored internally in the executable.
* [[Dave 2 Tileset format]] - <tt>TILES.DD2</tt> contains the game tiles.
* [[EGA Font format]] monochrome font used in the game is stored in the executable.
* [[Inverse Frequency Sound format]] - the sound file is stored internally and uses Apogees 'inverse frequency' sound format.
* [[Raw EGA data#Planar|Full-screen planar EGA]] Most graphics are in this format, compressed or rearranged in various ways. For example, the 320x200 screen graphics are this compressed with [[Huffman Compression]].

* [[RLEW compression]] This is used to compress the [[Dave 2 Intro format|INTRO.DD2]] file
* [[Dave 2 Huffman compression]] Used to compress most of the graphics files, a modification of the standard [[Huffman Compression]].
* Text is contained in the executable, the executable is compressed with LZ compression, and can be uncompressed with [[UNLZEXE]].

== Notes ==

Dangerous Dave 2 stores the header and <tt>LATCH</tt> internally in the executable at 74896 and 101096 respectively (in the UNLZEXE'd executable.) Tiles are stored in a separate file <tt>EGATILES.DD2</tt>. Since each tile may or may not be loaded in a level depending on whether it's needed, the tile file is composed of 858 128-byte entries, each containing 4-EGA planes for the tile.

[[Shadow Knights]], published just weeks later uses the Dave engine also and is even more similar than Keen.

Dave 2 is intermediate in development between [[Commander Keen 1-3]] and [[Commander Keen Dreams]] which followed it. Though basic, it makes use of several changes in format that are used in later Keen games.

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

Shadow Knights

2012-05-01T13:25:13Z

Eros: Linking UNLZEXE

{{Stub}}

{{GamePage}}

Shadow Knights is an early [[ID Software]] game made using the [[Dangerous Dave 2]] engine, itself modified from the [[Commander Keen 1-3]] engine. Due to having to be cut down to fit on a floppy disk and to meet its release date, it lacks a number of features, such as appreciable story elements and animating tiles, much like Dave 2.

== File formats ==

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

* [[B800 Text]] - 4000-byte internal files are text screens shown at exit.
* [[Commander Keen 1-3 Level format]] - <tt>LEVELxx.NIN</tt> are game levels.
* [[Commander Keen EGA Header]] <tt>EGAHEAD.NIN</tt> is used to read graphics files.
* [[Dave 2 Tileinfo format]] - information about the properties of tiles are stored internally in the executable
* [[Dave 2 Tileset format]] - <tt>EGATILES.NIN</tt> contains the game tiles.
* [[EGA Font format]] monochrome font used in the game is stored in the executable.
* [[Inverse Frequency Sound format]] - the sound file is stored internally and uses Apogees 'inverse frequency' sound format.
* [[PIC Format#PIC format version 1|PIC format version 1]] - the 640x200 end screen graphic is in this format, compressed with [[RLEW compression#RLEB compression|RLEB compression]].
* [[Raw EGA data#Planar|Full-screen planar EGA]] Most graphics are in this format, compressed or rearranged in various ways. For example, the sprites and the font file are this compressed with ?[[RLEW compression]]?.

* ?[[RLEW compression]]? This is used to compress most graphics.
* Text is contained in the executable, the executable is compressed with LZ compression, and can be uncompressed with [[UNLZEXE]].

== Notes ==

Shadow Knights is intermediate in development between [[Commander Keen 1-3]] and [[Commander Keen Dreams]] which followed it. Though basic, it makes use of several changes in format that are used in later Keen games.

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

Jill of the Jungle

2012-05-01T13:24:35Z

Eros: Linking UNLZEXE

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

[[Jill of the Jungle]] is the first version of the engine which would go on to power [[Xargon]]. It supports CGA, EGA and VGA graphics by way of "colour maps", which dictate the CGA and EGA colours to be used to display each of the possible 256-colours of a given image. This way only a single 256-colour image is supplied, rather than a different image for each display.

Jill is also unique in that it is one of a very small number of games that include a level editor, albeit an undocumented one. See the [[Using the official Jill of the Jungle level editor|tutorial]] for more details.

== Tools ==

{{BeginFileFormatTools|Type=game}}
{{FileFormatTool
| Name = [[Using the official Jill of the Jungle level editor|Built-in editor]]
| Platform = DOS
| grp = N/A
| map = Edit
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [[Camoto]]
| Platform = Linux console/GUI
| grp = N/A
| map = Edit
| gfx = Read
| mus = Edit
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [http://ftp.funet.fi/pub/msdos/games/editors/jilledit.zip JillEdit] [http://www.stuntsillusion.com/download/jilledit.zip (mirror)]
| Platform = DOS
| grp = N/A
| map = Edit
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{EndFileFormatTools}}

<br style="clear: both;"/>
== File formats ==

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

{|class="wikitable"
! File name !! Description
|-
| <tt>*.cfg</tt>
| style="background: #CCFFCC;" | Configuration file in [[CFG Format (Jill of the Jungle)]]
|-
| <tt>*.ddt</tt>
| style="background: #CCFFCC;" | Music in [[CMF Format]]
|-
| <tt>jill.dma</tt>
| style="background: #CCFFCC;" | Tile information in [[DMA Format]]
|-
| <tt>*.jn[123]</tt>
| style="background: #CCFFCC;" | Game levels in [[Jill of the Jungle Map Format]]
|-
| <tt>*.mac</tt>
| style="background: #CCFFCC;" | Input macros for demos in [[MAC Format (Jill of the Jungle)]]
|-
| <tt>jill[123].sha</tt>
| style="background: #CCFFCC;" | Shapes (images) in [[SHA Format]]
|-
| <tt>jill[123].vcl</tt>
| style="background: #CCFFCC;" | Sound and text assets in [[VCL Format]]
|-
| <tt>jn[123]save.[0-9]</tt>
| style="background: #CCFFCC;" | Saved games - just dumps of the entire level in its current state (same format as [[Jill of the Jungle Map Format|actual levels]])
|}

== Palette ==
[[Image:Jill of the Jungle palette.png|thumb|right|128px|Jill of the Jungle palette]]
The VGA palette can be found inside the .EXE file. The palette is the same in all episodes and versions.

==== Episode 1: Jill of the Jungle ====
{|class="wikitable"
!Version!!CRC32!!Date!!Size!!Palette Offset
|-
|1.0||7899CC28||1992-06-01||216 804 bytes||0x1ED84
|-
|1.2||9540714E||1992-07-12||204 784 bytes||0x1F884
|-
|1.2(a)||51ADAE83||1992-07-30||206 963 bytes||0x1FD54
|-
|1.2(b)||171E9EC0||1992-08-21||206 712 bytes||0x1FC34
|-
|1.2(c)||C52CA6D9||1993-02-17||206 636 bytes||0x1FC04
|-
|1.2(d)||0E7C596F||1993-12-27||219 216 bytes||0x24A64
|}

==== Episode 2: Jill Goes Underground ====
{|class="wikitable"
!Version!!CRC32!!Date!!Size!!Palette Offset
|-
|1.0||6064EA0A||1992-06-17||65 166* bytes||0x1F0B4<sup>†</sup>
|-
|1.2(a)||?||1992-07-30||?||?
|-
|1.2(b)||17477A49||1992-08-21||204 158 bytes||0x1F6E4
|-
|1.2(c)||75176ED7||1993-02-17||204 096 bytes||0x1F6B4
|-
|1.2(d)||0FDB489E||1993-12-27||218 338 bytes||0x26A64
|}

==== Episode 3: Jill Saves the Prince ====
{|class="wikitable"
!Version!!CRC32!!Date!!Size!!Palette Offset
|-
|1.0||3B4D8C3B||1992-07-07||201 616 bytes||0x1F1F4
|-
|1.2(a)||B4EA288C||1992-07-30||204 425 bytes||0x1F804
|-
|1.2(b)||D5345AFB||1992-08-21||204 174 bytes||0x1F6E4
|-
|1.2(c)||3FFF0F6C||1993-02-17||204 112 bytes||0x1F6B4
|-
|1.2(d)||E27D4300||1993-12-27||218 370 bytes||0x26A64
|}

*This version has been packed using [[LZEXE|LZEXE91]].<br />
†Data taken from version after uncompressing using [[UNLZEXE]].

The palette is in [[VGA Palette|classic VGA format]] (6-bit RGB.) Note that the [[SHA Format]] can override this palette.

== Notes ==
* Since the level files are used for a lot of different things, you can e.g. swap <tt>INTRO.JN1</tt> and <tt>1.JN1</tt> and then when you load the first level you'll be playing the intro screen.

== External links ==
* [http://jillofthejungle.110mb.com/home.html Unofficial Jill of the Jungle page] ([http://members.tripod.com/classic_roach/id14.html Older version], and [http://jill-of-the-jungle.tripod.com/jillsite/index.html alternate version])
* [http://ftp.funet.fi/pub/msdos/games/editors/jilledit.zip JillEdit] [http://www.stuntsillusion.com/download/jilledit.zip (mirror)] - a level editor for Jill of the Jungle created by Rory L. Fisher.
* [http://www.vgmaps.com/Atlas/PC/index.htm#JillOfTheJungle vgmaps.com] - all Jill maps as image files

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

Commander Keen 1-3

2012-05-01T13:23:10Z

Eros: /* File formats */ Linking UNZLEXE

{{Stub}}
{{GamePage|Commander Keen 1}}

Commander Keen episodes 1-3 was a revolutionary series that launched [[ID Software]]. The games made use of a number of formats and novel features that were to be adapted to other games ID produced. Keen is notable for being the first sidescrollling EGA game on the PC, and for cementing ID's love for EGA graphics (Most previous games had CGA, EGA and VGA graphics options, all later games were EGA, or had a separate CGA version.)

In them, the hero, Commander Keen, must collect stolen parts of his spaceship hidden on Mars (1), stop a Vorticon ship blowing up earth (2) and finally storm Vorticon VI itself in search of the cause of all this trouble, the mysterious Grand Intellect.

== File formats ==

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

* [[B800 Text]] - 4000-byte internal files are text screens shown at exit.
* [[Commander Keen 1-3 Level format]] - <tt>LEVELxx.CKy</tt> are game levels.
* [[Commander Keen EGA Header]] the EGA header is used to read graphics files
* [[Keen 1-3 Tileinfo format]] - information about the properties of tiles are stored internally in the executable
* [[Commander Keen 1-3 Score format]] <tt>SCORES.CKy</tt> stores the game's highscores
* [[Keen 1-3 Saved game format]] <tt>SAVEx.CKy</tt> store the game's save files. Keen is one of the few early ID games to allow this.
* [[Inverse Frequency Sound format]] - the sound file is stored internally and uses Apogees 'inverse frequency' sound format
* [[Raw EGA data#Planar EGA data|Full-screen planar EGA]] Most graphics are in this format, compressed or rearranged in various ways. For example, the 320x200 screen graphics are this compressed with [[Keen 1-3 RLE compression]], the <tt>EGALATCH</tt> AND <tt>EGASPRIT</tt> files use this too. Note that the screen's plane size is 8000 bytes, 192 bytes are just 'padding'

* [[Keen 1-3 RLE compression]] This is used to compress the ending and previews screens and is a modified form of RLE.
* [[Keen 1-3 LZW compression]] Used in episode 1 to compress the graphics files
* Text is contained in the executable, the executable is compressed with [[LZW compression]], and can be uncompressed with [[UNLZEXE]].
* The 1.34 executable is compressed with [[PKLite compression]]; the <tt>ARCHIVE.EXE</tt> file that packages the game is a self extracting PKLite archive.

== Notes ==

The so called 'Keen engine series' begins with this game. The two games based on this engine are [[Dangerous Dave 2]] and [[Shadow Knights]]

Most of the file formats here were reverse engineered by the Keen modding community.

Commander Keen is mentioned in [[Epic Megagames]] [[Jill of the Jungle]].

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

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

UNLZEXE

2012-05-01T13:21:48Z

Eros: Cloned from keenwiki. Added infobox. Changed a few things.

{{Tool Infobox
| Platform = DOS, Windows, Linux
| Release = 1990-05-17 (v0.5)
| Homepage = [http://sourceforge.net/projects/clonekeenplus/ sourceforge.net]
| Download = [http://sourceforge.net/projects/clonekeenplus/files/Tools/unlzexe/ sourceforge.net]
| Edit1 = Extraction
}}

UNLZEXE is a program that decompresses [http://bellard.org/lzexe.html LZW] compressed executables. It is notably used to decompress [[Commander_Keen_1-3]] or [[Catacomb]] executables before they can be patched. There is a 16-bit and 32/64-bit version available.

{{TODO|Linking to the original project page (if it still exists) instead of the SourceForge one}}

== Usage ==
=== DOS Version ===
If using the old, 16-bit version, you can simply drag-and-drop the compressed executable onto UNLZEXE. Successful decompression is heralded by the creation of a .OLZ file (Which contains the old, compressed file.) This works on most windows systems up to Windows Vista. Otherwise it must be run in DOSBox using the following commands:

Z:\>mount c "C:\the directory\the game is in"
Z:\>c:
C:\>unlzexe keen1.exe

=== x86 / x64 Linux or Windows Versions ===

In those versions you don't need DOSBox or mount anything. Just the following:

unlzexe file.exe

It will generate file.exenew which is the extracted version.
You can also use the drag and drop method here on any windows version!

NOTE: 64-bit Windows versions should be able to use the Win32 version.

== Links ==

* [http://keenmodding.org/viewtopic.php?t=1310 32/64 bit thread on keen:modding]
* [http://sourceforge.net/projects/clonekeenplus/files/Tools/unlzexe/win32/unlzexe081.zip/download Download 32/64-bit Windows Version]
* [http://sourceforge.net/projects/clonekeenplus/files/Tools/unlzexe/linux64/unlzexe081.zip/download Download 64-bit Linux Version]
* [http://sourceforge.net/projects/clonekeenplus/files/Tools/unlzexe/linux32/unlzexe081.zip/download Download 32-bit Linux Version]
* [http://files.commanderkeen.org/users/ceilick/UNLZEXE.EXE Download 16-bit version]
{{TODO|Link to the source code}}

[[Category:Extraction_tools]]
[[Category:Modding Tools]]

Catacomb II

2012-05-01T12:54:54Z

Eros: Reordered sections. Information about the game should be on top.

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

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

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

== Tools ==

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

== See also ==

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

[[Category:Softdisk]]

Catacomb

2012-05-01T12:52:44Z

Eros: Reordered sections. Information about the game should be on top.

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

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

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

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

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

== File formats ==

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

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

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

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

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

[[Category:Softdisk]]

Catacomb

2012-05-01T12:35:40Z

Eros: Changed * to #. Added TITLE.PIC and END.PIC to list of files.

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

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

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

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

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

== Tools ==

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

<br style="clear: both;"/>
== File formats ==

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

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

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

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

[[Category:Softdisk]]

Talk:Catacomb Tileset Format

2012-05-01T12:31:19Z

Eros: Examples?

It looks like this is a duplicate of [[Cosmo Tileset Format]]. Perhaps we should just link to that page instead? -- [[User:Malvineous|Malvineous]] 07:29, 19 January 2011 (GMT)

:I didn't know about that. But it seems like the Cosmo page only covers the EGA format, not CGA. So there's a little bit of a reason to keep this page. Even though there's not that much of a difference as long as you know how to read/interpret the raw CGA data. --[[User:K1n9 Duk3|K1n9 Duk3]] 13:17, 19 January 2011 (GMT)

:: That's true, I'm not aware of any other CGA versions. Maybe (eventually) we could move some of the EGA stuff off this page, onto [[Cosmo Tileset Format]] then rename that page to something like "Raw EGA tileset". Then we could rename *this* page to something like "Raw CGA tileset" and just have CGA info. Well anyway my point was to make sure you don't spend too much time on the EGA side of things if it's already a known format, but you've got some good explanations and things here we'll want to keep. -- [[User:Malvineous|Malvineous]] 11:23, 21 January 2011 (GMT)

:::I just had a look at the Cosmo format. All the Cosmo tile graphics (both masked and unmasked) are [[Raw EGA data#Row-planar_EGA_data|Row-planar EGA data]], while the EGAChars are [[Raw EGA data#Graphic-planar_EGA_data|Graphic-planar EGA data]]. So I think we should leave this a stand-alone site. --[[User:K1n9 Duk3|K1n9 Duk3]] 15:29, 21 January 2011 (GMT)

:::: Because the overall file structure is the same though (8x8 tiles) I'd like to combine that fact into a single "tileset" page, and then maybe link to [[Raw EGA data]] when the time comes to describing the format of each tile. Then your descriptions here could go onto the EGA data page instead of the tileset page (which would probably be more helpful, because there are other image/tileset formats which use different structures but have the same underlying EGA data format.) -- [[User:Malvineous|Malvineous]] 00:24, 22 January 2011 (GMT)

::::: Now that I've had enough time to think about it (and worked on the Cosmo and Duke 1 files), it might be okay to merge it. My idea was to add almost everything you need to know to read the format to this page. But that would just end up in the creation of countless redundant pages. --[[User:K1n9 Duk3|K1n9 Duk3]] 23:30, 23 January 2011 (GMT)

:::::: Yes the focus of the wiki is less on implementation detail (to a point) and more on accurate descriptions of the data. The problem with having too much implementation detail is that it limits you to certain languages, and then algorithms which may not necessarily be the most efficient. Just having clear detail about the format leaves you free to think about the best way to solve the problem in your own situation. But of course it is a balance, as having some code examples can make the topic much easier to understand. If you want to add everything you need to know to read the format from scratch it's probably best writing an example program and linking to the heavily commented source code instead, so common/redundant info can be removed from the article without being lost entirely. I'll probably merge the pages once I start implementing the formats in the projects I am working on (so that I know what I'm doing is correct!) -- [[User:Malvineous|Malvineous]] 10:31, 24 January 2011 (GMT)

Where did the examples go that [[User:K1n9 Duk3|K1n9 Duk3]] provided? Those examples were essential (atleast for me) in coding something to parse the format. I have some examples for the CGA tile format if we repost the old examples. -- [[User:Eros|Eros]] 12:31, 1 May 2012 (GMT)