Introduction
There have been many Nintendo 64 emulators over the years ever since the Nintendo 64 came out. Several major mentions include UltraHLE, a Nintendo 64 emulator that proved it was possible. Of course, the emulator was discontinued shortly after release. Many different emulators over the past 10 years have been developed and only a handful or even less are suitable for public usage. However, compared to like NES/SNES emulation (which is quite mature), emulation of the system is *still* in a infantile stage. Over time, a emerging push for more accurate emulation methodologies such as low level video processor (RDP) emulation has been made (such as recent work by Ziggy and Angrylion), however, the less accurate “HLE” approach to graphics emulation largely remains dominant.
This exposé will help highlight the several emulators for Nintendo 64 over the years that are now usable for the end public. This article will take into account the technical abilities, as well as the end user experience. The article was written with the following hardware in mind:
The emulators
Project64 is one of the most popular Nintendo 64 emulators, written by Nicholas Hamilton aka “zilmar” during his initial years of university. It has grown over the years and is the subject of quite some recent contraversy regarding its distribution practise. After version 1.4, its popularity exploded and now its at version 1.6 for the *public* release and a tentative version 1.7 *beta* release. There is essentially two seperate code forks, since 1.7 is a heavy rewrite into pure C++, whereas 1.6 is mainly C. Zilmar is one of the main developers that came up with the idea of emulator plugins, a means to modularise emulation by offloading the video/sound/input/coprocessor emulation to seperate components, like how Winamp operates with its input/DSP/output plugins. This allows for interchangeability of emulation components with other emulators supporting its plugin API, but also introduces major support issues, which were not present with earlier emulators, which kept all emulation central to the emulator itself. Also, some end users may prefer the purist, no emulator plugin approach.
Project64 1.6 is the most current *public* version of the emulator, which is free to download at no cost. In stark contrast to SNES emulators, it uses a internal database to store ROM information, as well as using it for game specific settings, or “hacks”, in order to run the game the user wants to. In addition, it includes several bundled plugins for video, input, sound and RSP (Reality Signal Processor) emulation, instead of keeping all code inside the EXE. User interface wise, its quite clean and polished, however a option to set plugins per-game, is sadly absent.
With the default plugin set, it performs quite well (its also to have been reported it runs well on other less powerful systems), apart from graphics glitches that can occur in many games. Many of these glitches manifest in incomplete special effects emulation, such as motion blur in Sin and Punishment, screen transistions in Legend of Zelda Majora’s Mask, missing effects & skybox in Perfect Dark and GoldenEye, broken rendering in Resident Evil 2, etc.
The most popular games on the most part, like Legend of Zelda: Ocarina of Time, Super Mario 64, etc run well with little graphical errors. Sound emulation on the other hand, is almost perfect apart from a small number of games. Stability is also on par, except for games which can crash the emulator on occasion, like Banjo Tooie, etc. All, in all, it works, if you have a suitable graphics plugin (like Glide64)and are willing to put up with other quirks, like sound bugs in certain games or crashes due to faulty core emulation also in a small number of games.
Project64 1.7 is the tentative non-public release of the emulator. In a complete backflip, to acquire access to the “beta or alpha program”, you need to pay a minimum of $20 AUD to the developers. However, it is possible to have a leaked version of the emulator, providing its cracked, and virus free.
It has however, got several major differences over PJ64 1.6:
- Supports low level graphics emulation (so games like Star Wars Rogue Squadron etc are able to boot. However, this is extremely slow.)
- Supports high resolution texture dumping/loading (in a custom format)
- Supports software graphics rendering in the new video plugin. (albeit slow in cases)
- Improved core/audio timing so games like Banjo Tooie, Resident Evil 2, Hydro Thunder, etc have correct sound or no crashes.
- Support for per-game plugin settings.
- Improved graphics emulation. Many games have now got improved effects emulation as well as Dark Rift and Frogger 2 now being playable.
However, the emulator unfortunately, is extremely unstable. There are many bugs in the emulator still, such as crashes when enabling cheats, glitches in the GUI, several outstanding emulation errors, as well as other problems. So, understanding this, care should be taken before using this build of Project64. However, those who are willing to try low level graphics emulation might want to try this.
1964 is another plugin based emulator, written by Joel Middendorf aka “Schibo” and “Rice”. For several years, it was at version 0.9.9 until a surprise release jumped it to version 1.1.
It, again is a plugin based emulator. The interface is quite nice, allowing for per game plugins, as well as the emulator core itself is quite optimized; which is nice for playing very intensive games like Goldeneye 007, Perfect Dark, or Conker’s Bad Fur Day. The default included video plugin is a rebadging of Rice’s existing work, so it shares many of its flaws, including inaccurate special effect emulation for many, many games. However, the audio plugin is of merit, as it works via running decompiled RSP code (which is in C) for the various Nintendo 64 audio engines. So, the emulator works quite well soundwise for the games it supports. Additionaly, the GUI apparently has one unique feature: boxart, which is quite novel.
A recent fork however, called “
1964 Ultrafast” is relevant to note too. It is a fork of 1964 1.1 that allows core overclocking, to compensate for games which cause the original Nintendo 64 to lag, like GoldenEye 007.
It also has:
- A heavily optimized interpreter core (60-100% faster)
- More accurate emulation with dynamic recompilation
- Better audio handling and core/audio integration
- Less speed hacks
Mupen64 is a emulator developed by Hacktarux, a French developer. The emulator is written in mostly C and is GPLed. It has ports to Windows, Linux and MacOS. The Windows port of the emulator is supplied with 2 graphics plugins (Direct64/glN64), as well as its own RSP HLE plugin (for fast/inaccurate audio emulation). Ideally, to get best results, its better to mix and match plugins from other plugin-based emulators.
GUI wise, the GUI is nothing special, apart from the ability to set per-ROM plugins like 1964. Corewise however, its quite good, having a stable core, as well as having special support for Glide64′s special effect emulation. With the Glide64 plugin and Mupen64, its possible to have fullspeed effects like the jumbotron screen in Mario Kart 64, unlike other emulators besides Project64 1.7 (which emulates the effect via a hack).
There is a third party fork of this emulator called mupen64Plus, which has also a large list of changes to the vanilla Mupen64. Some of these changes are:
- A port to x64, including all emulator components
- Cross platform GUIs in Qt4/WxWidgets
- Native MacOSX/Linux/Windows/FreeBSD support
- A entirely new core architecture, including core APIs
- Features for creating speedruns, including frame-advance, and realtime adjustment of emulator speed.
Because of the vast amount of core changes though, plugins for Mupen64 are completely incompatible with Mupen64Plus. That said, compatibility with games is high as well as common plugins like Glide64 have native Mupen64Plus ports.
For those unenlightened, the MESS project is a offshoot of the MAME project. The MAME project aims to “preserve and document” hardware, thusly forgoing speed for accuracy as game playing is a “unintended side effect” of the hardware “preservation”. The MAME project preserves arcade machines. Likewise, MESS does the same, except for consoles. The Nintendo 64 emulation in MESS is the result of several people including Ville Linde, Ryan “MooglyGuy” Holtz and angrylion. MESS, unlike the other Nintendo 64 emulators, does not use plugins and forgoes anything that goes against the pursuit of accuracy as defined by the devs working on MESS…
This means, no HLE graphics rendering, rendering in software only, and everything emulated on a low level. As such, it generally is unusable for gaming due to the immense speed hit these things make. In addition, setting up the emulator is very cumbersome. The Nintendo 64 PIF ROM plus two other ROM files are needed to start the emulator, plus the MESS GUI is very untidy. Not to mention, the commandline client too, which neophytes might find extremely unfriendly.
The emulation, while very slow, is quite a nice proof of concept of pure low level emulation for the Nintendo 64. Most games however crash and fail to run fully. So I have to not recommend this for public use, at all, especially due to the unwieldy interface, which can in fact, drive users away from using the emulator at all.
Conclusion
In conclusion, Nintendo 64 emulation has improved marginally from earlier attempts (especially during late 2010 and early 2011), however in many ways, there has been a step backward, namely in the number of emulators in development, as well as the methods used. Also, the scene itself is dwindling as the amount of developers in the scene is smaller, while scenes like the Wii/PS2/Dreamcast scenes just grow in popularity. Accuracy is still a major issue as it was in 1996, as well as the number of hacks being used for adequate emulation. Developments like hi-res texture packs only just jumpstarted the Nintendo 64 scene, while efforts like commercial emulators greatly undermine progress since the information is proprietary, especially with a scene so small, not to mention console developers clamping down on said activities. Therefore and finally, the future of this scene is quite uncertain, when newer consoles ironically have more faithful emulation as a whole, than the Nintendo 64 has experienced so far.
), plus decompression/compression related bugs which for some reason I don’t know pop up on some targets. Future plans for it are DLL support as well as support for OCX files, screensavers etc. Adding support for ryg’s 
