N64 Emulation: The Complete Setup Guide

The Nintendo 64 spent two decades as the awkward one. While the SNES and the Mega Drive reached the point where emulation was effectively a solved problem, N64 emulation remained a negotiation: this plugin for that game, this workaround for those textures, a folder of INI files and received wisdom passed between forum posts. That is no longer the situation, and the reason is worth understanding, because it changes what you should install.

This guide is current as of August 2026, and one thing has changed enough to invalidate most older advice: simple64, which was the accuracy recommendation for years, was archived in February 2025. Its developer moved to a new project. If a guide still tells you to install simple64, it predates that.

Why the N64 Was So Hard

Most consoles of the era drew graphics with fixed-function hardware. Give it a sprite, a position and a palette, and the behaviour is deterministic and well documented. The N64 did something closer to a modern PC. It had a programmable vector processor, the Reality Signal Processor, running small programs the documentation calls microcode, feeding a fixed-function rasteriser, the Reality Display Processor.

It is worth being precise about what followed, because this gets exaggerated. Most commercial games used one of the stock microcodes Nintendo shipped with its SDK, and there were plenty of those on their own: the Fast3D and F3DEX families, F3DEX2, S2DEX for sprite and background work, and the cut-down Turbo3D, which Nintendo's own manual admits drops clipping, lighting and perspective-corrected textures for speed. A game could even swap microcode partway through a frame.

A small number of studios went further and wrote their own. The two properly documented cases are Boss Game Studios, whose ZSort microcode powered World Driver Championship and Stunt Racer 64, and Factor 5, whose work on Indiana Jones and the Infernal Machine and Battle for Naboo has been reverse engineered in detail. The Factor 5 teardown contains a nice deflating discovery: even that microcode was not written from scratch, but built on Nintendo's own F3DEX source, with only a fraction still recognisable.

So the problem was never that every cartridge was a unique snowflake. It was that the emulator had to recognise a moving target, and the exceptions were exactly the technically ambitious games people most wanted to play.

Emulators dealt with this by cheating, entirely reasonably. High Level Emulation recognises what a known microcode is trying to do and substitutes a native implementation: rather than simulating the RSP executing instructions, the emulator spots the microcode and draws the triangles itself. It is dramatically faster, and for years it failed whenever it met something nobody had decoded.

That specific problem is now solved, which is the part most older guides miss. GLideN64's 4.0 release in April 2019 closed out the last of the unsupported microcodes, including a reimplementation of S2DEX that took its author roughly six months. Every N64 game runs in HLE mode today. Worth noting too that GLideN64's own developer has argued most N64 graphics glitches were never HLE's fault at all, but came from the gap between N64 hardware and PC graphics cards.

Low Level Emulation does the honest thing and simulates the processors instead. It is correct by construction, and for years it was far too slow to be practical. So the modern argument is not really HLE versus LLE for compatibility, which HLE won. It is about how exactly you want the picture reproduced.

What Changed: paraLLEl-RDP

The breakthrough was moving low-level emulation off the CPU and onto the GPU.

Angrylion is a software RDP renderer that has long been regarded as the accuracy ceiling: essentially a pixel-perfect reproduction of what the real chip does. Its problem was cost, because it does that work on the CPU and it is punishing.

paraLLEl-RDP, written by Themaister, reimplements the RDP as Vulkan compute shaders. It was not ported from Angrylion; it was written from scratch by studying Angrylion-Plus and working out what the hardware was doing. The result is that at native resolution its output is identical to Angrylion, which is to say pixel-perfect against real hardware, while running fast enough on ordinary machines. Libretro's own framing is that nearly any discrete GPU from 2013 to 2020 with Vulkan support handles low-level N64 graphics comfortably.

This is the single most important thing to understand when choosing an emulator, because the emulators worth using in 2026 are largely the ones built around paraLLEl-RDP. GLideN64, the other renderer you will see recommended, takes the pragmatic HLE approach in OpenGL. It is fast and it looks clean, but it is approximating.

How We Know Any of This Is Accurate

One reason the picture improved so sharply is that the N64 finally got a proper hardware test suite. n64-systemtest is a test ROM that runs on real hardware and on emulators and decides pass or fail itself, with no image comparison involved, covering exception handling, the TLB, memory access at every width, and RSP behaviour including deliberately undocumented and broken opcodes.

The effect on emulator development is visible in the changelogs. ares reported passing 560 of 563 tests in May 2022, roughly 99 percent, after a sustained campaign of fixes covering TLB handling, RSP DMA wraparound and a long list of hardware quirks nobody had bothered with before. That is the only published pass rate worth quoting, so treat any comparison table of emulator accuracy percentages with suspicion, because the numbers largely do not exist.

The suite itself moved on in July 2026 to a successor project, nemu64-test, which is where new tests are being written now.

The Emulators Worth Installing

gopher64 is the current recommendation for most people. It is the successor to simple64, written from scratch in Rust by the same developer, and it uses paraLLEl-RDP for graphics with its remaining internals drawn from a mix of original research, Mupen64Plus and ares. simple64 went into archive mode on 14 February 2025, timed with the gopher64 v1.0.6 release, so this is not a fork situation, it is a replacement. Recent additions include save state slots and cloud netplay servers. It is on Flathub, which makes it straightforward on Linux and the Steam Deck.

