Mmm, delicious donuts.
That’s a custom donut car, in game and working just fine.
I also found the real car settings, not the fake ones on the car select screen, so now you can make a car that accelerates so fast it takes off and flies right out of the track… err, good times…
Fixed up support for 8-bit pngs, as not many programs let you write 4-bit palettes. GIMP can, but it doesn’t make it obvious. Custom textures are now easy as.
Well it took a little longer than I might have expected, but here’s a custom-made car model inserted into the game, and running on a real N64. Such quality.
Thought I’d take a break from the tracks and look at the cars again, which are a lot less complex. I’m now at the point where I can export a car with correct textures to an .obj file. Doing the reverse and putting a modified car back into the game is now just a matter of implementing it (unless there’s something I don’t know I don’t know… which is quite possible).
I’ll make a first release once importing a car is possible.
Sometimes opening a file in a hex editor and staring at it is enough to begin working out patterns and possible meaning, other times I can see structure but the meaning is totally beyond comprehension.
Overlaying this data onto already understood data in a visual form can sometimes make its meaning clear. For example, each track collision section has an array of “Triangle” structs which describe the collision mesh. Each Triangle is comprised of 3 indices into the vertex array, and then 4 Bytes of unknown data. The last of these four Bytes is always a low value (<6), often the same value for most of the Triangles in a section, but I have no idea what-so-ever as to its meaning.
So as an experiment, I render the collision mesh and use this value to select a colour for each Triangle from an array of pre-defined colours:
Black Forest with the ground type colour coded
Aha! These different colours match exactly with the different parts of the track, this value must be the collision’s type, which could be road, dirt, grass etc. I still don’t know where these types are defined but this is a good start.
Moving on, each collision vertex is defined as 3 floats for position, 4 Bytes for lighting color (R8G8B8A8), and two shorts whose purpose is unknown. The first short is sometimes 0xFFFF, and otherwise has similar values to the second short which seems to start at 0 for the first vertex and gradually increments by 1 for later vertices.
If I colour the mesh differently depending on whether or not this vertex has a 0xFFFF value, this is the result:
Sydney with the unknown vertex properties == 0xFFFF highlighted
The collision sections with a 0xFFFF value are the sections where the different variations of the track diverge from each other.
If I instead alter the meshes colour depending on the value of the second short I get this:
Kyoto with the collision polygons coloured by the vertex unknown2 value
I’m still not sure what this data is, but now I can see the overall pattern. Perhaps the increasing values are how the game determines if you are going the wrong way around the track, or each cars placing. Doing this colouring using the first shorts values shows that excepting the 0xFFFF values, these are forming a similar – but less segmented – pattern in reverse.
Kyoto with the collision polygons coloured by the vertex unknown1 value
So I spent the past months going down a rabbit hole. When the game loads a track it doesn’t just inflate all the parts and dump them into RAM, as it does, it modifies some of them, and even calculates some things and inserts them between the parts.
“Well”, I thought, “if the game does it, then I must too!” And that’s how I spent the past few months decompiling the track loading functions by hand. Only to realise, as I got deeper and deeper, that to do the job properly I would more or less have to write an N64 cpu emulator to emulate the whole game.
At that point I gave up. That point was yesterday.
When I thought about it, the data I want to replace is what’s in the ROM, not the RAM, so really I don’t care what the game does with the data once it’s in the RAM, so long as the data I put into the ROM is compatible.
Moving on then, I’ve now parsed the basics of the track models, bringing me back to where I was last time I tried this years ago. Onwards!
One of the Hawaii track variations
Nice eh
The 3 LoD models for the 1999 Stallion SR A
Happily the data I thought was normals turned out to be normals, which you can see rendered here. They’re most obviously used to show reflections on the cars.
Each car has the hi-def model made of 25 individual parts, and three LoD models, in addition to 4 wheels and a few other entries with <3 vertices. Not sure if those are used for something or just dummy data.
I haven’t really looked at the wheel data yet, at the moment they’re displaying with the texture only covering half of the wheel, I guess the bottom half is meant to be a mirror of the top but I have to find out what causes this (or is it hard-coded? wheel textures have their own table).
Still no idea how a given model/texture is assigned a palette, and I feel like there might be a problem with the palettes I’m inserting, for one model I’ve noticed the palette doesn’t seem to match the in-game one anymore.
LoD models for cars 0, 6 and 33
So it turns out the game does use an unaltered version of Zlib. My bad data was a result of assumptions about how the texture data is inserted into the car’s data blob.
At first glance it appears the texture data is just dumped straight into the gap that exists for it, but this is not the case. What I thought was a second table of texture descriptor pointers is actually a list of all the individual textures the car uses. After inflating the car’s data this table is walked through and used to transfer the needed textures into their positions within the blob, so in some cases not all the inflated data ends up transferred into the blob. As simple as that!
I was able to work this out pretty quickly using MAME, not only does it actually run WDC, the graphics are correct, and it has an excellent debugger with every feature I could dream of a N64 emulator having. I can’t believe I didn’t find out about this sooner. The only down-side is it runs very slowly, but frankly I couldn’t care less!
The reason I’m only showing LoD models and not the most detailed ones, is that the detailed models are split up into separate pieces (grill, bonnet left, bonnet right, etc) and I haven’t added the ability to draw them all at once yet. Soon, soon.
Your car when you load a texture but forgot to set half the UVs
Well on the path to getting car texture support done, but there have been a few trials along the way.
Firstly the game uses a format I haven’t run into before:
The indices are stored in interleaved order (all even rows, then all odd rows) and the odd rows are word swapped (xxxxxxxx yyyyyyyy is stored as yyyyyyyy xxxxxxxx), very strange.
Second problem I have yet to resolve, I haven’t found how the game keeps track of the texture sizes. This may be hard-coded for car data, as they seem to use 80×38 textures for everything except the wheels, and the wheels have a separate block of texture pointers to the rest of the car parts. Hopefully looking at the track data which has a variety of texture sizes will shed more light on this.
Finally, and perhaps most frustrating, the game appears to use a slightly modified version of zlib 1.0.4 (there’s a string referring to this version in the ROM) to inflate the compressed data. You can use vanilla zlib to decompress and compress data and more often than not you’ll get the same output as the game, buuut not 100% of the time. Hoping that it was perhaps just some breaking change in zlib (which is currently v2.x) I grabbed the source for 1.0.4 and tried that, but it gives the exact same output. So now I have to reverse the game’s inflate routine to be able to extract correct data. Reversing an ASM routine is kinda fun, but can be painful as well.
Such is life.
The most detailed of the three LoD models