Changes

To understand the current plugin situation, and why there are several competing emulators that all appear to use the same plugins but said plugins are not compatible across emulators, a bit of history is in order. As for the terms HLE and LLE, which will occur with frequency throughout this page, and the difference between them, it is recommended to read this page on [[High/Low level emulation]] beforehand.

Historically, the majority of N64 emulators all shared the same plugin spec (known as the zilmar spec, after the creator of Project64, the first emulator to use it), and could therefore all use the same plugins, meaning you could take a plugin DLL file, use it on one emulator, then take that DLL and use it on another, and it would also work there. Of these, the big three emulators were [[Project64]], [[1964 ]] and Mupen64. Each had advantages and disadvantages, and some games worked well in one only to not work in another, even when using the same plugin configuration. This necessitated having all of these emulators and sometimes even older or modified versions of them, along with a great many plugins, to be able to play most of the N64 library with the least amount of issues possible - though admittedly a good amount of games (particularly the most popular ones) were playable with just the best few of them. To illustrate the point, [http://bhemuhelp.unaux.com/n64mgcl/N64ConfigList.html here] is a site that, as late as 2012, was dedicated to documenting the exact emulator, plugin and settings combination necessary to get each and every game to at least a playable state, if at all possible.

HoweverTo illustrate the point, [http://bhemuhelp.unaux.com/n64mgcl/N64ConfigList.html here] is a site that, as late as time went on2012, was dedicated to documenting the exact emulator, things began plugin and settings combination necessary to get each and every game to changeat least a playable state, slowly if at firstall possible. 1964's development eventually ceasedUnsurprisingly, this situation often led to a lot of confusion from users, who often wondered why there were so many plugins, and it completely fell off which ones were the radar. Mupen64 was forked into Mupen64Plus and developed its own plugin spec that was incompatible with the older zilmar spec, making it unable best to use existing plugins unless they were specifically ported , only to find out it. This left only Project64 as often depended on the only relevant game, and active emulator still using the zilmar spec. For some time, even then, this left some games would refuse to work as intended no matter what was tried. Hence the fledgling Mupen64Plus missing out on most cutting-edge label "plugin developmenthell" was coined, and stuck as most people were still using Project64a description of the travails of trying to emulate N64 games well into the 2010's.

However, as time went on, things began to change, slowly at first. 1964's development eventually ceased, and it completely fell off the radar. Mupen64 was forked into [[Mupen64Plus]] and developed its own plugin spec that was incompatible with the older zilmar spec, making it unable to use existing plugins unless they were specifically ported to it. This left only Project64 as the only relevant and active emulator still using the zilmar spec. For some time, then, this left the fledgling Mupen64Plus missing out on most cutting-edge plugin development, as most people were still using Project64. A semblance of parity began to come about as a result of several major developments: first, Mupen64Plus itself was forked by the [[libretro ]] team, which made many improvements to the core emulator, and integrated its plugins into the core itself. Second, gonetz, the developer of Glide64, unveiled his newest plugin, GLideN64, which would officially support both the zilmar and Mupen64Plus specs from the beginning. Third, the Angrylion plugin, which is the most accurate and compatible (and slowest) plugin there is, began to be ported both for use with standard Mupen64Plus and the libretro fork. Finally, Themaister, one of the creators of libretro and [[RetroArch]], began developing a unique plugin initially exclusive to libretro known as ParaLLEl-RDP, essentially Angrylion running on the GPU through Vulkan compute shaders, enabling near-perfect N64 graphics emulation at actually playable speeds. Add to this the fact that most PCs and many mobile devices are now more than capable enough of running the most advanced plugins, and the plugin situation, once considered a labyrinth, has been greatly simplified to just needing a few for the vast majority of use cases.

*The zilmar spec - Utilized by Project64 and most other legacy emulators; only Project64 still uses it today.*

|Glide64**

An LLE video plugin based on inspired by and referenced against Angrylion's RDP plugin, ported made to run on the GPU through the use of the Vulkan API's compute shaders. It was introduced in the ParaLLEl-N64 libretro core, is also available in the newer Mupen64Plus-Next core, and is included in [[m64p]] and [https://www.64dd.org/downloads.html this build] of Project64 (if you just want the plugin for Project64, grab it [https://www.mediafire.com/file/neig4q7r788puj3/pj64-parallelrdp.rar here]). This is currently considered the best video plugin by most measures. It is just as accurate and compatible as Angrylion's RDP, but much faster. Like most Angrylion forks, it allows disabling of VI features such as anti-aliasing and blur. Unlike the software-rendered Angrylion, however, it also allows a number of enhancements, including hi-res upscaling, resulting in a sharp, high-definition picture while simultaneously retaining accuracy, essentially what the N64 output would look like if the original console could render in HD. It has higher system requirements than the other plugins, however. It requires a GPU with Vulkan support (most GPUs from 2014 onwards are covered) and up-to-date drivers, and upscaling increases the GPU requirements even further, far more than GLideN64. At native resolution, however, a modest PC with Vulkan support can handle it without much issue, even on integrated graphics. Due to its LLE nature, it does not support widescreen hacks or high-res textures - try GLideN64 if you seek to use such features.

A hybrid HLE/LLE plugin developed by the maker of Glide64, though its code is actually originally based on gln64 (with combiner hacks from Glide64 and LLE code from z64gland, to a lesser extent, angrylion). It is included with the latest versions of Project64, the Mupen64Plus-Next libretro core, and [https://github.com/loganmc10/m64p/releases/tag/v2021.5.30 older versions of m64p]. This is the best HLE plugin by far. The plugin currently supports mip-mapping, emulation of low-level triangles, microcode of every game, gamma correction, flat and prim shading, VI emulation, and LLE graphics (though defaults to HLE). It is the only plugin that has [[Nintendo_64_emulators#High-level_vs._low-level_graphics|implemented HLE support]] of microcodes for every N64 game (including the infamous Factor 5 and BOSS games) to enable fast performance and graphical enhancements. It currently fixes numerous long-standing issues in games and is capable of smoothly emulating advanced framebuffer effects in hardware that Glide64 and Jabo could not. It also supports several enhancements, such as hi-res custom [[Texture_Packs|texture support]], AA and AF, a [[Widescreen_Hack|widescreen hack]], and even some shaders. There is support for an "[[Overscan]]" feature that helps the users to [[Widescreen_Hack#Nintendo_64|remove black borders around a game's visual output]]. It requires at least OpenGL 3.3 in the latest versions to run, and OpenGL 4.x for some advanced functions, making this plugin more demanding than the plugins that came before it, though modern GPUs should be ok, even on mobile. It is not without its share of issues to this day, however. There are still several HLE bugs left to resolve, and its LLE mode, while much improved over z64gl's, is still not quite as developed as its HLE mode, and some of the plugin's enhancement features are disabled in this mode. Since it is hardware-rendered even in LLE, there are issues that may never be quite resolved due to inherent differences between the N64 hardware and the OpenGL API. It is advisable to use this over ParaLLEl-RDP only if you are unable to run the latter in HD at full speed or if further enhancements such as widescreen hacks and hi-res textures are desired. 

This is a fork of Angrylion's RDP that supports multithreading. It now is included in [https://64dd.org/downloads.html this build] of Project64 and in both N64 libretro cores. The standalone plugin version uses OpenGL 3.3 for drawing the picture and also supports Linux. The multi-threading helps boost performance significantly, but some games are still not full speed even on a Core i7-8700K. This fork has at least one accuracy regression, compared to the official version of Angrylion. It also allows you to disable VI filtersfor slightly better performance. Since it is a CPU-bound, software-rendered plugin, it has no enhancement options of any kind - what you see is what you get, exactly like on a real N64. Use this only if running a relatively fast CPU and ParaLLEl-RDP does not work with your GPU for whatever reason. 

*[http://www.emutalk.net/threads/54166-Rice-Video-Community-version Rice Video] - A fast, highly configurable video plugin once famous for its ability to load [[Texture_Packs|hi-res textures]], making it a popular plugin within the N64 emulation community. The 1964 team at one point annexed it as its official video plugin, renaming it 1964Video. There are many versions and forks of it floating around, either to fix issues or add features, and one such version is included in mainline Mupen64Plus and in the ParaLLEl-N64 libretro core. It eventually lost favor to Glide64, which can also load hi-res textures, and its compatibility as a whole is subpar even for an HLE plugin. The latest version is also full of regressions compared to older versions, even as it attempted to fix issues with those. As such, none of its variations are recommended for general use unless there's a very specific fringe case (such as some really old texture packs or ROM hacks), you're using a very, very old toaster, or are trying to emulate on a severely underpowered mobile device or handheld.

Below is a gallery comparing how many of these plugins handle Mario Tennis, a hard-to-emulate game with many special effects that few plugins get right. Pay attention to the scoreboard on the top left, the MPH indicator on the top right, the NPCs on the back, shadows below the characters, and the trail and sparkle effects on the tennis ball and rackets. Only GLideN64 and the Angrylion-derived plugins emulate it correctly:

Mario Tennis ParaLLEl 1x.png|Mario Tennis running on Mupen64Plus-Next using ParaLLEl-RDP at native resolution. PixelIdentical to Angrylion, and thus a pixel-perfect representation of real hardware.

*Jabo's DirectInput Project64 Input - Comes with Project64, but now removed in favor as of NRage Inputthe latest versions. It isnVery simple input plugin which looks suspiciously a lot like Jabo't too bads, but it may have some compatibility problems with some controllers. Should work just fine with the keyboard if you're one of those masochists who emulates without a controller. Only standard controller emulation with nothing attached to it. As usualat least has XInput support, do not expect any updateswhich is nice.

*Zilmar's RSP - Comes with Project64. Reasonably accurate, quite fast in Recompiler mode (enabled by default), and will work fine for just about every gamethe majority of games, only having issues with a few games in LLE. The version included in Project64 2.x and beyond can work with both LLE and HLE plugins by toggling the relevant options in the Plugins settings menu. This plugin is exclusive to the zilmar spec.*Mupen64Plus HLE RSP - Comes with Mupen64Plus. Based off of the old Mupen64 HLE RSP plugin, but much improved. Though it is only compatible with HLE audio and video plugins, when paired with GLideN64, it can play almost every single N64 game without issues, and it now has MusyX support as well for games that used it. This If you wish to use it with Project64, a zilmar-spec port is available and can be obtained by using [https://github.com/Rosalie241/BetterMajorasMaskInstaller/releases/tag/4.0.2 this installer]. It works out of the box with both the default Project64 Audio plugin as well as Azimer's, but it will not with Jabo's, as that is exclusive to the Mupen64Plus spec a pure LLE audio plugin and libretrorequires LLE RSP emulation.*[http://www.emutalk.net/threads/56919-quot-Static-quot-RSP-Interpreter-Plugin "Static" RSP Interpreter/CXD4 RSP] - Made by HatCat/CXD4 and originally released in [http://forum.pj64-emu.com/showthread.php?t=3618 Project64 Forum]. Comes with some forks of Mupen64Plus as well as both libretro cores, and is included in [https://64dd.org/downloads.html this build] of Project64. For whatever reason, the zilmar-spec version usually goes by Static Interpreter, while the Mupen64Plus-spec and libretro versions go by CXD4. As of the most recent release version, it is not only one of the most accurate RSP plugins, but also one of the fastest if using the SSSE3 version, though zilmar's RSP in Recompiler mode trumps as well as ParaLLEl-RSP both trump it in speed. It also comes in SSE2 and non-SSE variations in case your PC does not support those instruction sets. If using the zilmar-spec version, it is capable of working with both HLE and LLE audio and video plugins via the following settings:

*ParaLLEl-RSP - A fast and accurate RSP based on the work of [https://github.com/Themaister/parallel-rsp Themaister]. It is almost as accurate and compatible as CXD4, while being much faster. It is an RSP option mainly used in the [https://www.libretro.com/index.php/parallel-n64-with-parallel-rsp-dynarec-release-fast-and-accurate-n64-emulation/ ParaLLEl-N64 and Mupen64Plus-Next libretro cores]; however, it is also possible to use it with Mupen64Plus, its forks [[M64p]] and [[RMG]], and now even Project64 as a plugin([https://64dd.org/downloads.html this version] comes bundled with it). It only works with LLE video and audio plugins, however.

*Mupen64 HLE RSP - Comes with the old zilmar-spec Mupen64. A very fast and compatible HLE RSP plugin. Written by Hacktarux and Azimer. Has issues with some games, particularly those using MusyX microcode. MusyX support was and many other compatibility fixes were later added to the Mupen64Plus version, but those changes have yet to be backported which has now been ported to the zilmar-spec versionafter years of exclusivity on the Mupen64Plus side of things. Hardly needed these days for the zilmar-spec emulators and especially Project64As such, as zilmar's RSP plugin this version is fast enough, and Azimer's audio plugin now incorporates much of the new HLE RSP code from Mupen64Plus anywayofficially obsolete.

**Zilmar's RSP or Mupen64Plus HLE RSP**Make sure you configure the graphics plugin to show texture enhancement options. Then you'll have an extra tab to change more options. Go to the texture enhancement tab and click on the button that gives the best performance and it should improve framerate once you saved the settings. There's also another button for best texture quality. There's little need to touch the other plugins. Recommended for the older zilmar-spec emulators as well (replace Project64 Video with Glide64 Final for those). If you absolutely need more performance, you can try Jabo's plugin (specifically version 1.6.1, NOT the buggy version bundled with Project64), though it comes at a cost to compatibility. Also, try out the Mupen64Plus HLE RSP if you'd like to eke out that extra bit of performance.