ares is the choice when accuracy and preservation matter more than convenience, and it is still being actively worked on: the v148 release in May 2026 rewrote the N64 CPU and RSP recompilers for significant performance gains, and it is also the one to reach for if you care about the 64DD. Its history is routinely misreported, so for the record: ares is not a rename of higan. The lineage runs bsnes in 2004, renamed higan in 2012 as it became multi-system, and then ares forked from higan in March 2020, specifically because higan's cycle-accurate model could not accommodate systems like the N64 and PlayStation. Near, formerly byuu, began it; it became a public open-source project on 5 July 2021 with Luke Usher as project lead.

Rosalie's Mupen GUI (RMG) is the sensible option if you want the Mupen64Plus ecosystem without hand-assembling a command line emulator and its plugins. It wraps Mupen64Plus in a conventional application with graphics, audio, input, cheat and save configuration exposed properly.

RetroArch with the Mupen64Plus-Next core makes sense when the N64 is one system in a larger library and you want one interface, one controller configuration and shaders across all of it. Mupen64Plus-Next 2.0 brought 64DD support, Angrylion and GLideN64 in a single build, and paraLLEl RSP support.

Project64 has the largest install base and the gentlest onboarding, and is Windows only. Be careful with version advice here: the stable release is still 3.0.1 from July 2021, and while there are nightly builds of a 4.0 branch, the project's own community treats them as too experimental for daily use.

Settings That Actually Matter

Most of the settings people obsess over make less difference than the renderer choice. The ones worth attention:

Internal resolution. Upscaling is the reason to emulate rather than use original hardware on a modern display. Bear in mind that the N64's own texture budget was tiny, so at high multipliers you are rendering low-resolution textures very crisply, which some people find worse rather than better. Two or three times native is a reasonable place to start.

Native resolution when you want accuracy. paraLLEl-RDP is only pixel-identical to Angrylion at 1x. If you are checking whether something is an emulation bug or genuine hardware behaviour, drop to native first.

Frame pacing. The N64 library is full of games with unstable frame rates by design. Enable V-Sync and a frame limiter, and resist the temptation to uncap.

Save states versus real saves. Fine in general, but games with real-time clocks or unusual save hardware can behave oddly when a state is restored. Use the in-game save for anything you care about.

What Still Breaks

Custom microcode is no longer the hard problem, and any guide still framing it that way is a decade out of date. The genuinely awkward cases in 2026 are different, and there are three worth knowing about.

World Driver Championship and Stunt Racer 64 are the current landmine. Both use Boss Game Studios' ZSort microcode, and in the Mupen64Plus family they have regressed: they fail to boot with paraLLEl-RSP while working with the older CXD4 RSP. That is an open bug across several trackers rather than a settled situation, so if you hit a black screen on either, switch the RSP plugin before anything else.

Framebuffer effects at upscaled resolution. Games that read rendered output back on the CPU are the ones that resist upscaling. Jet Force Gemini is the standing example: it needs two framebuffer copy settings at once, and enabling both forces the game to render at low resolution. Pokemon Snap is fussier still, and is one of the few titles genuinely better served by an accurate renderer than by a fast one, because Professor Oak's photo evaluation depends on depth precision that HLE approximates.

Graphics driver bugs, which are nobody's fault but yours to work around. Intel integrated graphics on Windows currently produces corrupted textures with paraLLEl-RDP, traced to a driver regression, and Intel's Arc cards have their own Windows problems while working correctly on Linux with Mesa.

One structural fact worth knowing, because it explains why some of these persist: paraLLEl-RDP upstream has had no substantive commits since November 2024. Every accuracy-focused emulator listed above bundles the same renderer, so they inherit the same open issues, including some with fixes already written and waiting.

Hardware You Actually Need

gopher64 states its requirements plainly, and they are a reasonable proxy for this class of emulator: a GPU supporting Vulkan 1.1 or higher, and a CPU supporting AVX2, meaning roughly Intel Haswell or newer, or ARMv8.2-A. Older or budget machines without AVX2 will not run it at all.

For upscaling, the practical advice from the renderer's own author is that 8x exists mainly because the maths allows it, and that 2x or 4x is more than enough. Be aware that published guidance on how much VRAM 8x needs does not agree with the renderer's own documented allocations, so treat any specific figure with suspicion.

The Other Option: Native PC Ports

For a small number of games, emulation is no longer the best route at all, because the games themselves have been reconstructed as native PC software. Two different techniques are involved and they are frequently confused.

Decompilation ports rebuild the original source from the binary, then compile it natively. Ship of Harkinian is the well-known one, giving Ocarina of Time a native PC build with widescreen, high frame rates and mod support. 2Ship2Harkinian does the same for Majora's Mask, with its first public build in May 2024.

Static recompilation is the newer approach: N64Recomp translates the original machine code into native code without needing a full decompilation, which is much faster to apply to a new game. Zelda64Recomp is the flagship, shipping Majora's Mask. Note the detail that trips people up: Ocarina of Time support is planned but has not shipped, so if you want OoT on PC today, Ship of Harkinian is the answer.

Where a port exists, it is usually the better experience. Where one does not, gopher64 with paraLLEl-RDP is as close to the real thing as software gets.

A Note on ROMs

Emulators are legal. Downloading games you do not own is not. Dumping your own cartridges is the clean path, and the hardware to do it is more available than it used to be: Epilogue's 64 Operator arrived in 2026 specifically for N64 carts, and it will also tell you whether a cartridge is genuine, which matters more than it used to now that reproductions are common.

Sources and further reading: gopher64, simple64's archive notice, paraLLEl-RDP, ares, Emulation General Wiki on N64 plugins, Ship of Harkinian, n64brew's hardware wiki, Nintendo's own microcode documentation, GLideN64 4.0 release notes, the Factor 5 microcode teardown, nemu64-test and ares v128's test results.