Reply to Re: dink map specs sheet?
If you don't have an account, just leave the password field blank.
: Hey,
: It'd be extreemly usefull to me if someone would write a detailed documenat about how the dink map file works (dink.dat). I can open it, and read all teh values, but i have no idea how they work, or what they stand for. a pointer would be really usefull. the WDE source code has a bit, but i must admit, my MSVC skills are next to nothing (for obvious reasons, i think?)
: anyone willing?
Eh... just open it up, use a hex editor, and reverse engineer it. That is what I did for Map.dat and Hard.dat.
The actual Map file is stored in Map.dat anyway...
Hmm... I do have some documentation I wrote up for Paul, in order to motivate him to create Sprite Replacer... I suppose I could paste that here. Some of it might not make the most sense, as it was written for Paul. I might also have some stuff on Hard.dat around...
=-=-=-=-=-=-=-=-=-=-=-=-=-
MAP.DAT: SPRITES
=-=-=-=-=-=-=-=-=-=-=-=-=-
All of this was done by hex-editing and guessing, not talking to Gary or Seth about it, so certain things might not be right. Well, Gary did say there are several un-used variables like rotation and gold amount when he was working on WDE (Seth gave him some of the DinkEdit code to help him make it)... anyway, here is what I've found:
Each map square seems to take up exactly 31280 bytes of map.dat. Of those 31280 bytes, I don't know what the the first 8240 do (not sprites at least). Sprite data starts right after that mysterious 8240 chunk. Each sprite takes up 220 bytes. assuming that the 99 sprite rule is correct, the sprite data is between 8240 and 30020 of the map square. I'm not sure what goes on between 30020 and 31280, maybe tiles, haven't bothered to test yet.
In each 220 byte sprite, most variables seem to take up 4 bytes, with the major exception being the script name, which takes up at least 13 bytes (WDE limits you to this, for reasons I'm not sure. The actual limit seems to be 56 bytes). Maybe Seth left some extra room for directory names and the like.
Note the attached pictures (one being the WDE box that I used, the other being a peek at the map.dat data for that sprite).
(0-3) 2C 01 00 00 is X. (2*16^1 + 12*16^0 + 0*16^3 + 1*16^2) is 300
(4-7) C9 00 00 00 is Y (12*16^1 + 9*16^0) is 201
(8-11) CA 00 00 00 = 202, Sequence
(12-15) 03 00 00 00 = 3, Frame
(16-19) 01 00 00 00 = 1, Type (Background, Person, Invisible)
(20-23) DB 00 00 00 = 219, Size
(24-27) 01 00 00 00 = 1,
(28-31) 00 00 00 00 = 0
(32-35) 00 00 00 00 = 0
(36-39) 0F 00 00 00 = 15, Brain
(40-91) Script? Perhaps some unused variables after it.
(92-95) DA 00 00 00 = 218, Speed
(96-99) CD 00 00 00 = 205, Base Walk
(100-103) CC 00 00 00 = 204, Base Idle
(104-107) CE 00 00 00 = 206, Base Attack
(108-111) 00 00 00 00 = 0
(112-115) D5 00 00 00 = 213, Timing/Delay
(116-119) D0 00 00 00 = 208, Depth Que
(120-123) 01 00 00 00 = 1, Hardness
(124-127) 00 00 00 00 = 0
(128-131) 00 00 00 00 = 0
(132-135) 00 00 00 00 = 0
(136-139) 00 00 00 00 = 0
(140-143) 00 00 00 00 = 0, Enable Warp
(144-147) DC 00 00 00 = 220, Warp Screen
(148-151) DD 00 00 00 = 221, Warp X
(152-155) DE 00 00 00 = 222, Warp Y
(156-159) D2 00 00 00 = 210, Touch Seq
(160-163) CF 00 00 00 = 207, Base Death
(164-167) 00 00 00 00 = 0
(168-171) D9 00 00 00 = 217, Hitpoints
(172-175) 00 00 00 00 = 0
(176-179) D8 00 00 00 = 216, Defense
(180-183) D6 00 00 00 = 214, Experience
(184-187) D3 00 00 00 = 211, Sound
(188-191) D4 00 00 00 = 212, Vision
(192-195) 00 00 00 00 = 0, Nohit
(196-199) D1 00 00 00 = 209, Touch Damage
(200-220) unused.
That covers all of the parameters available in WinDinkedit... and I think thats all thats available in DinkEdit as well (not sure though).
Negative numbers are a bit... odd. I forgot how they usually work in hexadecimal, but they just seem weird here. Anyway:
-1 is FF FF FF FF
-2 is FE FF FF FF
-340 is AC FE FF FF
And so on. Maybe not that weird after all...
To get the Nohit, Hard and the like, I toggled them on and off and compared the new map.dat with an old copy.
There seems to be an awful lot of unused areas, but Gary did mention that there were a lot. And it is odd how Seth used integers for boolean-level operations (nohit and hardness). Heh, he really was a sloppy programmer
Oh, and it doesn't look like there is a variable for the editor number (or at least I didn't find one). Its probably determined by its order in the file.
-=-=-=-=-=-=-=-=-=-=-=-=-
Hmm, it appears I don't have any hard.dat documentation after all... all I have is a Perl program that converts the hard.dat file into a text file and bmp, and then back from a text file and bmp to the hard.dat. No documentation though...
: It'd be extreemly usefull to me if someone would write a detailed documenat about how the dink map file works (dink.dat). I can open it, and read all teh values, but i have no idea how they work, or what they stand for. a pointer would be really usefull. the WDE source code has a bit, but i must admit, my MSVC skills are next to nothing (for obvious reasons, i think?)
: anyone willing?
Eh... just open it up, use a hex editor, and reverse engineer it. That is what I did for Map.dat and Hard.dat.
The actual Map file is stored in Map.dat anyway...
Hmm... I do have some documentation I wrote up for Paul, in order to motivate him to create Sprite Replacer... I suppose I could paste that here. Some of it might not make the most sense, as it was written for Paul. I might also have some stuff on Hard.dat around...
=-=-=-=-=-=-=-=-=-=-=-=-=-
MAP.DAT: SPRITES
=-=-=-=-=-=-=-=-=-=-=-=-=-
All of this was done by hex-editing and guessing, not talking to Gary or Seth about it, so certain things might not be right. Well, Gary did say there are several un-used variables like rotation and gold amount when he was working on WDE (Seth gave him some of the DinkEdit code to help him make it)... anyway, here is what I've found:
Each map square seems to take up exactly 31280 bytes of map.dat. Of those 31280 bytes, I don't know what the the first 8240 do (not sprites at least). Sprite data starts right after that mysterious 8240 chunk. Each sprite takes up 220 bytes. assuming that the 99 sprite rule is correct, the sprite data is between 8240 and 30020 of the map square. I'm not sure what goes on between 30020 and 31280, maybe tiles, haven't bothered to test yet.
In each 220 byte sprite, most variables seem to take up 4 bytes, with the major exception being the script name, which takes up at least 13 bytes (WDE limits you to this, for reasons I'm not sure. The actual limit seems to be 56 bytes). Maybe Seth left some extra room for directory names and the like.
Note the attached pictures (one being the WDE box that I used, the other being a peek at the map.dat data for that sprite).
(0-3) 2C 01 00 00 is X. (2*16^1 + 12*16^0 + 0*16^3 + 1*16^2) is 300
(4-7) C9 00 00 00 is Y (12*16^1 + 9*16^0) is 201
(8-11) CA 00 00 00 = 202, Sequence
(12-15) 03 00 00 00 = 3, Frame
(16-19) 01 00 00 00 = 1, Type (Background, Person, Invisible)
(20-23) DB 00 00 00 = 219, Size
(24-27) 01 00 00 00 = 1,
(28-31) 00 00 00 00 = 0
(32-35) 00 00 00 00 = 0
(36-39) 0F 00 00 00 = 15, Brain
(40-91) Script? Perhaps some unused variables after it.
(92-95) DA 00 00 00 = 218, Speed
(96-99) CD 00 00 00 = 205, Base Walk
(100-103) CC 00 00 00 = 204, Base Idle
(104-107) CE 00 00 00 = 206, Base Attack
(108-111) 00 00 00 00 = 0
(112-115) D5 00 00 00 = 213, Timing/Delay
(116-119) D0 00 00 00 = 208, Depth Que
(120-123) 01 00 00 00 = 1, Hardness
(124-127) 00 00 00 00 = 0
(128-131) 00 00 00 00 = 0
(132-135) 00 00 00 00 = 0
(136-139) 00 00 00 00 = 0
(140-143) 00 00 00 00 = 0, Enable Warp
(144-147) DC 00 00 00 = 220, Warp Screen
(148-151) DD 00 00 00 = 221, Warp X
(152-155) DE 00 00 00 = 222, Warp Y
(156-159) D2 00 00 00 = 210, Touch Seq
(160-163) CF 00 00 00 = 207, Base Death
(164-167) 00 00 00 00 = 0
(168-171) D9 00 00 00 = 217, Hitpoints
(172-175) 00 00 00 00 = 0
(176-179) D8 00 00 00 = 216, Defense
(180-183) D6 00 00 00 = 214, Experience
(184-187) D3 00 00 00 = 211, Sound
(188-191) D4 00 00 00 = 212, Vision
(192-195) 00 00 00 00 = 0, Nohit
(196-199) D1 00 00 00 = 209, Touch Damage
(200-220) unused.
That covers all of the parameters available in WinDinkedit... and I think thats all thats available in DinkEdit as well (not sure though).
Negative numbers are a bit... odd. I forgot how they usually work in hexadecimal, but they just seem weird here. Anyway:
-1 is FF FF FF FF
-2 is FE FF FF FF
-340 is AC FE FF FF
And so on. Maybe not that weird after all...
To get the Nohit, Hard and the like, I toggled them on and off and compared the new map.dat with an old copy.
There seems to be an awful lot of unused areas, but Gary did mention that there were a lot. And it is odd how Seth used integers for boolean-level operations (nohit and hardness). Heh, he really was a sloppy programmer
Oh, and it doesn't look like there is a variable for the editor number (or at least I didn't find one). Its probably determined by its order in the file.
-=-=-=-=-=-=-=-=-=-=-=-=-
Hmm, it appears I don't have any hard.dat documentation after all... all I have is a Perl program that converts the hard.dat file into a text file and bmp, and then back from a text file and bmp to the hard.dat. No documentation though...
