Monthly Archives: September 2016

The power of visualization

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

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

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

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

Kyoto with the collision polygons coloured by the vertex unknown1 value

Dreamin’

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

One of the Hawaii track variations