DKC Atlas Forum

[Simion32]

.
.
CLICK HERE TO BROWSE DOWNLOADS:
DKC Resource Editor - Program Releases
.
Please report all program bugs in the appropriate bug reporting topic once it is created by me.
Also, please discuss the bugs there, too, instead of in this topic, to keep things organized.
.
.

[Qyzbud]

Hey sweet, that's a very nice start!

The tiles aren't actually stored in coloured duplicates (eg. Caves: green/brown/purple...), are they? Surely not... You're just applying different palettes to the same basic graphics data as the extraction occurs, right? Another question; how does one view the raw GFX files, if indeed one can?

'Mine Shafts' should maybe be 'Walkways'

My 'Mine Carts' tiles came out bright pinky-purple... Just for your information!

[Simion32]

You're just applying different palettes to the same basic graphics data as the extraction occurs, right?

Exactly. I'm just having it extract all possibilities, since this is going to be used for the DKCLB.

Another question; how does one view the raw GFX files, if indeed one can?

There is a program called Tile Molester, I would recommend using that. You can just open the .GFX files directly, and then import a pallete form a savestate (I don't think it can import the raw .PAL files that this generates...). You need to have Java installed on your computer to use Tile Molester, though. Basically what these .GFX files are, is the graphics which are decompressed into RAM memory for display. Of course, instead of loading them into RAM, the tool outputs the graphics to files instead. So effectively you can read these GFX as if you were looking at a save state.

Mine Shafts: Ah, I got that name carried over when I was looking up data addresses in giangurgolo's documents. I'll fix that.
That pink color may be due to your display driver or something. It won't matter anyway once I correct whatever is causing the tiles to be mono-chromed.

Also, after these problems are fixed, I plan on coding the tool to generate HTML tables of the tiles, similar to the "Tile Set Collection" which used to be on giangurgolo's docs page. The next thing on the list would be to extract level tile-maps and then have all of the levels mapped out into big .PNG's. Fortunately, this should not take as long because I am past the confusing parts. Making the alpha correct was difficult, I even somehow managed to get photo-negative tiles once.

[Cyclone]

Great work Simion!

Got a few curiosities.

- Probably obvious but are you also going to include extraction of sprites/background objects in png formats like you did with the level tiles?
- How did you manage to accurately include the alpha channels? This was the most impressive part of the program so far. Good job!
- What part of the rom actually contains the information that combines the level tiles together? I'm assuming your not going to join them by hand.

I did a quick test and mapped a few tiles of DK’s tree house and everything matches perfectly to my zsnes screen shot. Keep it up.

[Simion32]

Got a few curiosities.

1. Yes, I am going to make it assemble those also.
2. The alpha channel is really just a number 0-255, but the way I was using before it was correct caused strange effects.
3. I don't know that off the top of my head, but you needn't worry, I'll (eventually) post the offsets so Qyz can get them on the main site.

[nackhe]

The extraction tool doesn't seem to work for me...
I'm pretty sure I have the right ROM version and all, but nothing is happening.
It made a few submaps and says it's extracting, but I waited like 5 minutes and nothing happened at all.

Edit:

Never mind!
I got it to work!
Turns out I was using the wrong ROM after all

Anyways, good job simion, looks awesome!

[Simion32]

Anyways, good job simion, looks awesome!

Thanks! (I'll edit in a notice saying to be sure that the ROM is a verified clean dump.)

[Simion32]

Alright, I've fixed the Mine Carts monochrome-pallet problem. It turns out that the Mine Carts tile set doesn't use its own separate pallet, it uses the same pallet as the Mines do. I still haven't a clue what is messing up the Temples/Snow Glaciers tile sets...

While fixing that I found yet another error - I forgot to make it create a folder for the "Factory" tile set, therefore no tiles are generated.
If you really must see the factory tiles, you can put a folder named "Factories" in the "Resources\Tilesets\" directory and it should work.

While I was investigating why the temple graphics don't show up correctly, I found this in the raw graphics:

Strange.png (6.1 KiB) Viewed 850851 times

I wonder what that was used for?

I haven't quite tracked down the problem, but it seems that the Temple tileset ends up requesting an 8x8 tile which is at an out-of-range location, greater than the size of the GFX file. Any time the graphics go out of range, it ends up generating weird lined 32x32 tiles. You can see this effect with tile 0001.PNG in the Temples folder - the first half of this tile at least has SOME graphics, and everything beyond that point is 'corrupted'.

[Qyzbud]

It turns out that the Mine Carts tile set doesn't use its own separate pallet, it uses the same pallet as the Mines do.

Interesting, the mine cart tracks appear in Mine Cart Madness, which uses the Walkways tile set... Do you suppose part of the palette for Walkways is designated for the colouring of the tracks also, or do you think the game calls on a separate palette for colouring Mine Cart Madness' tracks?

Temple and Snow terrains seem pretty simple in design/composition... I've no idea why they should break the rules. If it was only the temples which were acting up, I would imagine it may be something to do with their animated background graphics. That strange tile jumble you attached to your post includes the numbers 1-6, which is something I have seen when working on freezing the animated torches for mapping purposes. Leads me to think that the animation is what's causing problems.

temple_bg_anim_placeholders.png (11.16 KiB) Viewed 850831 times

The image above shows a side-effect of a code I created to freeze banana animations. If (when entering a temple level) you activate the PAR code (7E002800) as the map screen is fading to black, you will be greeted with not only frozen banana animations, but also this numeric sequence in place of the animated torch in the background. I don't know if this is relevant to what you are working on here, Simion, but it seems that it could be.

Interesting how Rare made those numbers look nice, even though they weren't to be seen by anyone other than us hackers, eh?

[Simion32]

Interesting, the mine cart tracks appear in Mine Cart Madness, which uses the Walkways tile set... Do you suppose part of the palette for Walkways is designated for the colouring of the tracks also, or do you think the game calls on a separate palette for colouring Mine Cart Madness' tracks?

It's set up is like this:
All Mine Levels and Mine Cart Carnage = Mines Pallete
All Walkway Levels = Walkways Pallete
Mine Cart Madness is a Walkways level since it uses walkway platforms, and that tile set contains the tiles for cart track. However, Mines and Mine Carts are two separate level archetypes. Each pallet contains colors for the mine cart tracks. There is no single designated tracks pallet, instead, it uses colors from whichever level pallet the game is using. But, this means that the cart track graphics are stored twice in the ROM, since they use different pallet entries with each level type.

I don't know if this is relevant to what you are working on here, Simion, but it seems that it could be.

I don't necessarily think that's the problem, as these numbers (as in the picture I attached) were extracted correctly from ROM. The main problem is that, after comparing to a savestate, it looks like about %25 of the raw graphics are missing from the Temples.GFX file. When it tries to access an 8x8 tile which doesn't exist, it causes a read error and all following tiles fail to generate.

Which leaves me with two possibilities... Either there is something wrong with the decompression part of the tool, OR the Temples tile set is somehow formatted differently than the other tile sets (eg. the TIS file), which is inherently read the wrong way causing the GFX read error.

[Qyzbud]

...the cart track graphics are stored twice in the ROM...

Seems rather inefficient. I wonder why they did it that way. I understand what you said, but I'm sure they could have found a more memory/storage efficient way to achieve an identical result. If they used another method, perhaps you would have more than 2KB to play with in the ROM file.

Regarding the Temples tile set: So you don't think that maybe the extractor is having trouble when it encounters the animated graphics? I'm no expert (just a dabbler), but I would think that animated graphics would be stored/retrieved in a slightly different way to standard 'static' background graphics. I wasn't saying that the jumbled tiles you extracted were erroneously obtained, but that the numbers suggested to me that it was something to do with the animation 'placeholders' I attached above.

[Simion32]

So you don't think that maybe the extractor is having trouble when it encounters the animated graphics?

I don't really know, it just seems unlikely. I don't even know how rare was able to animate background tiles in the first place, I think it's in the same way that Mario games have animated lava/water.

I'm going to have to find these animated torches anyway, so maybe I can figure out how exactly they are accessed. I am currently unaware as to the exact cause of the error. Anything is possible, especially with such a complex game like DKC.

I'll do some manual layouts of tiles from the Temple's tile set and see what I come up with... it may give some clue as to what's going wrong.

[cfh]

But, this means that the cart track graphics are stored twice in the ROM, since they use different pallet entries with each level type.

This is very strange... why didn't they just place the colors in the same location in each pallet? This would work on the GBA, I dunno about SNES but I assume it's similar...

[Simion32]

Well, I think I've found what has been causing all this trouble: Gnawty Millstones! (pun intended) The millstone graphics are loaded in before the actual Temple graphics, which offsets them by quite a few tiles. However, instead of being normal, the tile set has to account for these Millstones being 'part of' the tile set, and thus have a higher offset than if there were no Millstones. I expect something similar with the Snow Glaciers tile set.
*image removed by me*
EDIT: I also noticed how the background torches are already replaced. Perhaps that's how they get the graphics to animate. I suppose they just swap the tiles before they are displayed. Now it should be easy to find the location of the torch graphics!

[Qyzbud]

Good job, Simion. I was actually going to mention the millstones as a possibility, but I was convinced that the torches were to blame!

I can't think of anything remotely similar that could be messing up the snow tile set, though... Perhaps the blizzard effects/snowflakes?

[Simion32]

Yep, that was the problem. I had my extractor subtract 277 from the tile number and it generates all of the Temple tiles just fine.

I can't think of anything remotely similar that could be messing up the snow tile set, though... Perhaps the blizzard effects/snowflakes?

I looked at a savestate of Snow Barrel Blast, and there doesn't seem to be anything preceding the level graphics... this may be a bit more tricky to figure out.

[Simion32]

Alright, I'd like to say that this time the culprit was indeed the animated background tiles... it was another easy one to fix, I just had to know what was going on.

The Snow Glaciers tile set uses several different "blank" tiles which are actually placeholders for the layers of animated snow, but these are stored after the level graphics, which was causing my extractor to mess up.

Also, I've just now found the location of the Water Corals tile set, so those should be extracing just fine.

I'll have CFH re-upload the extractor later, when I have added more basic features like generating level maps and HTML tables of tiles, extraction of tilemap data, and possibly some other things.

[Cody]

Your program is fabulous. I know it will eventually replicate level terrain, but is it ever going to extract full level maps (down to the enemy locations), like Qyz' Jungle Hijinx map?

Also, one tiny question...are you ever planning on working on perhaps a tiny ROM editor for Donkey Kong Country, which could maybe let you move/change (but not add) terrain and enemies? That would be great and would probably satisfy the thousands of fans out there eagerly awaiting a DKC level editor

[Simion32]

is it ever going to extract full level maps (down to the enemy locations), like Qyz' Jungle Hijinx map?

Maybe this will be possible once I have more information on objects and stuff such as that. It would qualify as part of a level map, so when possible I'll add that as a feature.

Also, one tiny question...are you ever planning on working on perhaps a tiny ROM editor for Donkey Kong Country, which could maybe let you move/change (but not add) terrain and enemies? That would be great and would probably satisfy the thousands of fans out there eagerly awaiting a DKC level editor

I may do just that, although you will be limited to the space that levels take up with a limited amount of objects. I wanted to make a quick "editor" so that I could make my own hacks easily, as well as replicate the "Awesome Hack" of Reptile Rumble. However, I may not be able to have too much of a GUI, as I don't know how/where sprites are stored in DKC - maybe a list of objects to place, but nothing more. You could expect a graphical terrain editor, though. Please note that if I do make it, said tool will not be top priority.

[Cody]

Nice. I look forward to the final project (if it will end up existing)

[Simion32]

OK, I'd just like to announce that all normal levels are now extracting correctly. I have added a Yes/No option so that you can avoid taking up disk space if you don't need/want to extract level maps.

However, I am now seeing some serious problems with the extractor at this point - memory leaks and random crashes! It should not take up a lot of memory before/after doing its operations, but by the time it finishes (and when choosing to make level maps) it is taking up around 730MB of RAM!! Something is really screwed up with my code, so I'll have to fix this before I release the next version of the tool.

All extracted level map PNG's (only main levels; not bonuses, boss levels, or things like DK's treehouse) take up a total of 24.6MB (25,873,835 bytes).
ALL extractable data so far takes up 31.2MB (32,802,557 bytes).

[Qyzbud]

So, my old techniques for mapping levels by hand are now officially redundant, eh? This is rather a bitter-sweet turn of events, but if I look at it from a practical standpoint, it's wonderful news. How far do you suppose this tool will evolve? Any plans for an eventual GUI, or a resource replacement function, a bit further down the track?

[Simion32]

Yes, I suppose those methods are now redundant, but making this tool took quite a bit of effort; I'd say it's only a slight bit easier than using screen shots and pasting them together because of all the technical stuff I had to understand to make it work. Remember, I will be making such a tool for DKC2 and DKC3 as well.

I do plan on making a GUI eventually, I may even integrate a small ROM-editing tool (like what I mentioned above) into this tool, and it can be called a "Resource Editor". I just want to get the basics down first, before trying to make a fully-working GUI. As for resource replacement, level maps and sprites within these maps will be editable. I really couldn't make a graphics editor, since I don't know how to re-compress the GFX files (and re-compressing them would end up producing data a different size than DKC's original compressed graphics). So, I guess you could say my mini-ROM-editor is now confirmed as one of my projects!

I'm fairly certain that the memory leaks are being caused because I'm not getting rid of the file I/O streams... file streams are the only thing I can think of that would take up that much memory.

In fact, most of the level-tile-map addresses which giangurgulo documented were incorrect. Although very small inaccuracies, they are inaccurate nevertheless, so I am putting together an Excel file of all the memory addresses I use in this tool. Qyz, wouldn't you need this kind of thing for the ASM Addresses page?

EDIT: The memory leaks are fixed. One of my program loops in the level maps part kept generating 32x32 tiles when loading them from the PNG's, but they never got deleted, causing massive memory consumption. Unfortunately, CFH is currently in Florida, so he can't upload the current version - you'll have to wait to get an update.

[Simion32]

UPDATE!
DOWNLOAD: *see releases forum to download*

OK, here's the update you've all been waiting for. The only maps left to add in are bonus rooms and other miscellaneous stuff. You now have the option to generate level maps of all normal levels, which are also 32-bit translucent PNG's.

[Qyzbud]

That's great news, Simion; I can use these extractions to verify the accuracy of my terrain maps, and vice versa (in case of ripping anomalies).
Once I've had a chance to put this new release to good use, I'll give some proper feedback.

Proper feedback: Well, your extractor just did something in around 5 minutes that I took several months to complete... Good work!

Some notes:

• Tiles are missing/corrupt around the light graphics in Loopy Lights.PNG and Stop & Go Station.PNG
• The extra 'scenes' at the end of Manic Mincers.PNG don't appear using my mapping techniques.
• I see the Temple level PNGs have those numeric place holders I pointed out earlier.
• In the Mine Cart Carnage.PNG, the cart-rails appear, but not the terrain tiles immediately behind them... (you know this already, I know...)
• I'm surprised to see that Ropey Rampage.PNG uses the 'daytime' jungle palette, as it starts in darkness...

Nothing else seems strange. Despite how muddled/incomplete some of these terrains may look, that's indeed how they were designed by Rare.

Suggestion: I don't know if everyone would want this, but since this tool is currently an 'all or none' extractor (meaning you can't just pick which map you would like to extract), it may be sensible to give the PNGs a 1-1, 1-2 etc. or a 01, 02 etc prefix, so that they sort in gameplay order once extracted. Just a thought.

...most of the level-tile-map addresses which giangurgulo documented were incorrect. Although very small inaccuracies, they are inaccurate nevertheless, so I am putting together an Excel file of all the memory addresses I use in this tool. Qyz, wouldn't you need this kind of thing for the ASM Addresses page?

All of this data would be very handy for the site, as I want it to function as a complete technical guide, not just a glorified list of levels and glitches, etc. I'll talk with you further about this via PM. (Edit: Thanks, by the way!)

[Cody]

Suggestion: I don't know if everyone would want this, but since this tool is currently an 'all or none' extractor (meaning you can't just pick which map you would like to extract), it may be sensible to give the PNGs a 1-1, 1-2 etc. or a 01, 02 etc prefix, so that they sort in gameplay order once extracted. Just a thought.

