DK64 - Kiosk Restoration Project

[SubDrag]

Originally Posted by runehero123

GEDecompressor doesn't compress some of the kiosk rom's files correctly. I tested it by compressing one of the files and then decompressing it to see if it was the same. The original file had a couple extra bytes at the end. Hmmm....

It compresses fine, just using different tools so file sizes differ.

[runehero123]

Originally Posted by CoolisCool

In both of those files, the textures are stored elsewhere; collision data is near the end. I'll work on reverse engineering the header tomorrow.

Ah, I had a feeling they were. In that case, it may take longer to port the BG objects. However, there's the potential for beta textures .

And good luck reverse engineering the header. I know there are differences between the kiosk and final version's headers.

Originally Posted by Cooliscool

I'll also end up adding DK64 support to BG, which shouldn't take long considering that aside from game subjectivities, it uses the same ucode as Tooie.

Sounds good. Maybe we'll find some new objects in ROM that aren't in the map object mod, or image mod codes.

Originally Posted by SubDrag

It compresses fine, just using different tools so file sizes differ.

DK64 won't load the model because of the size difference. I tried inserting extra bytes at the end to make up for the difference, but that doesn't seem to work either. Also, this problem doesn't occur with every model (Funky's shop loads fine.).

[cooliscool]

Preliminary details, will update as I continue.

DK64 Model Header:

This data is for the final version, though the kiosk versions header is the same; just subtract 8 bytes from each offset. 

Layout is "offset (datatype) = description and details"

s16 = signed 16 bit int (-32768 - 32767)
u8 = unsigned 8 bit int (byte, 0-255)

0x38-0x3B (32-bit UInt) = pointer to start of master vertex lookup table (16 bytes per entry - [xxxx - s16][yyyy - s16][zzzz - s16][0000][uuuu - s16][vvvv - s16][rr - u8][gg - u8][bb - u8][aa - u8]

0x40-0x43 (32-bit UInt) = pointer to end of master vertex lookup table 

((endptr-startptr) / 16) = vertex count)

0xE6-0xE7 (16-bit UInt) = number of display list commands (*8 = dlist buffer size in bytes) 

0x148 (64-bit UInt per command) = start of master display list (first 8b = commandcode, next 24b = loword, next 32b = hiword)

struct DK64Header
{
int VertStart;
int VertEnd;
int VertCount;
int DLStart;
int DLCommandCount;
}

struct Vertex
{
short x;
short y;
short z;
short flags;
short u;
short v;
byte r;
byte g;
byte b;
byte a;
}

struct DisplayList
{
unsigned long Command;
byte CommandCode;
unsigned int loWord;
unsigned int hiWord;
}

long[4] ShiftTable = {0xFFFFFFFF, 0xFFFF, 0xFF, 1}; // macro for appending bytes 

void ReadHeader(byte[] FileByteBuffer, struct DK64Header Header, bool kioskMode)
{ 
    int inc = 0; // for kiosk/final compatibility
    if(kioskMode) {inc=8;} // could be more elegant

    for(int i=0;i<4;i++) 
    {
         Header.VertStart += FileByteBuffer[(0x38-inc)+i] * ShiftTable[i];
         Header.VertEnd += FileByteBuffer[(0x40-inc)+i] * ShiftTable[i];
    }

    Header.VertCount = ((Header.VertEnd - Header.VertStart) / 16);
    Header.DLStart = 0x148-inc; //constant

    for(int i=0;i<2;i++)
    {
          Header.DLCommandCount += FileByteBuffer[(0xE6-inc)+i] * ShiftTable[i+3];
    }
         
}

[Navillus]

I can't understand hardly any of this, but I'm eager to play the final version. I'll be keeping watch on this thread for more exciting updates.

[CoolJosh3k]

Those without any programming know-how and know-what would have that C code go right over their heads. Not to mention ASM.

[SubDrag]

It'd really be better for me to redo compression using gzip anyways, the way it's done is rather...pardon the pun, funky.

[cooliscool]

Originally Posted by CoolJosh3k

Those without any programming know-how and know-what would have that C code go right over their heads. Not to mention ASM.

Indeed. It's intended for RH, myself, and the others programmers here. It'll end up helping quite a lot with this project if put into good use; and it's far from complete.

[CoolJosh3k]

Yep. I hope this thing goes well. This thread is one to watch, hence my recent activity.

[tony111ster]

if this does go well (kudos to all the programmers who know what they are doing and talking about) Then we shall get the life balloon thing, as well as old sprites, original levels and challenges, so excited for the revival

[runehero123]

Originally Posted by Cooliscool

Indeed. It's intended for RH, myself, and the others programmers here. It'll end up helping quite a lot with this project if put into good use; and it's far from complete.

Thanks for the header information! I was also wondering. How does the collision data work? Is it just a transparent model constructed of a display list?

Originally Posted by Subdrag

It'd really be better for me to redo compression using gzip anyways, the way it's done is rather...pardon the pun, funky.

Sounds good. That shouldn't take too long, would it?

[cooliscool]

Collision is indeed a "transparent" set of triangles, but it's not set up through a display list since it'll never be seen - no use in sending it to the RDP. Normals are specified so that the equation, which essentially judges the player's distance from the triangle, doesn't need to compute much. I'm still working out exactly how it's setup as far as DK64 is concerned; and I may need some levels' setup files to make a proper determination. Do you have any you're aware of?

[SubDrag]

Hmm looks like it's already there?

Do you have: (needs gzip exe)

bool GECompression::CompressGZipFile(CString inputFile, CString outputFile, bool byteFlipCompressed)
{
CString gzipFileName = (mainFolder + "gzip.exe");
char tempFileExistName[1000];
strcpy(tempFileExistName, (mainFolder + "gzip.exe"));

[runehero123]

Originally Posted by Cooliscool

Collision is indeed a "transparent" set of triangles, but it's not set up through a display list since it'll never be seen - no use in sending it to the RDP. Normals are specified so that the equation, which essentially judges the player's distance from the triangle, doesn't need to compute much.

Ah, I should've known. Thanks though, I'm working on a game engine for the N64 so information like this will be useful when it's time to implement collision detection.

Originally Posted by Cooliscool

I'm still working out exactly how it's setup as far as DK64 is concerned; and I may need some levels' setup files to make a proper determination. Do you have any you're aware of?

I only have the setup files for object(doesn't include actors) placement data. That's probably not what you need though. The data you're looking for is probably located in the global setup file (not sure where it is in DK64) which contains data like what song or which Background object a level should load. I'm guessing it would be located in the same file as menu texts which happens to be global data.

Originally Posted by SubDrag

Hmm looks like it's already there?

Do you have: (needs gzip exe)

bool GECompression::CompressGZipFile(CString inputFile, CString outputFile, bool byteFlipCompressed)
{
CString gzipFileName = (mainFolder + "gzip.exe");
char tempFileExistName[1000];
strcpy(tempFileExistName, (mainFolder + "gzip.exe"));

Yeah, I've been using gzip to compress these. I'll have to figure something out about the bytes being trucated at the end of the file.

[SubDrag]

It's not truncated...it's compressed better. You need to redo the table of all files if DK has that (and shift contents), or where it says compressed size, or else it will possibly crash like you see.

[runehero123]

Originally Posted by SubDrag

It's not truncated...it's compressed better. You need to redo the table of all files if DK has that (and shift contents), or where it says compressed size, or else it will possibly crash like you see.

Yeah, I'm pretty sure I did all that correctly.

There's a table for the decompressed size of BG data, and compressed size is calculated in the pointer table.