Duke II map format - all worked out.

Discuss classic and favorite computer or console games here.
Post Reply
szevvy
Vortininja
Posts: 36
Joined: Thu Nov 01, 2007 15:04

Duke II map format - all worked out.

Post by szevvy »

As I may have mentioned at some point, Malvineous and I (he more than me) have been trying to figure out the last remaining bit of the Duke II level format - the stuff that aligns certain tiles.

Well...the final breakthrough was made today, my hat goes off to Mal.

A sample of the loveliness:
http://images.szevvy.com/o6.mni.png (linked as it's a big image) - you can see that the barrels looks perfect as opposed to, say, what Wombat 0.4a show.

The format is explained on Shikadi:
http://www.shikadi.net/moddingwiki/Duke ... Map_Format

Hooray!
User avatar
KeenRush
Android Dummy
Posts: 2560
Joined: Sat Oct 27, 2007 20:57
Location: KEEN1.EXE
Contact:

Post by KeenRush »

For some reason I couldn't access the picture you linked, but awesome job guys. :birthday Unbelievable that such complex thing can be solved.

If you guys aren't busy (yeah, you probably never are :crazy), is there any chance you could try to crack down the map format of SkyRoads? :begging http://www.bluemoon.ee/history/skyroads/ It's a game I'd love to edit. My attempts at it have been completely fruitless. But the small bit I've discovered is that all the level data is stored inside one file (can't remember its name right now, am not home), and the levels (those for which there is data in the level file) and game works fine even if you swap the level files from the X-Mas version or demo version. In the beginning of the file there's some header that marks where in the file the tracks' data begins (or something) and those are two-byte integers, and due that fact the level data is compressed some way, otherwise all the levels wouldn't fit in the file and couldn't be pointed with two bytes. Sadly that's all I know. Or well, I know the level backgrounds are their own image files, not stored inside the level file. It'd be so awesome to be able to edit the levels -- and preferably the vehicle graphics too. I can't remember if there was more data in the header... But if I'm not completely mistaken (as said, can't check my few notes now), there is some values in the header telling the length of the level, or more like the amount of blocks (as the levels consist of such) it requires; those numbers are always dividable by 7, and that way one can get to know how long a level is. There's alyways 7 blocks side by side. Changing that number to a proper one allows one to cut the level neatly, if I remember correct. :dead2
My newest mod - Commander Keen: Sunset: viewtopic.php?t=8568 | codename H.Y.E.N.A.
User avatar
Malvineous
Shikadi Webmaster
Posts: 382
Joined: Wed Oct 31, 2007 21:48
Location: Brisbane, Australia
Contact:

Post by Malvineous »

Hmm...the image works fine for me - you can view .png images? It is quite a large image, maybe it's too big for your browser? I've discovered a couple of other things with the levels in the last few hours, so that picture is already obsolete - I'm sure Szevvy will upload a newer version once he implements the changes :-)

I have had a look at Skyroads but unfortunately never found anything. I tried e-mailing Bluemoon to see if they'd be willing to share any info but I never heard back - perhaps you could try contacting them too, they might respond if there's enough interest.

I don't know about Szevvy, but I'm terrible at compression algorithms, so reverse engineering it is pretty much out of the question unless someone can figure out how to decompress the files.
User avatar
KeenRush
Android Dummy
Posts: 2560
Joined: Sat Oct 27, 2007 20:57
Location: KEEN1.EXE
Contact:

Post by KeenRush »

No idea, could be any setting on this computer. If I were home I'm sure it'd work in Opera (this one has Firefox :barf).

In fact, I didn't even think of mentioning it, I too have e-mailed Bluemoon, but got no reply either. :( That was perhaps more than a year ago.

Yeah, the format could be about anything. It also could be some kind of image format that's compressed. It could have multiple layers, which might be more possible than some colour representing all those different kind of blocks (some blocks are higher than others, some have those pipes on them etc...). Somekind of starting point could be that there are few layers, and in them the data for what kind of structure there is in the block and in which colour. But well, none of this is really helping, it's quite hopeless...

Edit: Who's good with debugger? 8)
My newest mod - Commander Keen: Sunset: viewtopic.php?t=8568 | codename H.Y.E.N.A.
User avatar
memsys
Vortininja
Posts: 229
Joined: Thu Nov 01, 2007 20:25
Location: Vortiville, Vorticon VI

Post by memsys »

so making levels for duke 2 is now posible ?
(i used to be ME!)
Image
Galaxieretter
Arachnut
Posts: 891
Joined: Thu Nov 01, 2007 2:35
Location: Lancaster PA
Contact:

Post by Galaxieretter »

Wow... that is some CRAZY STUFF!

Just out of curiosity, how do you figure this stuff out?
User avatar
Malvineous
Shikadi Webmaster
Posts: 382
Joined: Wed Oct 31, 2007 21:48
Location: Brisbane, Australia
Contact:

Post by Malvineous »

Not sure about Wombat but yeah, my editor's slowly getting there. I'm hoping to make an alpha release sometime over the next few months so that'll support editing Duke II maps.

And yeah, looking at it like that it does seem quite complicated. When you're figuring it out you're only looking at small parts of it though, so that makes it much simpler. You sort of get a feel for it, and start to recognise what things look like, and can make educated guesses as to what they might be used for. With DukeII this is how all the blocks of data were discovered, but the recent discovery of the "supplemental foreground data" was much trickier because it was different to almost anything we'd seen before.

In the end the time honoured method of hex editing was used, in that we'd load up a level file, change one of the bytes in the "unknown" data, then play the game and see what changed. Duke II was particularly annoying because almost every byte we changed had exactly the same effect - all the affected tiles "broke."

After a while a lightbulb went off and I realised that the data might be running through the level in a specific way, which was different to what I'd originally thought. This turned out to be true, and was the breakthrough that allowed us to look at the data in a completely different way, which meant when we returned to the hex editor we had a better idea of which bytes to change and why our previous changes broke every tile on the level.

After a few more hex edits we had a fair idea of how it worked, and it was time to return to our respective game tools and try implementing the format. Eventually after much fiddling and inspiration it all came together, and I started to see very obvious patterns in the ~200 lines of code I had to process the data, and realised we thought the format was a bit more sophisticated than it really was - so in the end I was able to simplify it down to ~15 lines of code, and that's what ended up on the wiki.

Now all that remains for me is to reverse the procedure so that it's possible to *save* a map, then I'll have a nice WYSIWYG Duke II editor :-D
Post Reply