Changes

|ParaLLElMupen64Plus-Next

|[https://www.retroarch.com/ 2.0-rc2git]|{{✓}}

|[https://github.com/higanares-emuemulator/ares/releases/ {{aresVer}}]

|[https://pj64netplay-emugithub.mlcom/download.html {{Project64NetplayVer}}Project64Netplay/Project64-Netplay-2x git]

|[https://play.google.com/store/apps/details?id=org.mupen64plusae.v3.fzurita 3.0.291 308 (beta)]

Although many Nintendo 64 emulators have been made and many games can be run between them, until recently complete compatibility and/or accuracy still leaves left a bit to be desired. For half a decade, Mupen64Plus and Project64 have vied for the most playable emulator, and which has been was more compatible has often depended on when and in what configuration each emulator has been tested. Both emulators default to lackluster plugins, but, as As of August 2017, both emulators have roughly equal graphical compatibility and accuracy when running with GLideN64the same [[recommended N64 plugins]] setup, though both default to Glide64, a now relatively lackluster plugin.

:;Mupen64Plus-Next and ParaLLEl-N64:A Both are heavily-modified fork forks developed as a [[libretro]] corecores. It introduces They introduce many features and optimizations not present in mainline alongside [[RetroArch]]'s general features, including Project64-style overclocking for faster frame rates, 3-point texture filteringfor Glide64, superior A/V sync and latency, and even an initially exclusive LLE Vulkan renderer based on Angrylion's pixel-perfect RDP pluginnow known as ParaLLEl-RDP, making it a better alternative to the standalone version in some cases, especially if accuracy is the goal. ParaLLEl -RDP has a special "[https://www.youtube.com/watch?v=mzR93F9gPdc Super VI Mode]" option which, if used, can make the visuals of N64 games look less blurry with fairly mitigated jaggies even at their native resolutions. Although, it may need a [https://www.youtube.com/watch?v=z7_D_D419S0 powerful GPU]. It also offers native high-resolution rendering, only available in integer scales of the original N64 resolution.

::As for the difference between the two cores, ParaLLEl-N64 is actually the older of the two, as it is based off of the old Mupen64Plus-libretro core, having been renamed to ParaLLEl-N64 upon its initial integration of the ParaLLEl-RDP and RSP plugins. In addition to the ParaLLEl plugins, it also retains the older HLE plugins (glN64, Rice, and Glide64), as well as Angrylion Plus. Meanwhile, Mupen64Plus-Next is a new rebase off of bleeding-edge mainline, and as such is the more compatible of the two. It does away with the legacy plugins and replaces them with GLideN64 as a better HLE solution (though of course, the ParaLLEl plugins and Angrylion Plus stay), it considerably cleans up the Core Options menu for easier configuration, and it adds Transfer Pack support. Add to this the fact that going forward, all further improvements and new features will be to the Mupen64Plus-Next core, and Mupen64Plus-Next is now the more recommended of the two, thus ParaLLEl-N64 should now only be considered for performance reasons or perhaps for older ROM hacks that don't play well with the newer, more accurate plugins. :;[[m64p]]:Probably the easiest "out of the box" solution for Nintendo 64 emulation. It comes with Parallel ParaLLEl-RDP, as well as its own custom GUI and input plugin. If GLideN64 is desired instead, there is an older build that retains it.

;[[Project64]]:An open-source emulator for Windows, as well as one of the oldest. Its official release builds are more up-to-date than Mupen64Plus', and the current version, 3.0.1, is roughly as accurate as the development versions of Mupen64Plus when both are played with recommended plugins. It has a more user-friendly interface than the Mupen64Plus attempts and supports more features such as overclocking and Transfer Pak emulation. It does come with GLideN64 out-of-the-box, but the default audio plugin isn't even the best in the box. For the most part, it works well in [[Wine]], but, if you're on a different platform, use Mupen64Plus instead.

;[[CEN64]]:Aims for cycle accuracy while, at the same time, aiming to eventually be usable on modern PC hardware. It currently lacks many features and has spotty compatibility, but it's gradually improving. It can already emulate some well-known edge cases such as the picture recognition in Pokemon Snap.

;[[UltraHLE]]:marked a milestone in Nintendo 64 emulation, in that it was the first to play some popular N64 titles at full speed on hardware made at the time of its release through [[High/Low-level emulation|high-level emulation]]; it isn't without its drawbacks though - pressure from users, combined with legal threats from Nintendo, forced them to discontinue development. Besides being for historical value, there's not much to expect from this emulator anyway due to compatibility issues.

One of the biggest hurdles to emulating the Nintendo 64 is was the Reality Display Processor (RDP), one which used a custom design that had to be fine-tuned to get more performance out of two components in the Reality Coprocessor made by SGIsystem using microcode. The Reality Display Processor was To emulate the RDP accurately, one would have to execute said microcode the most powerful consumer-grade GPU at way the time RDP did, which differed from PC graphics cards of the console's release; this was a selling point day. To complicate matters further, API standards that Nintendo were available on PCs two decades ago were nowhere near as flexible as they are today. If you wanted to emphasize as a result of working with SGI. Howevermake an accurate GPU-accelerated RDP plugin in 2003, reverse engineering efforts for popular Nintendo 64 games showed that Nintendoyou simply couldn's software development kit included a common microcode for t with the RDP. It's possible Nintendo didn't want to give developers access at a lower level out of fears that doing so would damage consumer units, but that meant most APIs of the effort spent emulating time (OpenGL 1.x and Direct3D 9). For the RDP average user, hardware-accurate GPU acceleration would go towards figuring be out how to handle the microcodeof reach for a long time.

* Most developers [[UltraHLE]] offered a compromise. In contrast to earlier consoles, whose video chips in 1999 and hindsight had been easy to render to the early 2000s opted host CPU's framebuffer, performant RDP emulation had to take shortcuts, including programming around specific games' microcode to approximate functions through various APIs such as cleanly translate their graphics commands into API calls using Direct3D, OpenGL, and even Glide. While With this resulted in much more reasonable , the theoretical system requirements for emulationplummeted, along with and the host graphics card could reproduce a functional equivalent rather than the exact method. This also gave way to prettier, higher resolution graphics, though whether or not this method is an improvement is subjective and a common point of discussion. Unfortunately it proved to be hit and miss, often requiring owing to the nature of per-game tweaks microcode detection and having to tweak settings to prevent some games for running into graphical glitches on many games. Some games flat out didn't work, because it wasn't clear what the microcode did or why, and required extensive hardware testing.* On the low-level side, developers would either completely emulate the RDP or autodetect the microcode and use an appropriate implementation for the game. The former would mean a software renderer accurate to the hardware but major performance bottlenecks unless optimizations like vectorization and multi-threading were implemented. The latter would mean faster performance but developers would still have to figure out how to account for edge cases.

Low-level RDP emulation was continually improved in that time, most notably by [[MESS]] up until its merger with [[MAME]], where its RDP code was turned into a plugin by Angrylion. Compatibility-wise, Angrylion's RDP was considered flawless by the community, though reception wasn't as warm overall, since it ran only on the CPU and was thus painfully slow on mid-grade machines. A dozen forks attempted to bring the system requirements down and the current incarnation that does so is Angrylion RDP Plus, using multithreading. Accurate low-level emulation would only come to the GPU in 2020, when a new version of the Mupen64Plus-based ParaLLEl [[libretro]] core was released containing a rewritten RDP plugin using compute shaders in Vulkan. Though it isn't a direct fork of Angrylion, Themaister says the Angrylion code was the central point of reference for developing the plugin,<ref>[https://github.com/Themaister/parallel-rdp#disclaimer README] for parallel-rdp repository on GitHub. § Disclaimer. "While paraLLEl-RDP uses Angrylion-Plus as an implementation reference, it is not a port, and not a derived codebase of said project. It is written from scratch by studying Angrylion-Plus and trying to understand what is going on. The test suite uses Angrylion-Plus as a reference to validate implementation and cross-checking behavior."</ref> meaning ParaLLEl uses the same strategies that Angrylion does to emulate the RDP while running on the host GPU (as long as said GPU supports Vulkan). On the high-level side, gonetz and one or two assistants have spent a large portion of development improving GlideN64's microcode handling of microcode throughout 2016-2018.<ref name="gliden64_blog-1">{{cite web|url=https://gliden64.blogspot.com/2017/|title=Public Release 3.0|publisher=Blogspot|accessdate=2018-06-17|date=2017-12-29}}</ref><ref name="ZSortBOSS">{{cite web|url=https://github.com/gonetz/GLideN64/issues/1685#issuecomment-364436534|title=Initial implementation of BOSS ZSort ucode (WDC, Stunt Racer)|publisher=GitHub|accessdate=2018-06-17|date=2018-02-10}}</ref> This means that [https://youtu.be/HfCOnmRHI0o Factor 5]'s games are now working in the high-level graphics mode].<ref name="Indiegogo">{{cite web|url=https://www.indiegogo.com/projects/indiana-j-infernal-machine-high-level-emulation#/updates/all|title="Indiana J. & Infernal Machine" HLE|publisher=Indiegogo|accessdate=2018-06-17|date=2018-05-17}}</ref><ref name="gliden64_blog-2">{{cite web|url=https://gliden64.blogspot.com/2018/05/hle-implementation-of-microcodes-for.html|title=HLE implementation of microcodes for "Indiana Jones" and "Battle for Naboo" completed.|publisher=Blogspot|accessdate=2018-06-17|date=2018-05-26}}</ref> Other games may still have issues with RDP quirks like frame buffer/depth buffer access (including issues with how the frame buffer framebuffer is used as well as performance issues), VI emulation, and how combine/blending modes are emulated (such as noise issues and combiner accuracy).

Nintendo collaborated with SETA to release an arcade system based on their Nintendo 64 system (kind of like their PlayChoice-10 for the NES, Super System arcade hardware for SNES, and later Triforce for GCN and Wii U). The Nintendo 64-variant with more RAM, the Aleck 64, failed to catch on and bombed. It was never released outside Japan, even though one N64 port made it.

The already available [http://assemblergames.com/l/threads/aleck64-on-retail-consoles-poc.55041/ patches] to convert arcade ROM dumps to regular N64 ROM format can be found [http://micro-64.com/database/aleck64.shtml here]. While Mupen64Plus-based emulators can't run these conversions out of the box, Project64 does just fine.