"Oh, wow--that totally rocks!
Thanks a million. You've saved me an incredible amount of work."

Mon Ful Ir, Aug 29 2008

"So I checked out the XSLT converter and my goodness: this is an amazing piece of work!
It's fantastic that you can convert DUNGEON.DAT into XML because this info can be used by anyone now (well, anyone who knows how to use XML files).
Excellent work!"

Gambit, Feb 13 2008

"Greatstone's work looks interesting."
Paul Stevens, Feb 14, 2008

i'm gathering info enough to render complete dungeon viewport (DM snes style) in some ways: (i) using sck (swoosh construction kit) to extract viewport information. it includes decoder for "558 item", very excellent!
Kentaro, Mar 11 2007

Specification 1.0

16 February 2003
This version:
Last version:
Christophe Fontanel

Table of content
2.First line
3.Attribute1: item number
4.Attribute2: item type
5.Attribute3: item attribute
6.Attribute4: description of item (generic)
7.Attribute5: description of item (detailed)
8.Attribute6: comments

1. Preambule
As requested by rain, here is how I designed the .map files used by my data file decoding script.
If you want to use the .map files from my script in your own programs, fell free to do this and read the following for your information.
2. First line
Each .map file starts with a line containing the file format and endian.
Then there is a line for each item in the data file containing 6 attributes separated by ",".
3. Attribute1: item number
This is not necessary for the program (which reads line by line) but it makes it easier to edit the file manually because you don't have to rely on line numbers (the first line of the file is for format description, so the first item (item number 0000) is on line 2!).
4. Attribute2: item type
For the few RAW1 items in DM and CSB that holds data about creatures, etc... I planned to use DAT1, DAT2, DAT3, DAT4, etc...
5. Attribute3: item attribute
For images, I plan to put there a PALx value, indicating the palette number to use for the item. The correct palettes are stored in one of the DATx items at the end of the Atari ST graphics.dat file, but I did not extract them yet. The palettes would then be stored as standard Microsoft .pal files. Palettes should not be stored directly in the map file to minimize its size and to make it easier for us to change palettes without changing .map files.
For sounds, this attribute is already used, with SPRx values, indicating the sample rate to use for the sounds. The different sample rate values are coded in the script itself, look for them in the BuildWAVHeader function (they should be moved to an external .ini file for easier changes). I prefer not to incldue the sample rate values directly in the .map file because we are not sure of the exact values of sample rates (they are pure guess most of the time, based on my hearing). It is easier to change them in the script or .ini file than changing it on all items in .map files.
For other items, the NULL value is used. Maybe in the future we will have to put something here.
6. Attribute4: description of item (generic)
See Attribute5.
7. Attribute5: description of item (detailed)
These two values should describe the content of the item. I split this description in two parts. The first part should be correct for every graphics.dat file (even edited ones) and the second should be more descriptive of the original content or the customized content.
In the DM PC English graphics.dat file, item 0639 is described like this in the .map file:
0639,IMG3,PAL1,Creature 17 (Front),Giant Wasp,
The first description will always be true: item 0639 will contain the front view of the 17th creature.
The second description is the name of the creature in the original data file, but it could change in custom graphics file with new creatures (in that case, either we ignore that second part of description, or we build an updated .map files with new descriptions).
8. Attribute6: comments
Rarely used as of now, maybe not at all.