Mario Kart 64 Hacking General Discussion

[queueRAM]

(09-05-2016, 05:33 AM)mib_f8sm9c Wrote: So this brings us to the A1 buffer. For clarity, the A1 buffer is NOT an output, it's a processing aide to determine pixels that are in areas with lots of changing colors. Every time that a pixel's color changes from a previous pixel, in the A1 buffer it adds 1 to the pixel to the right, the pixel that's 2 pixels right, the pixel down, the pixel down & left, the pixel down & right, and the pixel down twice. 6 in total. Effectively this map shows you areas that are heavy in changing colors, and places that are effectively the same color.

​

Thanks for confirming the A1 buffer is just used temporarily during decoding. I couldn't find any references to it outside of the TKMK00 decoder, so I had my suspicions.

(09-05-2016, 05:33 AM)mib_f8sm9c Wrote: ​
That being said, making a compressor sounds pretty complex. Deciding how to make the Hoffman tree from the start sounds like an interesting challenge, and it'd probably be hard to make a compressor that'd out-perform the one made for this. I'm having fun though.

​

I've been able to read over your description and the code you posted and I think I was able to understand all of it. Thanks for posting all of that, it really helped. However, I agree that writing a compressor will be difficult. I think first pass will just trying to store it as uncompressed as possible (similar to the fake MIO0 headers concept), so always using a new color, always new RGBA, but I haven't quite thought out how to handle the effect this has on the color change map and channel readers. I'll give this some more thought.

(09-05-2016, 05:33 AM)mib_f8sm9c Wrote: ​
EDIT: Okay, I figured out how the new pixel color is calculated from the predicted values & the output from the Channel Commands. I think I have it all figured out. I'll write up my own non-assembly-style decompressor, comment the heck out of it & probably upload it here, and then maybe take a hack at a compressor. But not today. I need a break, I lost my whole weekend to TKMK.

EDIT EDIT: Working C# code for a decoder:
http://pastebin.com/Zyx0xCdz

​

Awesome! I ran some tests comparing the md5sums of all 63 TKMK00 images produced from your C# version and my C version, and they all matched! Looks like you got it all figured out. And I hear you about needing a break. I thought a good weekend was all I needed to decode TKMK00 and it ended up taking me nearly a week to cobble together that C code.

I've been going through the structures used to generate the menus and trying to figure out how to update images inside of it. Like everything else, it is quite convoluted. I'll update this post with a complete doc once I have more sorted out. Here is what I have now: http://sprunge.us/RFiN

Brief summary: the menus use both TKMK00 and MIO0 compressed assets (characters and map previews use MIO0). This table uses both and passes them to 800996BC() with either a segmented address from the table or a virtual address. Based on which type of data, it calls one of two specialized DMA functions to compute ROM offsets from segmented addresses and then calls the appropriate mio0decode/tkmk00decode function. Related submenus are then also loaded based on data in the menu structure.

Also, out of curiosity, I took the time to try and decode the two Japanese TKMK00 menu options. Looks like at one time they were thinking of having race modes without items.

	アイテムなし	without item
	アイテムあり	with item

Thanks to abitalive and his friend for confirming the translation.

[MRKane]

I know this doesn't help anything, but having done a fair few ASM hacks for Mario Kart I can contest that the code is a horrible mess, but would like to say that I'm thrilled, excited, and crazy impressed by what you're doing!!

[queueRAM]

I put together a few assembly examples on how to change and relocate some of the texture, course, and music data in the ROM. Hopefully this helps make sense of the data structures. This supersedes my earlier relocate course data example.  Attached archive includes all the tools and assembly used to make them.

TKMK00 textures (swapped title and menu textures):


Character selection textures:

(12-05-2016, 12:32 AM)MRKane Wrote: ​
I know this doesn't help anything, but having done a fair few ASM hacks for Mario Kart I can contest that the code is a horrible mess, but would like to say that I'm thrilled, excited, and crazy impressed by what you're doing!!

​

The code is indeed difficult to make sense of, but don't sell yourself short! If you can read through the code, you can certainly be of help.

[mib_f8sm9c]

Nice work! I'm also finally done with the TKMK00 encoder, thank goodness. I've put both the encoding/decoding process up on Github:
https://github.com/mib-f8sm9c/MiscellaneousHacks/blob/master/BetaTools/MarioKartTestingTool/TKMK00Encoder.cs

Here's an example of what the TKMK00 format will let you change in-game:


I'll be back to the Mario Kart development soon enough, I might take a couple of days to get my irl life sorted out though.

Also a note, if people do want to help, I'll be writing this tool in C# and it'll be updated regularly on Github. So you'll have lots of opportunity to help out if you want!

[Drew Weatherton]

Those are both very exciting developments! Do you also have the ability to replace textures encoded with MIO0? I've got my MagiKoopa model and I could create appropriate size images if you can provide specifications.



In fact, if you want to start messing with something, here are some 360 degree renders I had made. I can tweak angle, height, resolution. Whatever.