There's a simple way to get around that: If you arrange the icons by "Modified", it will list them in gameplay order.

Simion, great tool! I really am impressed.

[Simion32]

Loopy Lights and Stop & Go Station: I don't think the tiles are corrupt, it may be something more to the effect of the numeric placeholders in Temples... both of those levels use variable lighting, which requires swapping pallets; However, the pallets it swaps to/from may use different background tiles. I may try to track down why exactly this is, but as of now I'm not entirely sure.
Manic Mincers: A slight mistake on my part. I observed that the majority of the levels are rounded to the next 256 bytes because this would be an exact number of 'screens'... however, I accidentally re-adjusted the data-length value for Manic Mincers whilst correcting the other levels (the data rate in a tile set is 32 Bytes per column of tiles). I should have gave the extractions a once-over before releasing this version...
Ropey Rampage: That is, as far as I can tell, a fancy pre-calculated pallet effect. It's probably a graphical "subtract" operation, which basically decreases every color in value. The weather modifier is used as an indicator when to dynamically shift between these pallets, but only one real hard coded pallet is used. I'm very sure that is how this effect works, but further investigation may be required.

Suggestion: give the PNGs a 1-1, 1-2 etc. or a 01, 02 etc prefix.

I'll add that, it will make it just that little bit easier to work with.

