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