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)

Ripping DKL sprites

Hi, I recently noticed that you ripped numerous DKL sprites, including a few unused ones. Can you please explain to me how you did that? And how do users rip unused graphics so flawlessly (like )? Yoshi (talk) 12:48, 3 January 2015 (EST)

My usual approach is to reverse engineer the game to figure out the relevant data formats. After doing that I write a script to extract the sprites directly from the ROM. It's a complicated process, but it can be fun if you're into solving puzzles. Blaziken257 (talk), the one who ripped that minus barrel sprite, does things similarly as far as I know.

Another way is to use a memory editor to force the game to display the sprite that you want. From that point it's possible to either take a screenshot or extract it from RAM. This method is also game-specific.

If you're interested in ripping sprites from the DKL games yourself or interested in knowing more about what is involved in doing so, then it may help to know that I've documented the relevant formats over at DataCrystal (see Donkey Kong Land, Donkey Kong Land 2, and Donkey Kong Land III).

--Shiny (talk) 16:34, 3 January 2015 (EST)

The way that I found the Minus Barrel sprite (and other unused sprites) was to use a custom Python script to generate metasprites from 16x8 tiles (based on your information) and outputting them to PNG images (PyPNG was a big help to me here). Once I did that, I wrapped this in a loop, which generated images (including each frame) for metasprite IDs 0 to 255 (of course, some of these were garbage data). That's the short explanation.

If you want to see these images from a memory editor, you can edit either RAM address C10F or DF0B (these correspond to GameShark codes 01xx0FC1 and 01xx0BDF, respectively). The former changes one of the sprites that is currently in memory (but not all of them), while the latter changes the sprite of your character. Note that this does not change the animation cycle!

In DKL2, here are 8-bit hexadecimal values of unused sprites:

• 39 - Early Kremkoin sprite.
• 54 - Rambi when he is hurt.
• 6F - Unused hole.
• 70 - Several miscellaneous barrels -- one frame is a Minus Barrel.
• 75 - A Kannon and a Kannonball, the latter of which has some unused frames.
• 7C - Unused flame.

These are the 8-bit hexadecimal values of unused sprites in DKL3:

• 30 - Yellow cursor.
• 39 - Early Kremkoin sprite, unused/leftover from DKL2.
• 3E - TNT Barrel.
• 5A - Diddy carrying something.
• 70 - Several miscellaneous barrels leftover from DKL2, including the Minus Barrel.
• 73 - All the animal barrels, including the unused Rattly barrel.
• 7C - Unused flame, unused/leftover from DKL2.
• 83 - Screech.
• 87 - Rambi charging.

I'll document this in greater detail on their respective pages when I have the time, but I'd like to get this more organized and include offsets of the graphics, as well as which frames are unused. --Blaziken257 00:30, 18 January 2015 (EST)

The long overdue metasprite addition to Donkey Kong Land

Hello. I realize that it's been over two years since you sent me a rip of all the metasprites in Donkey Kong Land. I apologize for taking a very long time, but I finally took a closer look at them to find what is used and what isn't.

• I'm highly certain that the defeated sprite of Chomps Jr. is unused, so I added it to the DKL page, and credited you.
• There's one sprite that appeared to be a couple of small rocks at first glance (6-29542-27 according to your naming scheme). However, it is actually the first frame in an explosion (caused by, for example, a TNT barrel). Here's a screenshot that I took where you can see the sprite being used: http://i.imgur.com/ZMosNAL.png

Everything else in your rip appeared to be used as far as I could see. Again, sorry for taking a really long time on this. I was busy when you first sent me the DKL metasprites, and then I forgot it for a while after that.

On a completely unrelated note, I've spent some of the past year looking at several Battletoads games, mostly the Game Boy ones. Not surprisingly, the engine for these games is similar to the one used for Donkey Kong Land (and its sequels, to a lesser extent). They even use the same Huffman format that the DKL games use for compressed tiles! Though I currently haven't found much worthy of being mentioned on this site, except for some possibly partially unused music in Battletoads (Game Boy), though I haven't played the game extensively to verify this. Oh well.

Also, a while before that, I was looking at the GBA versions of the DKC games, and I found a bunch of debug text stored in ASCII. Some of it is interesting (there's evidence of a test level or two), though I don't know if there's a way to make the text actually appear in the game. Finding the debug text is something, at least! --Blaziken257 01:42, 17 January 2017 (EST)