DKC Atlas Forum

[jonesy47]

Hey guys. My question is pretty much what the title asks.

How would one go about being able to the edit the player sprites (dixie and/or kiddy) in Donkey Kong Country 3? An editor? Something that decompresses the graphics so I can change in yy-chr? Hex editing? How do i do this?

[Mattrizzle]

There are no relevant utilities for the Donkey Kong Country games, so you'll have to resort to hex editing. Lots of pointer calculation is needed, as well as an intermediate knowledge of 65c816 assembly.

[jonesy47]

Yikes. I could do pointer calculation if need be but I have no knowledge of assembly. I want Donkey Kong instead of Kiddy Kong (kinda like your new hack) SOOOOOOO bad...oh well. Good Luck on DKC2!

[jonesy47]

Ok, after pondering this a bit more, what kind of pointer calculation would I need to learn? Do you know of any good tutorials on the subject or a good place to start?
Over the years, I've read many tutorials on romhack.net and have even hacked metal gear so that it actually had metal gear in it (lost the damn copy. MIGHT be on an old xbox tho...) but yeah, I'm not really sure what tree to start barking up? I'm prepared to try pointer calculation and, even if I'm unpracticed in hexediting lately, I'm willing to do that.

As far as ASM goes, really, all I'm interested in is replacing Kiddy with Donkey Kong. Dixie Kong can stay so, I assume (ha ha) that wouldn't require THAT much complicated coding considering they seem to essentially be the same size and have the same move set. Buuuuuut, I'm probably wrong.

So, I guess I'm just asking for a means to learn how to do what you outlined in your original response.
Just kinda really want to do this. << Long time hater of Kiddy Kong, since '96. Can't help how I feels.

[Raccoon Sam]

All Kiddy's palettes are somewhere in the 0x3D3213 - 0x3DC3A3 range. Finding and changing them to match Donkey's palettes pretty easy I guess.
Kiddy's graphics, on the other hand, begin at 0x4C2E7 and end in 0x4F05F. That's only one bank, though, and you'll find Kiddy again at 0x533B5 - 0x5E4A9, 0x613AC - 0x6FEFE, 0x74460 - 0x7FD8A, 0x84549 - 0x8FE75, 0x927DD - 0x94855, 0xE6D83 - 0xE94E9, 0xEA057 - 0xEB819, 0x13541A - 0x13722C, 0x173319 - 0x175ABD, and 0x1C8AAF - 0x1CA6D7. So all in all you have at least eleven individual places where editing needs to be done, not to mention those are only the on-level graphics. I don't know where the map screen graphics or the snowball/sideshow graphics are, and to be honest, I'm not even sure if the ones I listed are 100% accurate or all there is.

But anyway, let's try something so you'll get a better grasp on how cumbersome this is.
Here's the first time Kiddy appears in the ROM, at 0x4C2E7 like I said:


After the first 24 tiles you will see a seemingly garbled tile. That's the tile alignment data.


If you open that offset (0x4C5E7) in a hex editor, you'll see these bytes (I added some color emphasis the slashes):
04 08 08 00 / 18 18 00 00 7E 4D 7E 5D 8C 5D 8A 4D 90 6D 88 45 8D 45 95 6D 81 6D 83 75 85 7D 8F 7B

The first four bytes have something to do with loading of the graphics. I edited them resulting in gradual corruption of the sprite in question. So no idea.
The second four bytes, no idea either. Editing these sometimes makes the background glitch out, sometimes nothing. So no idea either.
The remaining 24 bytes are X-Y coordinate pairs. If you edit those, parts of the sprite in question are moved in space.

I don't know where the information regarding how much space is allocated for each sprite (pointers probably) or the information on how the sprites' parts are read (some of those Kiddy's parts are 16x16, some are 8x8) or animation durations or hitboxes are stored.

And I really don't know how to find them either. If I were to do this project, I'd imagine the easiest way out is to compile as much information as possible regarding the Kiddy's sprite properties, and then program a separate "DK Inserter" that inserts the graphics/hitboxes/whatever from a separate binary to DKC3, automatically calculating all the pointers and whatnot.

I mean, the thing I showed you is just one sprite. At a quick estimate, Kiddy has ~200 unique sprites. Doing those each by hand will probably be too much.

And still, that's just replacing the graphics. You'd still have to find and replace the sounds, some physics values and program the hand-slap routines in assembly... I have no idea how find those either. Well, sounds maybe.

[Mattrizzle]

After the first 24 tiles you will see a seemingly garbled tile. That's the tile alignment data.

The tile alignment data of a sprite actually comes before the sprite's graphics. Simion32 documented the format here.

If I were to do this project, I'd imagine the easiest way out is to compile as much information as possible regarding the Kiddy's sprite properties

These patches might help out. Be sure to read the other files in the zips for instructions and a list of palette locations.

Here are some relevant offsets:
DKC1 v1.0 (U)
3BCC9C-3BF78F Sprite Pointers (4 bytes per sprite; 2,749 sprites)
3B8000-3B9579 Hitbox Pointers (2 bytes per hitbox)


DKC3 (U)
3C8000-3CC3F2 Sprite/Hitbox Pointers (5 bytes per sprite; 3,479 sprites - first 3 bytes: pointer to sprite; last 2 bytes: pointer to hitbox of sprite)

[Raccoon Sam]

Okay, wow, thanks!
jonesy47, please disregard the misinformation in my post. While the offsets were probably somewhat right, you're better off following the info in the link Mattrizzle provided.
With that info and enough determination, you might be able to replace most graphics. But it's still a giant ordeal.