Emulation General

Nintendo 64 emulators

213pages on
this wiki
Add New Page
Talk0 Share

The Nintendo 64 (N64) console

The Nintendo 64 is a 64-bit, 5th generation console released by Nintendo in 1996.

Emulation for the N64 is a confusing topic. The system is complex and confounded , leading to it being difficult to create an emulator compatible with some games even with available documentation. Some games require specific plugin set ups with specific emulators.


Name Operating System(s) Latest Version Active Recommended
Mupen64Plus Multi-platform SVN



Multi-platform 2.0-rc2
Project64 Windows 2.2
1964 Windows

1.1 (official)

1.2 r146 (SVN)

Daedalus Windows 1.1
MESS Multiplatform 0.150
Sixtyforce OS X 0.9.8
CEN64 Windows, Linux Git
UltraHLE Windows 1.0.0
Name Operating Systems(s) Latest Version Active Recommended
Daedalus PlayStation Portable SVN
Not64 Wii, Gamecube 20150205
Wii64 Wii, Gamecube 1.1 beta



N64 emulation is a complete mess (and broken). Every emulator has its own unique compatibility issues, and it varies significantly even within one emulator if using different plugins. Refer to this link for optimal emulator settings based on the game you want to play. In terms of compatibility with the N64's game library, vanilla Mupen64 was basically always better than Project64 1.6, with 1964 basically only working well for a few different games. Mupen64Plus improves upon Mupen64 even further, while Project64 2.1 only fixed a few things and broke others. Mupen64Plus is receiving far more updates, and will likely be the go-to emulator for general use in the future.

  • Mupen64+ is the best overall N64 emulator, but you still need PJ64 for certain games. It lacks a native GUI, and instead is ran by dragging and dropping ROMS and editing the config with notepad++. There are GUIs made for it, but many are problematic and glitchy.
  • RetroArch has a port of M64+ it has support for multi-pass shaders.[1]
  • Bizhawk has a port of M64+ and it seems to work well enough. Bizhawk lacks portability however, and is only Windows and OSX only.
  • Daedalus, results are even more hit-and-miss than on other emulators due to being made for PSP first and foremost. On PSP, most games are unplayable, but there's a small amount of them that work really well with the right settings (California Speed, Donkey Kong 64, and Quest 64, for example). It's the only option for N64 emulation on PSP.
  • Wii64 and Not64 are both based on Mupen64, with Not64 being a fork of Wii64. Not64 claims to be better optimised, as well as having higher compatibility and more frequent updates. N64 emulation on Wii is not very good, and it is recommended to stick with the Virtual Console N64 releases.
  • MESS uses a very accurate method of emulation, but as a result is very, very slow, so it's hardly usable on most current hardware. Its core is also very unstable and prone to crashing.
  • Sixtyforce is Mac-only, closed-source, which asks you to pay for it to use all its features. It's utterly irrelevant now.
  • CEN64 aims to accurately emulate the N64 (like MESS), but it requires a high-end computer to run games at full speed.
  • UltraHLE only works if you have a 3dfx based video card, and its no longer being active, since 1999. But, if you have an old toaster, its an option. According to its compatibility list, it can play some commercial games without any major bugs, just with small glitches.

Emulation issuesEdit

The N64 was (not unlike the Sega Saturn) an overly complex machine that was difficult to program for. The N64's RDP was pretty much the first real 3D accelerator GPU on consoles. In fact, at the time it came out, it was the most powerful consumer-grade GPU in the world (came out a few months before the Voodoo). It is very hard to emulate all of its functions accurately due to the lack of publicly available documentation for emulator developers. Many RDP functions have to be reproduced in software for accuracy, which takes a lot of power. Especially if you also reproduce the coverage filters, which are a nuisance because they make the image look blurry, and at the same time necessary for pixel-perfect graphics. For this reason, emulating it with a high degree of accuracy and compatibility has proven to be no simple task.

High-level vs. low-level graphicsEdit

One of the biggest hurdles in the road to proper N64 emulation has been accurately emulating the N64's graphics hardware, known as the Reality Display Processor, itself a part of the N64's Reality Co-Processor. The RDP is a very complex, fully-featured GPU, and emulating it at a low level has proved to be a daunting task that requires a lot of research, coding expertise, and immense amounts of system resources.

For this reason, most developers have instead opted to approximate the RDP's functions using high-level emulation (HLE) through various APIs such as Direct3D, OpenGL, and even Glide. While this results in much more reasonable system requirements for emulation along with prettier, higher resolution graphics, this method can be hit and miss, often requiring per-game tweaks and settings to prevent graphical glitches on many games. Some games that implemented custom microcode (which has yet to be reverse-engineered) such as Factor 5's games do not work with hardware accelerated plugins except Z64gl.

It should also be noted that even though most games "work" through the HLE method, it is not an accurate representation of what the N64 hardware's video output actually looked like, but rather a rough approximation by PC graphics hardware. Your mileage may vary on whether this is a good thing or not, given the N64's often blurry, low-res output.

Texture filteringEdit

The N64 was the first console to feature texture filtering of any kind. However, unlike PC graphics hardware and every console after the N64, its implementation of bilinear texture filtering was unique in that in order to reduce strain on the system, it only used three samples as opposed to four, resulting in slightly jagged textures. Instead of faithfully applying this "imperfect" version of bilinear, HLE plugins instead apply conventional bilinear filtering, interpolating straight from the source texture up to the output resolution, much like on PC games. While technically this method of bilinear filtering is superior to the N64's, it can also result in textures that look even blurrier than on real hardware.

Another issue lies with the appliance of texture filtering per quad on static images, text, and sprites. Because each quad is filtered separately, this can cause some visual inconsistencies. Text and UI elements often look as though their edges cut off abruptly, and static images such as prerendered backgrounds or menu screens may look as though they are separated into squares. Some plugins allow the user to turn off texture filtering to remedy this, but unfortunately this also applies to textures in the game world, exposing their often extremely low-res nature.

So basically, unless Nintendo literally drops all the hardware specs and inner-workings of the N64 or all the members of every emulation project decide to get together to form the best emulator ever made- its likely to be years before we start seeing actual progress again.

Project64 2013-06-26 17-44-58-31

Conker's BFD copyright screen, displaying issues with filtered text.

Mupen64plus 2013-08-18 20-35-50-08

Ocarina of Time's menu subscreen, displaying issues with filtering. Note how the Quest Status screen appears to be divided into a grid.

Ad blocker interference detected!

Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.