​https://drive.google.com/open?id=0B6R-_aY9WtmIWWxVdlQ3ckZ0QVU

[queueRAM]

(16-05-2016, 07:56 PM)Drew Weatherton Wrote: Do you also have the ability to replace textures encoded with MIO0?

​

Yes, the character selection screen uses MIO0 compressed RGBA16 textures, so my silly koopa troopa hack depicted in my previous post demonstrates updating RGBA16 textures and MIO0 compressing them and updating the texture tables to point to the relocated MIO0 data.  You can take a look at the included Makefile and assembly file for how I moved data around and update texture pointers. Unfortunately, my MIO0 compressing algorithm isn't optimal as Nintendo's MIO0 files sizes are all less than mine. This is important because it basically forces one to relocate at least some of the textures instead of merely overwriting the old ones.

(16-05-2016, 07:56 PM)Drew Weatherton Wrote: ​
I've got my MagiKoopa model and I could create appropriate size images if you can provide specifications.

​

The kart textures are also MIO0 compressed, but the decompressed data are encoded as CI (16?), not RGBA16, so they use a palette to store the texture. I've never used this format before, but it seems like a fairly straightforward table lookup. n64rawgfx (the command line backend for N64rip) appears to support CI modes (something like "-f CI --pdepth 16 --paddress "), but I haven't tried to use this yet. shygoo's Kart Viewer shows the decoding of the existing kart textures and it looks like there are ~0x140 different perspectives of each kart (although all from left side, so I suspect they just horizontal mirror to view right). Probably the trickiest part of all of that will be encoding all of a character's kart textures with the same palette and the kart's wheels with a separate palette. The wheels are split into a separate palette so palette switching can be abused to make the wheels appear as though they are moving. Kart textures are 64x64, by the way.



When I have some free time, I'll run some tests on the CI format and see if I can replace one of the kart textures. I might be able to put together a framework for changing the kart textures, but I'd leave the actual replacement up to you.

[Drew Weatherton]

queueRAM. Thanks for the detailed response. I'll work on tweaking the camera location to replicate those used in the game. Is it possible to get an export of all images named by memory address? shygoo's Kart Viewer shows them, but it seems to create an animated gif or something, I'm not sure how to save them separately. Also, I see what you mean with the color palette stored separately. abitalive and I found that the color palette information is stored here:

// ROM RAM Kart Coloration Palette
dd $0F12D430 // $000E2F40 $800E2340 - Mario (4 Bytes) ($0F12D430)
dd $0F09ABFC // $000E2F44 $800E2344 - Luigi (4 Bytes) ($0F09ABFC)
dd $0F1C4958 // $000E2F48 $800E2348 - Yoshi (4 Bytes) ($0F1C4958)
dd $0F386858 // $000E2F4C $800E234C - Toad (4 Bytes) ($0F386858)
dd $0F438874 // $000E2F50 $800E2350 - D.K. (4 Bytes) ($0F438874)
dd $0F2F5DEC // $000E2F54 $800E2354 - Wario (4 Bytes) ($0F2F5DEC)
dd $0F258AC8 // $000E2F58 $800E2358 - Peach (4 Bytes) ($0F258AC8)
dd $0F4F8C88 // $000E2F5C $800E235C - Bowser (4 Bytes) ($0F4F8C88)

[queueRAM]

(17-05-2016, 03:12 PM)Drew Weatherton Wrote: Is it possible to get an export of all images named by memory address? shygoo's Kart Viewer shows them, but it seems to create an animated gif or something

​

The Kart Viewer is just cycling through each texture and drawing it to the screen. There's not really a convenient way to dump all the textures from javascript, so i ported shygoo's code to C. I've attached an executable that can be run to dump all the kart textures from the ROM to PNG. It defaults the wheel palette to 0x1BBEEC, but can be changed with command line flags. You can run it from the command prompt or drag-and-drop the ROM on top of the mk64karts.exe. Default output directory is "karts" in the directory where the ROM is located.

Code:

​Usage: mk64karts [-d PNG_DIR] [-w WHEEL_PAL] MK64_ROM

mk64karts v0.1: MK64 kart texture dumper

Optional arguments:
-d PNG_DIR    output directory for PNG textures (default: "karts")
-w WHEEL_PAL  wheel palette offset in ROM (default: 0x1BBEEC)
-v            verbose progress output

File arguments:
MK64_ROM      input MK64 ROM file

Source code is available: https://github.com/queueRAM/sm64tools/blob/master/tools/mk64karts.c
Note: I have no intention to support this tool. n64split will manage this in the future

[Drew Weatherton]

Thank you very much. This is super helpful

[mib_f8sm9c]

I'm cleaning up my Cereal64 code now so I can start the Mario Kart 64 tool this weekend. I'll push it to Github by Monday, despite whatever state it's at, but it should have the level viewer and some texture swapping code in there for now. I'll see if I can get a Kart Editor in as well.

EDIT: My weekend was way busier than I expected, I'm moving this deadline to sometime tonight [Monday 23rd].