Simion, great tool! I really am impressed.

Thanks, more is on the way!

Hmm, I wonder what that platform at the very bottom of Treetop Town is/was for... that's the spot with the second bonus level, isn't it? I'd like to find out just what the heck they hid down there. I'm pretty sure it has something to do with the safety-return sequence of barrel cannons, which I assume were put in place just in case you try to go to the bonus again after you have already been there.

[Stone]

I've tested the Extraction now and it works until it askes to create level maps after pressing y.

And I'm sure that I have the [U] 1.0 [!]
I'll try it on a second PC tomorrow. Maybe I should check the checksum of the rom

P.S.: The tiles generated first are all white, i think that's not normal

[Simion32]

I've tested ...... tiles generated first are all white, i think that's not normal

The ROM is probably hacked/corrupted. If some tiles are all white, that suggests to me that someone was trying to zero-out the tile set(s). And, you must make absolutely sure that you have a verified [!] ROM. Just open it in ZSNES, it should come up with a message saying "BAD ROM" at the bottom of the screen if it is indeed bad.

Are you sure you pressed only the y key and then enter? Anything other than "y" (without the quotes) will be interpreted as a no. I'm sure that's not your problem, just saying that it's a possibility.

[Stone]

Mhhh, there is no Bad Rom sign, it says Checksum: OK

