DKC Atlas Forum

[Gabriel]

Here is a list of the various things that I found while working on my rom editor.

I'll start with level tilemaps:
Most levels (not water levels or slipslide ride), are stored in colums. They are 16 32x32 tiles high and vary in length. Each tile takes up 2 bytes of rom.Byte 1 says which tile number to use. The low bit of byte 2 is also part of the tile number (if there are more than 255 tiles in a tileset). The high bit of byte 2 tells weather the tile is horozontally or vertically fliped. EX) 00 01 is tile 1, 40 01 is tile 1 horozontally flipped, 80 01 is tile 1 tile 1 vertically flipped, C0 01 it tile 1 horizontally and vertically flipped. If a tile is horozontally flipped, the tile's collision is also fliped. However, if a tile is vertically flipped, its collision is NOT flipped.

Now object maps:
A typical object is 8 bytes long, it looks like this FU 00 XX XX YY YY OB OB. The FU is the object function byte. It is always betyeen 0 and F. Most objects use 01 for this byte. However "special" objects, such as the day-night trigger in jungle hijinxs use 08 for this. Byte 2 is always zero. Bytes 3 and 4 are the X-coordinate of the object. Bytes 5 and 6 are the Y-coordinate. Bytes 7 and 8 are the object short. They probably point to some ASM code to tell the game what to do. Also, objects' position is stored relative to the global tileset. As in, in object map terms, the X-coordinate of the start of jungle hijinxs is 0, but the X-coordinate of the beginning of ropey rampage is about 6000. Another thing, objects must appear in order, as in the X-co of the first object must be less than the X-co of the second object. Object 2 will not appear until object 1 has appeared.

Banana time:
Banana maps have a very strange data structure. Each banana formation in a level is 4 bytes long. They look like this: BA YY XX XX. BA is the banana formation. (images of them can be found on Giangurgolo's page). It is always even. Byte 2 is the Y-co of the formation. It MUST be a multiple of 8, (there are very few times when this is not the case). If not, a very strange banana formation will appear or the game will crash. The 2 byte X-co is very wierd. It is byte 4, times 64 plus byte 3, divided by 4. Byte 3 must be a multiple of $32. Bananas are stored relative to the level, as in the beginning of every level is 0 in banana map terms. Also, banana formations must appear in order. The X-co of banana 1 must be less than the X-co of banana 2.

This is most of the random things I have observed while hacking DKC.

[Simion32]

Thanks for posting about the banana format and the object-offset quirks (how it's based on the start of the tileset), that information will come in handy.

Contrary to what I told you before, Gabriel, the SNES graphics format isn't as simple as I told it to be, so I'll post about the tile graphics and explain the format in full here...

Let's take one 8x8 graphical tile, for example. First and foremost, an 8x8 tile is always 32 bytes.

In this demonstration...
-The first digit of each byte represents the pixel-row number (0 is top, 7 is the bottom row).
-The second digit is each bit's worth in that byte
-Each DWORD is seperated with tabbing, and the bytes on the second row come right after the first row.

01 02 11 1221 22 31 3241 42 51 5261 62 71 72
04 08 14 1824 28 34 3844 48 54 5864 68 74 78

So you would take bytes 01, 02, 04, 08, and stack them together like this (quoting what I said earlier):

01: 10001010 (each bit is worth 1 if bit is enabled, 0 if not)
02: 00010101 (each bit is worth 2 if bit is enabled, 0 if not)
04: 11010111 (each bit is worth 4 if bit is enabled, 0 if not)
08: 10001010 (each bit is worth 8 if bit is enabled, 0 if not)

Add it up vertically to get this: D40696D6 ...each of those digits in the result represents a color in the palette the tile uses; which are the pixels. Repeat that 8 times (once for each row of pixels) and you'll have a full 8x8 tile.

EDIT: About water levels, they are sequenced in rows instead of columns, and all of the ones in DKC are 64 tiles wide (128 bytes). However, the wide levels in DKC2 are not that simple, they seem to have variable width. For example, Bramble Scramble in DKC2 is MUCH wider than Slipslide Ride in DKC.

[Raccoon Sam]

However, the wide levels in DKC2 are not that simple, they seem to have variable width. For example, Bramble Scramble in DKC2 is MUCH wider than Slipslide Ride in DKC.

So there's been actually some DKC2 data findings? Have you got a document up or is this just assumption/early hacking?

[Simion32]

Really just an assumption based on how the levels look in-game.

EDIT: Screech's Sprint is definitely a little wider, as seen HERE (ripped by Stone).

I have, however, found where some data (I think it was tileset data, not entirely sure)is stored in RAM during de-compression. Haven't been able to simulate it yet, though. I also have some random hacking notes lying around but I won't bother to dig them up until I've got a fair bit of DKC done.

[Simion32]

Spoiler!

Banana Map Format [Revision]:

bbbbbbbbyyyyyybbxxxxxxxxxxxxxxxx
b - Banana Group Identifier
x - Placement X co-ordinate Low Bits
x - Placement X co-ordinate High Bits
y - Placement Y co-ordinate

I've just now been investigating a few missing banana formations in DKCRE and DELTA and finally figured out what went awry during development.
The reason the Y-coordinate seems to have an effect on the banana formation is because the lower two bits are part of the banana group identifier. If the group identifier is set to an incorrect value, it can crash the game or cause a "trash" banana formation to appear.
Here's how to get valid coordinate data from the banana maps:

First flip the words around, to comply with the SNES's Little-Endian formatting:
yyyyyybbbbbbbbbbxxxxxxxxxxxxxxxx

Take xxxxxxxxxxxxxxxx and shift it 2 bits to the right:
The final result is 00xxxxxxxxxxxxxx which is the X-coordinate of the banana group.

Next, take yyyyyybb and shift left by 1:
You get 0000000yyyyyybb0; logical AND this with 0xFFF8:
The final result is 0000000yyyyyy000 which is the Y-coordinate of the banana group.

Lastly, take yyyyyybbbbbbbbbb; logical AND this with 0x03FF:
The final result is 000000bbbbbbbbbb which is the banana group number.

Inside the spoiler is incorrect/outdated information, please see below:

[Simion32]

Banana Map Format [Revision 2]:

bbbbbbbbyyyyyybbxxxxxxyyxxxxxxxx
b - Banana Group Identifier
x - Placement X co-ordinate Low Bits
x - Placement X co-ordinate High Bits
y - Placement Y co-ordinate Low Bits
y - Placement Y co-ordinate High Bits (only nonzero in vertical levels)

I'm deep into development of the banana editing for DKCRE v0060, and I have uncovered something that should have been rather obvious:

The data is a little-endian DWORD!! When looking at the data, I realized that swapping the bytes not only results in a value which can be Radix sorted; but later found that the bits 0 and 1 of the last byte were actually reserved for Y coordinates, not unused shifted-out data!

Here's how to really get valid coordinate data from the banana maps:

First flip the entire DWORD around:
xxxxxxxxxxxxxxyyyyyyyybbbbbbbbbb

Take bbbbbbbbbb as the banana group number.

Next, take yyyyyyyy (shift it right by 9). This is the Y-coordinate of the banana group.

Lastly, take xxxxxxxxxxxxxx (shift it right by 18). This is the X-coordinate of the banana group.

[Simion32]

Data on the storage space saved by Rare's compression algorithm in DKC1:

=329,408 uncompressed bytes
-278,880 compressed bytes
-----------------------------
50,528 savings: $C560 (About 77% of Two $8000 Banks)

+ 33,952 gangplank galleon (is stored uncompressed)