DKC Atlas Forum

I've been trying to disassemble the decompression routine in DKC2, I've heard on the forum RLE was used but I can't found the code that decompress graphics...
If someone has a clue or has found it, that would save me time
Thanks

Actually, it's not only RLE... I've looked into this some, and it seems to use several compression routines at once.

Also, it's not used for just graphics, it's used for most everything in DKC2. MUCH more complicated than DKC's graphics-only compression.

However, I haven't developed any code to decompress DKC2 yet, so don't bother asking. I will be making such code for use in my DKC Resource Editor though, so everyone will be able to extract its data using this tool.

EDIT: Heads-up: An update to the DKC Resource Editor has occurred recently: v0.0.4.1

Yeah I saw your tool, thats a cool soft , but my needs are to do something for DKC2 on my own
Anyway, I've almost finish to port the 65816 assembly decompression routine to C++
It start near BB8DDF where the hearder is parsed then many subroutines are called
I did 12 of them, I don`t know how many there are, still doing the work
- Francis

Ah, but you inspired me to cut off from my usual work on DKCLB and work on porting the routine myself...

Took me a bit to get started (just understanding how it works) and I've got 4 of the 32 (i think there are 32 anyway) subroutines done. I plan on finishing it today.

From what I know, one of these is LZ77 or LZ78 compression. Not sure but I think DKC used something like that as well.

What exactly do you plan on doing? For me it's going to be mainly assembling Level Terrains into big PNGs, and all the same stuff that DKCRE does for DKC. As for editing DKC2.... that will come much later, as my main priorities are to focus on the DKCLB.

EDIT: Got 10 done so far...

Nice
I'm going to do a level editor like Lunar Magic, simple interface with drag-drop of elements
The decompression lib is going to decompress resources to show terrain and sprites on the screen, without saving file, all the work done in memory
DKC Rom -> Decompress then
4BBP GFX -> Bitmap then
Bitmap -> HDC

I've got some questions about the palette format, here some infos I've got from tracing the rom :

DMA[0]: write Mode: 0 0xFD26AE->0x2122 Bytes: 512 (inc) V-Line:217 CGRAM: 00 (0)

2. So that mean, the palette of the splash screen is 512 bytes non-compressed from the rom, thats right ?
1. Is the format : ?bbbbbgg gggrrrrr for each index like this document describe ?
Thanks for the precision
If you need the code I made for the decompression just ask

LokiNova wrote:I'm going to do a level editor like Lunar Magic, simple interface with drag-drop of elements
The decompression lib is going to decompress resources to show terrain and sprites on the screen, without saving file, all the work done in memory

Hmm... do note that you'll probably have to be able to expand the entire ROM to do that (unless you manage to make a re-compressor and like being restrained by the original data size). You'd likely run out of room, unless the ROM is made bigger and its data rearranged.

LokiNova wrote:Is the format : ?bbbbbgg gggrrrrr for each index like this document describe ?

Yes, that is the pallet format.

LokiNova wrote:I've got some questions about the palette format, here some infos I've got from tracing the rom :

DMA[0]: write Mode: 0 0xFD26AE->0x2122 Bytes: 512 (inc) V-Line:217 CGRAM: 00 (0)

2. So that mean, the palette of the splash screen is 512 bytes non-compressed from the rom, thats right ?

Not a clue, I haven't dealt with splash screens yet.

What does your decompressor code use to store the data? I've coded mine so far with a vector<char> to store extracted data in. I have about 20 functions done so far.

Do you know if the tile data for DKC2 in tall levels (like brambles) are any different than DKC's? I assume there has to be some level dimensions because the levels in DKC2 are not always "16 x Length" or "Height x 64" in tile area.

Simion32 wrote:

LokiNova wrote:I'm going to do a level editor like Lunar Magic, simple interface with drag-drop of elements
The decompression lib is going to decompress resources to show terrain and sprites on the screen, without saving file, all the work done in memory

Hmm... do note that you'll probably have to be able to expand the entire ROM to do that (unless you manage to make a re-compressor and like being restrained by the original data size). You'd likely run out of room, unless the ROM is made bigger and its data rearranged.

Yeah thats a problem that I will have to deal with... as for now, I have to render the complete level with background and tile

Simion32 wrote:What does your decompressor code use to store the data? I've coded mine so far with a vector<char> to store extracted data in. I have about 20 functions done so far..

It use an array of unsigned char, declared like that :

Code: Select all

unsigned char dataOut[2000];

Or it can be allocated into the heap with the Windows API if you dont want to overflow the stack :

Code: Select all

unsigned char *dataOut = (unsigned char*) HeapAlloc(GetProcessHeap(), NULL, 2000);

I just did a function that take as parameter,

unsigned decompress(unsigned char *dataOut, unsigned dataOutSize, const unsigned char *dataIn, unsigned dataInSize);

For each subroutine to parse, it is enclosed in a switch/case statement,

Code: Select all

      switch (t)
      {
         case 0x08:
         {
            unsigned char byte = dataIn[indexIn++];
            dataOut[indexOut++] = (byte / 0x10) | ((d % 0x10) << 4);
            d = dataIn[indexIn++];
            dataOut[indexOut++] =  byte % 0x10 | (d / 0x10);
            t = ((d & 0x0F) << 2) + 0x3F;
            break ;
         }
         ...
      }

Simion32 wrote:Do you know if the tile data for DKC2 in tall levels (like brambles) are any different than DKC's? I assume there has to be some level dimensions because the levels in DKC2 are not always "16 x Length" or "Height x 64" in tile area.

I haven't got into that currently, but it should be similar to Super Mario World, there may be some data to define the dimensions of the level, the music, etc. this need to be more investigate
As for now, I'm trying to understand how all it is stored into the memory... I've got the bitplane and I just verify if my knowledge is right with some sample data...

LokiNova wrote:I haven't got into that currently, but it should be similar to Super Mario World, there may be some data to define the dimensions of the level, the music, etc. this need to be more investigate

The 8x8 tile graphics are assembled into 32x32 tiles, and these are then arranged into levels. At least that's how DKC does it, I'm quite sure DKC2 does the same (except of course, most of the data is compressed in DKC2 instead of just the graphics). Also DKC2 probably accesses its level data via RAM memory, not ROM like DKC does.

EDIT on 25th: Hey, I've got the routine done... time to give it a test-run!

Simion32 wrote:

LokiNova wrote:I haven't got into that currently, but it should be similar to Super Mario World, there may be some data to define the dimensions of the level, the music, etc. this need to be more investigate

The 8x8 tile graphics are assembled into 32x32 tiles, and these are then arranged into levels. At least that's how DKC does it, I'm quite sure DKC2 does the same (except of course, most of the data is compressed in DKC2 instead of just the graphics). Also DKC2 probably accesses its level data via RAM memory, not ROM like DKC does.

EDIT on 25th: Hey, I've got the routine done... time to give it a test-run!

Nice job! I've finish a tile parser that take a TilePalette, TileMap, an array of data and a HDC to draw as parameter just to understand the file format

Flip bit support is missing, will do it soon
Keep the good work
- Francis