This is a really lofty goal, but I think in my spare time I’m going to have a try at 100% accurately re-creating the Goldeneye engine in C, based on disassemblies and traces of the actual game.
Well, that’s the end goal, anyway. For now I’d be satisfied with tracing out the game’s boot process to figure out why, exactly, it fails to boot in MESS currently.
Either way, my current work is here. That’s after around 4-5 hours’ worth of work.
On a weekend with nothing better to do thanks to a deathly head cold, I decided to bolt USF support onto MESS.
So far things seem semi-promising. It’s too slow to be listened to in realtime, but that can probably be fixed with an RSP recompiler. Some games work, some games don’t work, some games work but in strange manners.
Here’s a quick rundown on the USF sets I’ve tried so far, and their relative working or unworking status:
I suppose the next step is to either figure out why some games are playing nothing, or why some games are just running off into the weeds, resulting in MESS fatalerroring!
I’ve decided to take a short break from working on renderer issues, insofar as pretty much every single game that doesn’t run into some sort of bug lurking in machine/n64.c or some sort of MIPS CPU bug has largely correct graphics. The few games that do run up to a machine/n64.c-related bug or MIPS CPU bug also have largely correct graphics. Barring a few exceptional cases, these games would be playable if not for the aforementioned bugs and/or performance.
Since I am not quite familiar enough with the N64’s non-graphical functions to be comfortable bug-hunting in those realms, for now I’m going to concentrate on performance.
Using MAME’s built-in profiler to determine CPU load distributions across the main CPU, RSP, and everything else (mainly the RDP), I can break the games down into four categories:
In order to more accurately nail down the performance of 3D games, I’ve run a profile on three games: Castlevania, Tom & Jerry: Fists of Furry, and Super Mario 64. Unsurprisingly, due to the immensely small number of different microcodes that were ever used on the N64, the code profiles look largely the same. The percentages listed are the percentage of execution time spent in each function, not including children.
As I see it, the first priority is to convert the RSP core over to use MAME’s DRC system. Unfortunately, I’m not quite sure what sort of performance increase will be seen by DRC-ifying the RSP. The VMAC* and VMUD* opcodes have a rather large amount of code associated with them, and not only that, they loop 8 times across 8 elements. This was probably accomplished in parallel on the real RSP.
Another piece of low-hanging fruit is the fact that around 10% of the execution time is taken up by memory accessors thanks to the RSP’s less-than-optimal IMEM and DMEM implementation. The RSP has to hit the memory system for every single read and write that it does. However, in reality IMEM and DMEM are accessed far, far less often by the main CPU than they are by the RSP itself. It therefore makes better performance sense to have two 4kbyte arrays central to the RSP core itself, which it will access directly rather than going through MAME’s core memory accessors. The main CPU will be able to access these memory spaces by querying the RSP core, and any RSP DMA accesses can be done by simply grabbing a pointer into the RSP’s IMEM or DMEM arrays, just like it works now.
Lastly, the plan is to wire the RDP emulation up to MAME’s “work unit” system, which will allow it to distribute drawing commands across multiple CPU cores when available. Unfortunately, the RDP being as slow as it is, it will likely not have too terribly much of a performance impact on my laptop, but it might improve in the situation of a quad-core CPU.
Anyway, that’s the main plan. Here’s hoping I can stick to it.
Continuing this weekend’s N64 extravaganza, some more poking around has fixed a long-standing issue with my new coverage implementation, which is that the texture coordinates and gouraud steps were being mangled by up to +/- 1 pixel delta. This may not seem like a lot, but keep in mind that the S (aka U) texture coordinate can change by anywhere from 8 to 32 texels when traversing across a triangle by only one pixel vertically.
And now, the pretty pictures:
Before:
After:
There’s still some work to be done on rounding the last pixel in a horizontal span, which is causing the remaining issues that are visible in the Zelda screenshots, but still, things are looking considerably better.
I finally decided to figure out why the scene geometry in The Legend of Zelda: Ocarina of Time is so screwed up. As it turns out, RSP DMA transfers should have their length rounded up to the next 8 bytes, not the next 4.
Since it’s kind of hard to get the dramatic change across with still shots, I broke out the -aviwrite parameter and uploaded a couple of videos to YouTube.
A Play-N-Trade recently opened up in a local mall, and I have to admit that it’s been an absolute godsend as far as N64 games are concerned; they have more unpopular games than I could have hoped for.
My ultimate goal is to amass a complete collection of every Nintendo 64 cartridge released in North America, and I realize it’s going to be tough going, but I think Play-N-Trade is definitely going to help me out in this regard.
Today I collected up all of the unused game consoles and games that I had laying around my apartment that I knew I’d never get around to playing or would never play again, and took them over to the Play-N-Trade. $303 in in-store credit later, I picked up the following N64 games for only $135 out of that credit pool:
A Bug’s Life
Chopper Attack
Destruction Derby 64
Gauntlet Legends
Gex 64: Enter the Gecko
Gex 3: Deep Cover Gecko
Glover
The Legend of Zelda: Ocarina of Time
The Legend of Zelda: Majora’s Mask
Mario Golf
Mario Kart 64
Monster Truck Madness 64
Pokemon Snap
Re-Volt
Ridge Racer 64
Roadsters
Rugrats Scavenger Hunt
Starfox 64
Super Bowling
Tom & Jerry in: Fists of Furry
Tonic Trouble
WCW vs. NWO: World Tour
WWF: No Mercy
Ultimately, a pretty good haul!
PIN64 proves its usefulness once again!
I’ve always had some slight suspicions that 1-Cycle mode uses the Color Combiner setup for Cycle 1 rather than Cycle 0, mostly because I’ve observed some games setting different parameters for Cycle 1 versus Cycle 0, even when in 1-Cycle mode.
Sure enough, I finally found one game that proves my theory: F-1 Pole Position 64. Here’s what its menus originally looked like:
Aaaaand after:
As it turns out, there was a rather significant bug in the way MESS was loading textures using the Load Block command when a line-swap delta was specified. I’m actually surprised it worked at all. Now the secondary texture loaded into the CC_TEX1 input is loaded properly.
Before:
After:
A bunch of miscellaneous fixes today:
After making the decision to remove my original alpha-rejection code as it was causing more bugs than it was fixing, I began the arduous process of tracking down the multitude of ways in which the Nintendo 64 can handle textures that need an alpha border to be cut out.
First, I ran across Quake 64, which uses the RDP’s Alpha Compare functionality to cut out its font. Alpha Compare is relatively simple - it takes place after the Color Combiner stage and before the Blender stage. If the alpha value of the color output by the Color Combiner is less than or equal to the alpha value specified in the Blend Color register, the RDP will not pass that pixel into the Blender. If the combined alpha is greater than the alpha value specified in the Blend Color register, the RDP will rasterize the pixel through the Blender.
Sure enough, the UI’s text is now fine:
Next, I finally came to the realization that there is no other form of automatic pixel rejection based on an alpha value, thanks to a tip from a fellow who goes by the nickname of ‘Happy’. He put forth the idea that the N64 only supports Alpha Compare and no other method for automatic pixel rejection, which caused me to look a bit closer at things like the karts in Mario Kart 64 and the trees in Super Mario 64.
Sure enough, it turns out that I had to emulate the effects of the “Coverage Times Alpha” bit in the Set Other Modes command. I was only emulating the “Use Coverage As Alpha” bit, and since the transparent pixels were fully covered, they were being rasterized due to their coverage being non-zero. However, the pixel alpha value was, in fact, zero, so multiplying the coverage value by zero resulted in a final blended alpha of zero! Brilliant! Mario Kart 64 and Super Mario 64 now look much better:
I then turned to Space Station: Silicon Valley, wherein the Take 2 logo was completely black. It turns out that if both alpha values of the second Blend cycle are zero, the pixel does not become zero - in fact, the cycle is then just ignored. A quick fix later and the logo sprang to life:
Lastly is a personally controversial fix in that it wasn’t until this blog post that I realized that the fix I came up with causes problems in other games. In Bust-A-Move 2, there is an animated ground plane that is drawn line-by-line down the screen. The topmost line of the plane actually has a T coordinate of 160.0, and as a result the Set Tile Size command sets the tile’s T base to be 160.0. However, the S and T mask bits were set to 7, which results in the coordinates mirroring from 0 to 127 and back. Since the texture coordinates were being adjusted by the values in the Set Tile Size command after mirroring, and the mirroring was affecting the coordinates, they were not remaining at the appropriate position.
Before my modification to the order of coordinate adjustment, the ground plane looked like this:
After my change, the ground plane looked like this:
Unfortunately, I discovered when writing this blog post that the same change seems to affect the text in some games, so it will need further examination. Still, I feel I’m on the right track.
A number of N64 games in MESS have suffered from a strangle hall-of-mirrors effect, or assorted missing graphics. Since I’ve had some time off from work, I decided to look into it.
As it turns out, I wasn’t properly emulating the fact that the most significant coverage bit is stored in CPU-visible memory as the least significant bit in a 16-bit RGB555 triplet. This didn’t have much of an effect on things unless a game was copying the framebuffer contents into RAM, in which case the low bit was used as the alpha bit in a 16-bit RGB555 texture that was used in the following frame.
In addition, I’ve had it re-confirmed in my mind that in at least some cases the N64 does not choose not to blend a pixel if its alpha value is 0; this along with the coverage bit fix has the following effects on the following games that I’ve tested:
- Mario Kart 64: The full backgrounds in menus now appear, rather than the first 16 lines or so, and the jumbotron in the Luigi Raceway and Wario Speedway venues work:
Dr. Mario 64: The playfield no longer becomes all white and hall-of-mirror-y when playing:
Pokemon Puzzle League: The scrim around the playfield and HUD is now visible.
Tetrisphere: There’s no longer a hall-of-mirrors effect between the gaps in the undulating background tiles.
I have a strong feeling that in some cases the N64 does reject pixels prior to color-combination and blending if they have an alpha value of0, it just may be controlled by a mechanism I do not fully understand (Force Blend bit in the Set Other Modes command?).