PhobosLab

Blog<br>Games<br>Projects

Dominic Szablewski, @phoboslab

— Tuesday, August 4th 2026

How to Make a Nintendo 64 Game in 2026

Two years ago, I was Porting my JavaScript Game Engine to C for No Reason.<br>I have since found a reason: making a new N64 game!

The result is Xibalba 64 – a Wolfenstein<br>3D-like FPS. Modretro agreed to publish the game as a physical launch title for their M64<br>(a modern N64 clone), complete with cartridge, packaging and manual!

Xibalba 64 on Modretro.com

This, to my knowledge, is only the second physical release of any new N64 game since<br>the end of the console's original commercial life. The infamous Xeno Crisis<br>by Bitmap Bureau –<br>originally a new game for the Sega Mega Drive and subsequently released on many,<br>many more consoles – came to the N64 in 2023. No other new games have been<br>published for the N64 since Tony Hawk's Pro Skater 3 in 2002.

The Engine

Impact was a JavaScript game engine I developed back in 2010.<br>It was tailored for 2D action games, handling tile sheets, background maps, sprites<br>and collision detection. It's very simple, but still a sound foundation for<br>whatever you want to throw at it.

Two years ago I rewrote Impact in C. Why? I don't know. It was fun.

This C port, high_impact, has a notion of a<br>“platform backend”. The platform handles the low-level plumbing – opening a<br>window, creating a drawing surface, reading input, etc. Out of the box, high_impact<br>comes with two platform backends (SDL2 and Sokol), and you can compile your game<br>for either one. This already enables high_impact games to run on many different<br>devices.

The rendering backend in high_impact is also modular. You can compile your game<br>with a software renderer, OpenGL or Metal (for iOS/macOS). Support for new<br>platform backends or rendering backends can be added without modifying<br>any other part of the engine.

A perfect starting point for an N64 game.

N64 Hardware and Platform Library

The N64 is a quirky beast. In addition to the 93 MHz MIPS CPU (big-endian!), it has two<br>coprocessors for handling graphics, sound and more:

“Reality Display Processor” (RDP) – a fixed-function graphics processor

“Reality Signal Processor” (RSP) – a programmable vector processor

Both of these live in the same physical package, commonly called the “Reality Coprocessor”<br>(RCP).

Image from the N64Brew Wiki

For the first few years of the N64's life, Nintendo closely guarded access to the<br>RSP. It was exclusively used by Nintendo's officially sanctioned platform library, “libultra”.<br>Only later did Nintendo allow game studios to write custom “microcode” (actually just<br>MIPS assembly) for the RSP.

Keeping the hardware happy is no simple feat, and the instructions for the RDP are<br>quirky and complicated. Programming your game on bare metal is pretty much<br>out of the question. In recent years, Nintendo's official “libultra” has made its<br>way onto the internet, but using it would risk a copyright lawsuit.

Luckily, the N64 homebrew scene has picked up a lot of steam in the last few<br>years and we have a very capable alternative now: Libdragon.

Libdragon is basically SDL for the N64. It provides facilities for drawing<br>sprites and triangles, sound output, controller input and much more.

It took me only a few evenings to build a new platform backend for high_impact on<br>top of libdragon. I tested this with Biolab Disaster.<br>The game code remained unmodified; performance was meh, but I was using the<br>N64 hardware in the most naive way possible.

Video from my post on X, Sep 17, 2025 showing Biolab Disaster running in an N64 emulator

Dev Environment

Libdragon provides the compilers and everything else that's necessary to build a ROM<br>file for the N64. The installation instructions<br>and all other documentation are comprehensive and well-written. The library comes<br>with many examples to get you started.

In general, it was a pleasure to work with Libdragon. Just a heads up: you<br>probably want to use the preview branch as the “stable” trunk branch has<br>hopelessly fallen behind.

For testing, a good emulator is invaluable. For the longest time, N64 emulation<br>was extremely inaccurate. Lackluster emulation of the RSP and RDP coprocessors,<br>in particular, was the cause of most problems.

Most emulators just emulated Nintendo's platform library, libultra. They emulated<br>the intent to draw a triangle, not what the hardware would actually do. While<br>inaccurate, this made emulation possible at all in the early<br>days. Famously, UltraHLE<br>(“Ultra High Level Emulator”) was released well within the lifetime of the N64<br>and caused a lot of headaches and subsequent lawsuits.

These days the N64 core in Ares is much closer to the<br>actual hardware – the RDP and RSP are fully emulated, including accurate timing<br>for the RSP. The infamous slow memory bandwidth of the N64, however, can still only<br>be tested on real hardware (which recently caused me some disappointment).

So you need a real N64 and a cartridge that lets you play arbitrary .z64 ROM files.<br>The...