User talk:Shiny

The sprites in the DKL2 unused bonus stage map

Hello, sorry to bug you, but I noticed that you were able to add all the sprites for the map of the unused bonus stage in Donkey Kong Land 2 here. May I ask how you pulled this off? Did you do this all by hand, or did you find some way to automate this process? I'm asking because while I've been able to rip maps for the DKL games with a custom tool that I made, I could only figure out how to get the background portion, not the sprites, because that was a pain to figure out. I had to do sprites by hand, which was tedious, which you can see in some other maps that I uploaded for both the DKL2 and DKL3 pages. So were you able to rip sprites as well? If so, then I'm really curious as to how you were able to do that.

In addition, prior to this, I noticed these ripped maps for DKL3 here, which likewise include sprites. Were you the one who ripped these maps? I assume you were judging from the name. Again, I'm curious as to how you managed to include sprites if that was you who did all this. Thanks! --Blaziken257 21:59, 27 November 2014 (EST)

Hey, that's a familiar name. I read some of your writings about Donkey Kong Land 2, but only after figuring things out independently. Had I seen them earlier, it would have been a huge help- especially for figuring out the graphics compression (the hardest part, in my opinion).

Hello, sorry to bug you, but I noticed that you were able to add all the sprites for the map of the unused bonus stage in Donkey Kong Land 2 here. May I ask how you pulled this off? Did you do this all by hand, or did you find some way to automate this process?

Except for the character, the map was ripped (sprites included) by some monster of a Python script. I don't plan to release the script publicly (it's quite a mess).

I'm asking because while I've been able to rip maps for the DKL games with a custom tool that I made, I could only figure out how to get the background portion, not the sprites, because that was a pain to figure out. I had to do sprites by hand, which was tedious, which you can see in some other maps that I uploaded for both the DKL2 and DKL3 pages. So were you able to rip sprites as well? If so, then I'm really curious as to how you were able to do that.

I figured out how to rip sprites by looking at the game code and messing with the game in a debugger. After doing so, I assigned one to each object type (an animation ID and an animation frame index). Since there's no easy way to do that automatically, I ripped all the animations as separate images files and picked whichever one made the most sense. It was also necessary to account for objects that are displayed in non-standard ways (ex. single bananas, KONG letters, most kinds of barrels).

In addition, prior to this, I noticed these ripped maps for DKL3 here, which likewise include sprites. Were you the one who ripped these maps?

Yes! And you can expect full maps of Donkey Kong Land 2 as soon as Jon Leung (curator of VGMaps) finishes processing them.

--Shiny (talk) 08:58, 28 November 2014 (EST)

Thanks for responding. First, I'm sorry that you had to figure out certain things independently after I already had. Had I known that you were working on this too, I would have shared information with you. And yes, I do agree that the compression format for maps was a pain in the neck to figure out.

I do use a debugger myself (I use BGB), otherwise I would have never figured out how maps are compressed. I had limited success with sprites, though, and while I thought you might have found a way to rip sprites entirely automatically, it looks like you had to do part of that by hand too due to how difficult it is. You were able to do more than I could, though.

Just for one example, I noticed that starting at offset 0xE829 in DKL3 (both the GB and GBC version), there is data for Bear's animation. I couldn't figure out what the data was doing (when I used a disassembler, there seemed to be numerous, numerous conditional jumps shortly after 0x1ABF in the GBC version). However, I did notice there were a couple of bytes that were changed between versions, which broke Bear's animation in the GBC version. And it seems that all sprites follow this type of format, too.

I understand from a high-level perspective what you were trying to do, and I am glad to see other people hacking the DKL games besides me, it's just that things like this can be time consuming to figure out, if you understand. Anyway, thanks for all your effort!

Also, now that you have been able to rip sprites, I wonder if there are level differences between versions that I missed (besides the changes in Bramble Blast, Parrot Chute Panic, Kreepy Krow, and Tundra Blunda). --Blaziken257 16:30, 30 November 2014 (EST)

And yes, I do agree that the compression format for maps was a pain in the neck to figure out.

The map compression has many different control codes to figure out, but it's still just an LZ-derivative which are very common in GB/GBC games. The graphics compression, however, surprised me. But maybe that's just because I didn't know what Huffman coding was.

I do use a debugger myself (I use BGB), otherwise I would have never figured out how maps are compressed. I had limited success with sprites, though, and while I thought you might have found a way to rip sprites entirely automatically, it looks like you had to do part of that by hand too due to how difficult it is. You were able to do more than I could, though.

Just to clarify: ripping the sprites was automated but assigning animation IDs to each object type ID was not.

I've only ever seen one game where it was easy to automatically assign sprites to objects (Quest RPG: Brian's Journey). For most games (including DKL1-3) it's necessary to manually assign some kind of "sprite ID" to each object type ID. Some games do things a little differently and draw sprites manually. For those games, assigning sprites requires reversing lots of object-specific code *shudder* (Tasmanian Devil: Munching Madness does this).

Also, I added some information about Donkey Kong Land III's animation format to DataCrystal (see http://datacrystal.romhacking.net/wiki/Donkey_Kong_Land_III:Notes#Animations ). There's enough information there to rip most animations (barring a few special cases).

Just for one example, I noticed that starting at offset 0xE829 in DKL3 (both the GB and GBC version), there is data for Bear's animation. I couldn't figure out what the data was doing (when I used a disassembler, there seemed to be numerous, numerous conditional jumps shortly after 0x1ABF in the GBC version). However, I did notice there were a couple of bytes that were changed between versions, which broke Bear's animation in the GBC version. And it seems that all sprites follow this type of format, too.

I don't know anything about why Bear's animation is broken, but as far as I know data for Bear's animation (animation ID=0x45) is at 0x1F3A0, not 0xE829.

Also, I'm not sure what the code at 0x1ABF is doing either since I seem to have largely ignored it when reversing the code. It appears to be jumping based on a level ID.

Also, now that you have been able to rip sprites, I wonder if there are level differences between versions that I missed (besides the changes in Bramble Blast, Parrot Chute Panic, Kreepy Krow, and Tundra Blunda).

My scripts don't currently support other game versions. Adding support for them is a possibility, but I'm currently busy mapping the first Donkey Kong Land (backgrounds are done, but objects are missing since the format is different).

--Shiny (talk) 10:59, 1 December 2014 (EST)