CRC32 is C946DCA0, is that OK?

[Simion32]

That is the correct checksum, but can you tell me which tiles (which specific tile set) are white?

[Stone]

Every tileset is white, only Ship Deck has tiles that are non-white.

It is also the only one extracting without this message:
Opcode 0x20 found at $389707 is unemulated. The operation failed!

[Simion32]

Opcode 0x20 found at $389707 is unemulated. The operation failed!

That's one of my built-in errors, it's part of the graphics decompressor.

What's more is, the address $389707 should NOT have a value of $20, it should be $A2 according to my decompressor routine Excel documentation.

Which means, (part of) the decompression routine in that ROM is corrupted, even though the checksum is correct! How strange... I guess you will have to find a different ROM. There is also a possibility that you have a different version, but I doubt that it's different due to the seemingly correct checksum.

If you get a correct ROM and this still happens, it may be a computer-specific error.

EDIT: Ship deck doesn't get the error because the Ship Deck graphics are not compressed, and don't use the decompressor routine.

[Cyclone]

You’re making great progress on this tool Simion. Thanks for sharing.

[Qyzbud]

Why would ship deck graphics not be compressed, if all other graphics are?

[Simion32]

Why would ship deck graphics not be compressed, if all other graphics are?

I suppose that Rare wanted the graphics for the final boss to look the best possible, so they left them uncompressed.

