Native PC port engineering
G-Diffuser
A source port is not a wrapper around an emulator. The decompiled game, a hardware-abstraction runtime, two renderers, and the 64DD disk system all have to agree on one coherent product.
Problem
F-Zero X never left the N64, and its 64DD Expansion Kit never left Japan. Running the complete experience natively on PC, with modern display, input, and modding expectations, requires engineering well beyond emulation accuracy.
Engineering approach
- Build on the inspectredc/fzerox matching decompilation and the libultraship runtime, the engine behind Ship of Harkinian, targeting Direct3D 11 on Windows and OpenGL on Linux from one codebase.
- Load the translated 64DD Expansion Kit disk and IPL ROM to unlock the Course Edit track editor and the DD cups, journaling disk writes to a sidecar file so the original disk image is never modified.
- Implement true 16:9 widescreen rendering with a widescreen-anchored HUD, plus an ImGui enhancement menu covering graphics, audio, gameplay, practice, ghosts, and workshop tabs.
- Add a host-side ghost library with .gdg import/export and a browser window, and texture-pack modding with hot reload and in-game asset dumping tools.
Outcome
- The full Expansion Kit experience, Course Edit included, runs natively on Windows and Linux from user-supplied dumps; the repository ships no game assets.
- The port turns a console-exclusive into a moddable PC platform, with a documented texture-pack format and durable save handling for a disk peripheral designed to be rewritten.
The hardest problem
Let Course Edit and the DD cups save for years without ever touching the player's original 64DD disk image.
The Expansion Kit was built around a rewritable disk peripheral, so the game expects to write anywhere on disk at any moment, but the .ndd image is an irreplaceable artifact that one bad write corrupts.
Intercept disk writes at the 64DD layer and journal them into a sidecar file; reads resolve journal-first, so the original image stays byte-identical forever.
How I worked through it
The naive answer is copy-on-write: duplicate the ~65 MB disk image and let the game write into the copy. That multiplies disk usage per install, confuses players about which file is canonical, and still puts a writable image one bug away from corruption. Journaling inverts the relationship: the original becomes read-only truth, and every write the game issues is appended to a small sidecar with enough structure to replay or reset.
The same discipline shaped the rest of the port. New features go into the host-side ImGui menu; content the 64DD already renders, workshop tracks, machines, ghosts, stays in the game's own menus through the Expansion Kit. Two UI layers with one rule: extend around the game, never in place of it.
Technologies
- C
- libultraship
- Fast3D
- Direct3D 11
- OpenGL
- SDL2
- Dear ImGui
- CMake
- N64 decompilation