[Qyzbud]

Wait- so when we're talking about compression... it's lossy compression?? I didn't consider that for a second...

[Stone]

I'll try it again tomorrow, and on my fathers PC. Haven't found a clean ROM yet, and I'm tired

[Simion32]

Wait- so when we're talking about compression... it's lossy compression?? I didn't consider that for a second...

I don't really know if it is lossy or lossless, as I have no way to try re-compressing any graphics. I would assume that the scheme was designed to be lossless. From what very little knowledge I have about compression, it seems to be a form of RLE compression (Run-Length-Encoding) or it has similar features. I really have no idea exactly what it is, though. Another anomaly is that these graphics are within the first 64KB of the ROM, and are accessed directly instead of from RAM.

[Qyzbud]

I won't pretend I have a proper clue about this, but my speculation is as follows... Could it be that Gang-Plank Galleon's graphics are uncompressed because they are never used in any other parts of the game? This doesn't make a lot of sense, because there would be many other areas which use one-off tiles, like DK's treehouse, Kong helper areas, and all that... Although your extractor doesn't deal with them yet, does it? Maybe they are also uncompressed?

[Simion32]

Maybe they are also uncompressed?

It's possible... as far as I know, only the main level archetypes' graphics are compressed. I'd assume everything else isn't compressed, although I may be wrong. The title screen graphics are not compressed, I'm sure of that.

[Qyzbud]

I just want to clarify something... Is it the actual graphic tiles which are compressed with level archetypes, or are we talking about the level layout data from which the game reads how tiles are to be assembled to create the level terrain? It sounds like you mean the tiles themselves, but I thought I would just double check.

How is the level layout data stored/read within the game? I guess this info will be in the docs you send me...

[Simion32]

It sounds like you mean the tiles themselves, but I thought I would just double check.

Yes, the raw 8x8 graphical tiles.

[Stone]

Now I have found another ROM and it doesn't work, too.
Time to test it on the other PC.

P.S.: Dumps are from 1997 and 2001. I've seen that there is one from 1999. Delete this if it provides too much ROM information.

Edit: It doesn't work on PC #2.
Edit2: Now I've done a download overkill and finally found one that works from 2004. The tiles from Ship Deck look much better, too.

Very nice tool

[Simion32]

...finally found one that works...
Very nice tool

I forgot to mention (too late now though... ) - the ROM must be header-less. Meaning , if the file size is 4,194,304 bytes (exactly 4MB), then the ROM has no header. But if it does, the file would have data inserted at the beginning, thus making it larger. This also would offset the game's data by a bit, so I'm not surprised you found 'correct' ROMs that didn't work. If you were to remove the header, those other ones may have worked.
I have now edited my first post to say that the rom must be headerless.

[Tompa]

Oops, can't believe I missed this topic.

Anyway, I tried the program and ending up having the same problem as Stone had. And I'm pretty sure that I'm using the correct ROM for it.

Could someone just make a rar file with all the stuff and upload...?

[Simion32]

Could someone just make a rar file with all the stuff and upload...?

No, I thought that was against the forum rules. Just open your correct ROM file in Gieger's SNES9x Debugger, and it will ask to get rid of the header info. If the ROM has a header it will not work!

[Tompa]

I didn't mean that someone would upload the rom, but the level maps=P.
Anyway, I got the map from Qyz at least.

Do you think you can help me with my other question, Simion? To see what is solid walls and not in water levels.

[Qyzbud]

Being able to determine the exact 'tangible surfaces' of a terrain would be great. As Tompa suggested, much of any level terrain is purely graphical... Do you know, Simion, if the tangible boundary surfaces (not sure of the generally accepted term for this concept) are stored as separate level data? How does the game keep track of what is a floor/wall? This knowledge must be critical for recreating the engine and building levels... what can you tell us?

Re: copyrighted content
Mmm... this copyrighted content thing is a bit of a grey area. I think sprites/terrain maps/sound effects are fair game to be shared, as long as there is no claim to ownership, or for-profit use. I don't personally have a problem with game media content being shared here... all of our projects are created out of respect for and appreciation of the original works, so we're borrowing this media in good faith. I'm planning to have all in-game media hosted on the site before too long anyway, so it would be strange for me to restrict such sharing on this forum. I still very much admire Simion's efforts in regards to abiding by copyright laws, and I probably deserve a slap on the wrist for the maps and graphics I've uploaded already... but like I said; it's all done with the utmost respect for the original content creators.

[Simion32]

I will somehow try to add header detection to the next version of the tool, now that I see that's become a problem.

Do you know, Simion, if the tangible boundary surfaces (not sure of the generally accepted term for this concept) are stored as separate level data? How does the game keep track of what is a floor/wall? This knowledge must be critical for recreating the engine and building levels... what can you tell us?

Unfortunately, I have been so busy working on this extractor, that I haven't had time to hack the physics system. Don't get me wrong - this extractor is an integral part of the DKCLB, and I need to complete this tool first because it will deal with converting the game's data into a format readable by DELTA and/or the Level Builder. I will soon be on summer break from school, which will give me tons of time to work on hacking the very intricate parts of DKC. Once I do hack the physics, this tool will be able to extract physics data and stuff like that (and convert it to a much more sensible format, of course).

What I can say is that there are certain "physmaps" and "tilemaps" for each level archetype, and they are used to determine the physical properties and such. But note that I am NOT talking about the level tilemaps, rather these are something entirely different. These special tilemaps contain a listing of every tile in the tileset, that's about all I currently know about them. It seems similar to some stuff I've seen while hacking SMW using Lunar Magic; it may give some clue as to why these special tilemaps are needed - it may involve some sort of SNES requirement or something.

I also haven't figured out how physmaps are interpreted; for example, a certain number ($45, i think) somehow represents a jump-through platform. I changed the first byte in the Jungles physmap to this number, which resulted in DK being able to walk on every blank 32x32 tile, as if they were solid! However, I don't know any further details as to what does what. More details will be revealed once I have a chance to do some in-depth hacking.