https://emulation.gametechwiki.com/api.php?action=feedcontributions&user=GPDP1&feedformat=atomEmulation General Wiki - User contributions [en]2024-03-29T12:01:53ZUser contributionsMediaWiki 1.32.0https://emulation.gametechwiki.com/index.php?title=Recommended_N64_plugins&diff=58754Recommended N64 plugins2023-07-02T20:18:57Z<p>GPDP1: Replaced all instances of zilmar's RSP with Project64 RSP to reflect the recent renaming of that plugin. Also revamped the Project64 setups section somewhat. Some other minor changes throughout.</p>
<hr />
<div>The N64 emulation scene had previously been described as a broken mess, the very definition of plugin hell. With recent developments in the scene, however, the situation has markedly improved, and it is no longer considered necessary to have multiple emulators and plugins on hand to get most games to work. This page will outline the best plugins currently available for the benefit of both the casual and enthusiast looking to get their N64 emulation fix.<br />
<br />
==The Plugin Specs==<br />
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.<br />
<br />
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.<br />
<br />
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. Unsurprisingly, this situation often led to a lot of confusion from users, who often wondered why there were so many plugins, and which ones were the best to use, only to find out it often depended on the game, and even then, some games would refuse to work as intended no matter what was tried. Hence the label "plugin hell" was coined, and stuck as a description of the travails of trying to emulate N64 games well into the 2010's.<br />
<br />
However, as time went on, things began to change, though 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.<br />
<br />
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 changes and 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) video plugin there is but was initially only available for the zilmar spec, was ported to Mupen64Plus and integrated into 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.<br />
<br />
All that said, the issue is that there are now three plugin standards to account for:<br />
<br />
*The zilmar spec - Utilized by Project64 and most other legacy emulators; only Project64 still uses it today.*<br />
<br />
*The Mupen64Plus spec - Utilized by Mupen64Plus and most of its forks.<br />
<br />
*Libretro - Not really a spec per se, as the plugins are integrated directly into the libretro core, so there's no DLL files to download or add.<br />
<br />
As of right now, not all plugins are readily available on all three. Consult the tables below for reference:<br />
<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Latest Version<br />
! scope="col"|Project64<br />
! scope="col"|Mupen64Plus<br />
! scope="col"|Libretro<br />
! scope="col"|HLE<br />
! scope="col"|LLE<br />
! scope="col"|Widescreen Hack<br />
! scope="col"|Custom Texture Packs<br />
! scope="col"|Recommended<br />
|-<br />
!colspan="13"|Video Plugins<br />
|-<br />
|ParaLLEl-RDP<br />
|[https://github.com/Themaister/parallel-rdp git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|GLideN64<br />
|[https://github.com/gonetz/GLideN64/releases/tag/github-actions github-actions]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Angrylion RDP Plus<br />
|[https://github.com/ata4/angrylion-rdp-plus/releases/tag/nightly-build Nightly builds]<br/>[https://github.com/ata4/angrylion-rdp-plus/releases/tag/v1.6 1.6]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|Glide64**<br />
|Final<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|Jabo's Direct3D8<br />
|1.7.0.57-ver5<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Rice Video<br />
|0.4.4<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|glN64<br />
|0.4.1<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|z64gl<br />
|R17<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Angrylion (Official)<br />
|r114<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|}<br />
<br />
<nowiki>*</nowiki>It should be noted that Project64 after version 2.x made some changes to the zilmar plugin spec, and while it remains backwards compatible with the older version of the spec (meaning most older plugins will still work with Project64), plugins targeting the newer version will not work on older versions of Project64 or other zilmar spec-based emulators.<br />
<br />
<nowiki>**</nowiki>Funnily enough, Glide64 actually DOES have LLE code (much of it apparently comes from z64gl) and can technically run in LLE mode by using it alongside an LLE RSP plugin such as CXD4. However, it is not a complete implementation, and actually trying to run it in such a mode results in massive visual glitches, making it unusable. Practically speaking, then, Glide64 cannot be considered a true LLE plugin, and will not be designated as such, nor was it ever meant to be.<br />
<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Latest Version<br />
! scope="col"|Project64<br />
! scope="col"|Mupen64Plus<br />
! scope="col"|Libretro<br />
! scope="col"|HLE Compatible*<br />
! scope="col"|LLE Compatible*<br />
! scope="col"|Recommended<br />
|-<br />
!colspan="13"|RSP Plugins<br />
|-<br />
|Project64 RSP<br />
|1.7<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Mupen64Plus HLE RSP<br />
|[https://github.com/mupen64plus/mupen64plus-rsp-hle git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|Static Interpreter/CXD4<br />
|[https://github.com/cxd4/rsp git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|ParaLLEl-RSP<br />
|[https://github.com/Themaister/parallel-rsp git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Mupen64 HLE RSP<br />
|0.5.1<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|z64<br />
|r17<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|}<br />
<br />
<nowiki>*</nowiki>These terms signify whether an RSP plugin can work alongside HLE and/or LLE audio and video plugins. As for the type of emulation employed by the RSP plugins themselves, all but the Mupen64/plus HLE RSP plugins are LLE in nature. The LLE RSP plugins that can work with HLE plugins do so by passing the N64 display and audio lists onto the plugins themselves.<br />
<br />
==Video==<br />
===Currently Recommended Plugins===<br />
The following are the current best video plugins for use on modern PCs and devices.<br />
[[File:SuperMario64-Comparison.png|thumb|right|Jabo's Direct3D8 (left) compared with angrylion's RDP with OpenGL (right), while playing ''Super Mario 64''.]]<br />
====[https://github.com/Themaister/parallel-rdp ParaLLEl-RDP]====<br />
An LLE video plugin inspired by and referenced against Angrylion's RDP plugin, 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 several forks of Mupen64Plus and Project64, such as [[simple64]] and [https://www.64dd.org/downloads.html this build] of Project64. This is currently considered the best video plugin by most measures. It is almost 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 can also render at a high resolution and downsample back down to a lower one, should one wish to improve the 3D graphics without making them stick out from the often low-res 2D elements. Due to its LLE nature, it does not support widescreen hacks or high-res textures - try GLideN64 if you seek to use such features.<br />
<br />
System requirements for ParaLLEl-RDP are higher than for the other plugins. It requires a GPU with Vulkan support and up-to-date drivers (most Nvidia and AMD GPUs made after 2012 should be covered, though Intel graphics requires Skylake or newer), and upscaling increases the GPU requirements even further, far more than GLideN64. It must also be used in conjunction with an LLE RSP plugin, preferably its sister plugin ParaLLEl-RSP, as it features a recompiler for added speed. At native resolution, however, a modest PC with Vulkan support can handle it without much issue, even on integrated graphics.<br />
<br />
====[https://github.com/gonetz/GLideN64/ GLideN64]====<br />
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 z64gl and, to a lesser extent, angrylion). It is included with the latest versions of Project64, the Mupen64Plus-Next libretro core, and [https://github.com/simple64/simple64/releases/tag/v2021.5.30 older versions of simple64]. This is the best HLE plugin by far. The plugin currently supports mip-mapping, emulation of low-level triangles, microcode emulation of every game, gamma correction, flat and prim shading, VI emulation, and LLE graphics support. 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]], MSAA 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]].<br />
<br />
GLideN64 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.<br />
<br />
====[https://github.com/ata4/angrylion-rdp-plus/releases Angrylion RDP Plus]====<br />
This is a fork of Angrylion's RDP that supports multithreading. It 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, as does using it alongside an RSP plugin with a recompiler such as ParaLLEl-RSP, but some games are still not full speed even on a Core i7-8700K. It also allows you to disable VI filters for slightly better performance. This fork has at least one accuracy regression compared to the official version of Angrylion. 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.<br />
<br />
====Glide64====<br />
The former best general-use plugin. Versions of this are included in Project64, mainline Mupen64Plus, and the ParaLLEl-N64 libretro core. While it is no longer updated and is far less accurate and compatible than the newer offerings, it still has a few use cases, such as better support for older ROM hacks. It works relatively well for many (most?) games, has support for hi-res textures, and it is also faster than the newer plugins, which makes it suitable for slower devices such as the older Raspberry Pis. Otherwise, to ensure the highest possible compatibility, stick to either ParaLLEl-RDP or GLideN64.<br />
<br />
Note that the Project64 version of Glide64 has been renamed to Project64 Video and has undergone some changes and rewrites since it was initially forked, and thus may contain regressions compared to the last official standalone release of the plugin by Gonetz. Since this fork only works with current versions of Project64, should you wish to use this plugin on an older zilmar-spec emulator like 1964 or the original Mupen64, or if you want to avoid potential regressions with the Project64 version, use [https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/glidehqplusglitch64/Glide64_Final.zip Glide64 Final] instead.<br />
<br />
===Deprecated Plugins===<br />
The following video plugins are old and deprecated, and should not be used or considered unless you have a VERY old or underpowered device that cannot handle the recommended plugins, or there's a very specific use case not covered by modern implementations.<br />
<br />
*Jabo's Direct3D8 - Comes with Project64, and was once its default video plugin. Very speedy, has built-in AA and AF options, and includes a [[Widescreen_Hack|widescreen hack]]. The version included with the most recent versions of Project64 (1.7.0.57-ver5) is somewhat buggy and has regressions, however. [http://www.jabosoft.com/articles/114 Jabo's 1.6.1 patch] is better, though version 1.7 can run in LLE mode, which can help with a few games. Sadly, it will likely never see another update again, and though it is still included in Project64 to this day, it is no longer the default, and should not be used unless you have a very old PC that cannot handle Glide64 or GLideN64.<br />
*[http://www.emutalk.net/threads/54166-Rice-Video-Community-version Rice Video] - A very fast, highly configurable video plugin primarily based around the Direct3D API. It was once famous for being the first plugin that allowed the user to load [[Texture_Packs|custom hi-res textures]], which made 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, all aiming to fix issues or add features (one fork even featured early shader support), and forks of it are included in mainline Mupen64Plus and in the ParaLLEl-N64 libretro core. However, even during its heyday it lagged behind Glide64 and even Jabo in both compatibility and accuracy, and once Glide64 gained the ability to load custom textures, there remained little reason to use it beyond its speed. A "Community Version" popped up that aimed at improving it and fixing its issues, but it ended up introducing many regressions compared to older versions and the effort was eventually abandoned. 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) or are trying to emulate on a very old and/or severely underpowered PC or handheld device. If you are absolutely resolved to try it out, seek out the original versions by Rice, primarily 6.1.0 or 6.1.1b, and stick to the Direct3D renderer, as the OpenGL backend included in some versions is buggy and incomplete outside of the Mupen64Plus fork.<br />
*[http://www.emutalk.net/threads/40640-Z64-a-LLE-graphics-plugin z64gl] - A hardware-rendered, low-level plugin developed by ziggy, derived from MAME's N64 driver. A fork is maintained by the Mupen64Plus team, though not included in their official releases. It was once notable for being one of the only plugins that could play games without an HLE microcode implementation such as Rogue Squadron. However, it was rather glitchy, had higher system requirements than the HLE plugins, needed an LLE RSP plugin to work (such as the bundled z64 RSP or Project64's RSP plugin set to LLE graphics), and configuration required editing the config file directly. A [https://github.com/purplemarshmallow/z64/tree/angrylion-integration fork] cropped up that aimed at improving it, but it did not get very far. Nowadays, it's obsolete, as GLideN64 can now play every game through HLE (thus subverting z64gl's only selling point), and its LLE has been surpassed by Angrylion-derived plugins and even GLideN64's LLE mode.<br />
*[https://sourceforge.net/p/angrylions-stuff/code/HEAD/tree/ Official Angrylion RDP] - A software-rendered, hardware-accurate plugin, developed by angrylion (though derived from MAME, much like z64gl). This is the most accurate N64 video plugin in existence, emulating almost* every facet of the N64's RDP precisely and thus making it capable of playing almost every single game in the N64 library with no issues, fixing even notorious cases such as the ''Pokémon Snap'' red dot and the ''Body Harvest'' bridge. This, however, comes at the cost of insane CPU requirements while making games look like, well, N64 games running on real hardware, which means native resolution, no widescreen, no hi-res textures - just the N64 in its full, vaseline-covered glory. Since this particular version is single-threaded, uses DirectDraw and is Windows only, it is recommended to use Angrylion RDP Plus or ParaLLEl-RDP instead, which offer much more reasonable performance. Only try it out if you have a tricked-out rig and want to test your CPU's mettle, or if you can compile it from source and need it for testing/debugging purposes, as the latest updates are always made to this version first.<br />
*[http://www.emutalk.net/threads/55481-angrylion-s-Per-Pixel-RDP-with-OpenGL HatCat/angrylion's Pixel-Accurate N64 Plugin] - This is a fork of Angrylion's RDP, done by HatCat. It has some optimizations not present in the official code, but is outdated and lacking some accuracy improvements and optimizations written by Angrylion. It has the option to disable the VI filters (which gives a speed boost), as well as the ability to set custom resolutions. Also, this version uses OpenGL 1.x instead of Direct Draw and supports Linux. Obsoleted by newer forks such as Angrylion RDP Plus.<br />
<br />
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:<br />
<br />
<gallery widths="300" mode="packed"><br />
Mario Tennis Rice.png|Mario Tennis running on ParaLLEl-N64 using Rice. Missing various effects, heavily glitched court.<br />
Mario Tennis Glide64.png|Mario Tennis running on ParaLLEl-N64 using Glide64. Missing various effects and shadows, some glitches.<br />
Mario Tennis glN64.png|Mario Tennis running on ParaLLEl-N64 using glN64. Missing various effects; shadows are present, but glitched.<br />
Mario Tennis GLideN64 HLE.png|Mario Tennis running on Mupen64Plus-Next using GLideN64 in HLE mode with 16xMSAA. Minor text cutoff on bottom of scoreboard.<br />
Mario Tennis GLideN64 LLE.png|Mario Tennis running on Mupen64Plus-Next using GLideN64 in LLE mode with 16xMSAA. Minor text cutoff on bottom of scoreboard. Has slight polygon jitter not present in HLE.<br />
Mario Tennis ParaLLEl 1x.png|Mario Tennis running on Mupen64Plus-Next using ParaLLEl-RDP at native resolution. Identical to Angrylion, and thus a pixel-perfect representation of real hardware.<br />
Mario Tennis ParaLLEl 4x Downsampled.png|Mario Tennis running on Mupen64Plus-Next using ParaLLEl-RDP rendering at 4x resolution, then downsampled back to native resolution.<br />
Mario Tennis ParaLLEl 4x.png|Mario Tennis running on Mupen64Plus-Next using ParaLLEl-RDP rendering at 4x resolution. Has very slight polygon jitter, though less than GLideN64 in LLE.<br />
</gallery><br />
<br />
<nowiki>*</nowiki> There is at least [https://sourceforge.net/p/angrylions-stuff/tickets/10/ one known, relatively minor graphical glitch in Pokemon Snap] (go figure) using Angrylion that requires currently-unimplemented cycle-accurate behavior to fix without resorting to hacks.<br />
<br />
==Audio==<br />
This section will only cover the zilmar spec plugins, as Mupen64Plus does not have any alternative audio plugins besides the default, and neither do the libretro forks.<br />
<br />
*Project64 Audio - The default audio plugin for Project64, apparently loosely based off of code from Mupen64Plus's HLE RSP. Very barebones, with no options to speak off.<br />
*Jabo's DirectSound - Comes with Project64. It works fine for the most part, but some games may not play nice with it. It is a low-level plugin, so it needs an accompanying LLE RSP plugin. Will probably never be updated again.<br />
*[http://www.emutalk.net/threads/27610-Audio-v0-56-WIP2-Download-Feedback Azimer's HLE Audio] - This popular HLE audio plugin boasts high compatibility. Version 0.56WIP2 is old as hell, but it is the tried and true standard to which audio plugins are compared against. Recently, [https://github.com/Azimer/AziAudio Azimer open sourced his plugin], and there were plans to integrate it into Project64, though this has yet to happen. While the latest development versions have a few issues, it now works in LLE, and has integrated code from Mupen64Plus's HLE RSP plugin, allowing it to work with the Factor 5 and BOSS games even in HLE.<br />
*[http://forum.pj64-emu.com/showthread.php?t=3644 Shunyuan's HLE Audio] - An audio plugin, apparently based on 1964Audio and HatCat's RSP plugin. Can run in both LLE and HLE modes despite the name, though the HLE mode just makes it run an outdated, baked-in version of HatCat's RSP, which makes it not a true HLE plugin. Has been abandoned after charges of just taking others' code without revealing a source. If games run at a weird speed using this plugin, go to the ROM's Game Settings, and disable Fixed Audio Timing and Sync using Audio. Though it worked surprisingly well despite its Frankenstein nature, modern development versions of Project64 no longer work with it, apparently due to it depending on a bug that has now been fixed. As such, it is probably better to use Azimer's plugin instead.<br />
<br />
==Input==<br />
*Project64 Input - Comes with Project64 as of the latest versions. Very simple input plugin which looks suspiciously a lot like Jabo's, but at least has XInput support, which is nice.<br />
*[https://sourceforge.net/projects/nragev20/ NRage Input] - Also comes with Project64 as of version 2.2. Hands down the best input plugin as it is more feature complete than Jabo's DirectInput. Has a ton of options and great controller compatibility, including XInput support for use with Xbox 360 controllers. It can't emulate the microphone that is required by ''Hey You, Pikachu'' or the printer required for the ''Pokémon Snap Station''. It has the ability to emulate Controller Pak (''Mario Kart 64'''s ghost saves), Rumble Pak (''Star Fox 64''), and Transfer Pak (''Pokémon Stadium'' series) functionality fairly well. Version 2.3 of Project64 introduced a version of the plug-in that can emulate the N64's mouse accessory designed for the 64DD to coincide with Project64's newest ability to emulate the 64DD accessory. Surprisingly, ''Mario Artist: Paint Studio'' can use the Japanese ''Game Boy Camera'' (called ''Pocket Camera'') in Transfer Pak mode, but the camera function doesn't work as it displays static, although importing captured images still works technically.<br />
*Jabo's DirectInput - Used to come with Project64, but now removed in favor of NRage Input. It isn't too bad, 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 usual, do not expect any updates.<br />
*[https://www.raphnet-tech.com/products/raphnetraw/index.php/ Raphnetraw] - This open source plugin allows streamlined use of N64 controller(s) via raphnet [https://www.raphnet-tech.com/products/n64_usb_adapter_gen3/index.php N64-to-USB v3+ adapters]. It supports rumble and is available for Project64 and mupen64plus. Also contains various DLLs for special port arrangements [https://www.raphnet.net/programmation/mupen64plus-input-raphnetraw/index_en.php#4 (link)].<br />
<br />
==RSP==<br />
===Recommended Plugins===<br />
*Project64 RSP - Comes with Project64, and until recently was usually known simply as zilmar's RSP. Reasonably accurate, quite fast in Recompiler mode (enabled by default), and will work fine for the 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.<br />
*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. 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 work with Jabo's, as that is a pure LLE audio plugin and requires LLE RSP emulation.<br />
*[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 one of the most accurate RSP plugins, though Project64 RSP in Recompiler mode as well as ParaLLEl-RSP both trump it in speed. It can take advantage of SSSE3 for greater performance, though it also comes in SSE2 and non-SSE variations in case your PC does not support those instruction sets. In both the zilmar and Mupen64Plus versions (though not in libretro, it seems), it is capable of working with both HLE and LLE audio and video plugins via the following settings:<br />
**Simulate RSP graphics from external plugin - Check if using an HLE graphics plugin, uncheck if using LLE<br />
**Simulate RSP audio from external plugin - Check if using an HLE audio plugin, uncheck if using LLE<br />
**Force semaphore locking - Check to fix issues with Mario no Photopie. Only works with Project64 2.x and beyond.<br />
*ParaLLEl-RSP - A fast and accurate RSP written by [https://github.com/Themaister/parallel-rsp Themaister], though it borrows heavily from both CXD4 and CEN64's RSP code. It is about as accurate and compatible as the Static Interpreter/CXD4 RSP, while being much faster owing to its inclusion of a dynamic recompiler. 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 [[simple64]] and [[RMG]], and now even Project64 as a plugin ([https://64dd.org/downloads.html this version] comes bundled with it). Note that it only works with LLE video and audio plugins, though it is highly recommended if using such.<br />
<br />
===Deprecated Plugins===<br />
*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 and many other compatibility fixes were later added to the Mupen64Plus version, which has now been ported to the zilmar spec after years of exclusivity on the Mupen64Plus side of things. As such, this version is officially obsolete.<br />
*z64 RSP plugin pack - Largely deprecated by the Static Interpreter/CXD4 RSP plugin. This set of RSP plugins comes with the z64 video plugin, each with their own purpose:<br />
**Ziggy-z64RSP - This RSP is based on the MAME/MESS RSP code. It is slower but more accurate.<br />
**Ziggy-PJ64 - Based on the Project64 1.4 RSP, this plugin is much faster.<br />
**angrylion - This RSP is a simple Interpreter, and is required for a few games like World Driver Championship to work correctly with z64gl.<br />
<br />
==Recommended N64 Setups==<br />
<br />
===Overview===<br />
While in general only a small handful of plugins are necessary to play the vast majority of N64 games these days, there are nevertheless a variety of use cases which may necessitate using some plugins in specific combinations over others. The following section will be divided primarily by plugin specs, then further subdivided by the following use case "profiles":<br />
*General Use - A profile that strikes a good balance of speed, accuracy and compatibility. Most games will be playable on average hardware and should run with few to no issues.<br />
*Performance - Focuses primarily on speed for lower-end devices that cannot handle the General Use profile. Many games will be playable, but expect lower overall compatibility, glitches and missing effects.<br />
*Accuracy - Attains the maximum compatibility and accuracy made possible by the emulator. Almost all games will be playable and look as intended, but requires much higher system specifications.<br />
As a rule of thumb, start with the General Use profile. If it's too slow, move down to the Performance profile. Conversely, if there's a problem with the game (or you just want to be as close to real hardware as possible), move up to the Accuracy profile. It should be said there may be configurations within the emulator or plugin settings that may help with speed or compatibility, but it is generally not recommended to mess with them unless you know what you're doing, as both emulators and plugins are usually already optimized on a per-game basis, so moving settings around could result in breaking things. Should you wish to try to eke out more performance out of a given profile, it may be wise to consult with the emulator/plugin developers or communities centered around N64 emulation first.<br />
<br />
===Project64 and Others===<br />
Project64 comes bundled with the following plugins:<br />
*Video: Jabo's Direct3D8, Project64 Video (Glide64 under another name), GLideN64<br />
*Audio: Jabo's DirectSound, Project64 Audio<br />
*Input: NRage for Project64, Project64 Input<br />
*RSP: Project64 RSP<br />
Should you wish to use other plugins, they must be downloaded from a third party source and dropped into their respective plugin folder categories in the Project64 directory. Video plugins go under Plugin/GFX, audio plugins under Plugin/Audio, etc.<br />
<br />
*'''General Use'''<br />
**GLideN64<br />
**Azimer's Audio NEW (set to LLE)<br />
**Project64 RSP<br />
**For the majority of games, the default Project64 RSP will work just fine, at least in HLE mode. Should you wish to use GLideN64 in LLE mode (or any LLE video plugin for that matter) with the Project64 RSP, simply uncheck "Graphics HLE" in the Plugin configuration screen. Alternatively, use ParaLLEl-RSP, though that only works in LLE, so GLideN64's HLE mode will be unavailable with that plugin.<br />
*'''Performance'''<br />
**Project64 Video or Glide64 Final<br />
**Azimer's HLE Audio<br />
**Project64 RSP or Mupen64Plus HLE RSP<br />
**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. Recommended for the older zilmar-spec emulators as well (replace Project64 Video with Glide64 Final for those, though you may want to do that even with Project64 should you run into a regression). 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.<br />
*'''Accuracy'''<br />
**Angrylion RDP Plus<br />
**Azimer's Audio NEW<br />
**Static RSP Interpreter<br />
**If you have a decent quad-core CPU, you can run many N64 games with pixel-perfect graphics at full speed, thanks to the new multithreaded version of angrylion's software plugin. The new Azimer's plugin (still WIP) works well in LLE. To use the Static Interpreter RSP in LLE, you'll have to run the spconfig.exe that comes with that plugin, and tell it to NOT "simulate RSP graphics from external plugin" (in other words, type "0"). Since there's almost no accuracy difference, you may as well use ParaLLEl-RSP to get better performance, and/or move to ParaLLEl-RDP outright for even greater speed and upscaling options to boot (though it goes without saying upscaling would no longer be accurate). Conversely, if you want even greater accuracy, disable "Hide advanced settings" under Configuration, then enable "Always use interpreter core" under Advanced, and under Angrylion's options, disable multi-threading and set compatibility to "Slow". Performance WILL crash, but hey, it'll be accurate!<br />
<br />
===Mupen64Plus===<br />
The official releases of Mupen64Plus only come bundled with a handful of video and RSP plugins, namely Glide64mk2, Rice, and the HLE RSP. The developers also maintain forks of the CXD4 RSP and the z64 video and RSP plugins, but they are not included in the official release bundles for some reason. Should you wish to use those plugins or third party ones such as GLideN64 or the ParaLLEl plugins, you must build them yourself or get them from outside sources. Due to this fact, the mediocre nature of the "official" video plugins, and the overall lack of user-friendliness, it may be better to use a fork such as [[simple64]] or [[RMG]], though note that simple64 only comes and works with the ParaLLEl plugins, so RMG is a better choice if you wish to use something else, as that comes with more plugins and allows you to use whichever ones you want.<br />
*'''General Use'''<br />
**Video: GLideN64 or ParaLLEl-RDP<br />
**RSP: RSP-HLE (for GLideN64) or ParaLLEl-RSP (for ParaLLEl-RDP)<br />
**Either one of these combinations will enable you to play the vast majority of N64 games while having reasonable system requirements. GLideN64 is faster and has more enhancement options, but ParaLLEl-RDP is much more accurate to the real console. You can also use the CXD4 RSP with GLideN64 if you want, but be sure to set it to pass display lists to the graphics plugin in mupen64plus.cfg, else GLideN64 will switch to its LLE mode, which is not generally recommended to use.<br />
*'''Performance'''<br />
**Video: Glide64mk2<br />
**RSP: RSP-HLE<br />
**These are Mupen64Plus's default plugins. Glide64mk2 is based on Glide64 Final, and is named so as to differentiate it from the original, now obsolete fork of Glide64 that Mupen64Plus used at its inception. It is not up to GLideN64's level, but it does well enough for many games and is quite fast. Use this combination if you have a lower end PC that can't handle the General Use setup. If your device STILL can't handle this setup, try the Rice video plugin, but expect many missing effects, glitches and incompatibilities.<br />
*'''Accuracy'''<br />
**Video: Angrylion Plus or ParaLLEl-RDP<br />
**RSP: CXD4-ssse3 or ParaLLEl-RSP<br />
**Any combination of these should result in very high accuracy. Technically, the most accurate setup is Angrylion combined with CXD4, but the difference between these and the ParaLLEl plugins is almost negligible, while being a lot slower. Be sure to set the CPU core to Pure Interpreter for even greater accuracy, along with plummeting framerates.<br />
<br />
Note: In some cases the cfg file may not appear, in which case you may do this:<br />
*Open terminal in emulator folder on in its respective directory<br />
*''mupen64plus --configdir'' /directory/where/you/want/it/to/be<br />
<br />
===Libretro===<br />
There are two N64 libretro emulator cores for use on libretro frontends such as [[RetroArch]]: Mupen64Plus-Next and ParaLLEl-N64. The former is mostly up-to-date and is recommended for most use cases, while the latter is no longer updated and is only around for performance reasons. They also have access to the following plugins:<br />
*Shared by both cores<br />
**Video: ParaLLEl-RDP , Angrylion<br />
**RSP: ParaLLEl-RSP, HLE, CXD4<br />
*Exclusive to Mupen64Plus-Next<br />
**GLideN64<br />
*Exclusive to ParaLLEl-N64<br />
**glN64, Rice, Glide64<br />
Due to these differences, it is advisable to use Mupen64Plus-Next for general use, and ParaLLEl-N64 for performance.<br />
*'''General Use (LLE)'''<br />
**Core: Mupen64Plus-Next<br />
**Video: ParaLLEl-RDP<br />
**RSP: ParaLLEl-RSP<br />
**By default ParaLLEl-RDP will output at native resolution with all the VI filters on, making it look exactly like Angrylion and the real N64 console. Upscaling must therefore be enabled in the core options. You can also alternatively render at a high resolution and downsample to a lower one if you want to improve 3D without making it stick out from 2D elements too much.<br />
*'''General Use (HLE)'''<br />
**Core: Mupen64Plus-Next<br />
**Video: GLideN64<br />
**RSP: HLE<br />
**While GLideN64 also works with the ParaLLEl and CXD4 RSP plugins, using them will cause GLideN64 to switch to its LLE mode, which is currently glitchier and slower than the HLE mode, for few (if any) compatibility or accuracy benefits. As such, it is recommended to stick with the HLE RSP for GLideN64.<br />
*'''Performance'''<br />
**Core: ParaLLEl-N64<br />
**Video: Glide64<br />
**RSP: HLE<br />
**For slow, low-end devices and old PCs only. If further speed is desired or needed, you may try glN64 or Rice, but using them comes at a steep cost in compatibility and accuracy, and many low-end devices in use today ought to be able to handle Glide64 just fine (well, with the exception of certain underpowered "retro gaming" handhelds).<br />
*'''Accuracy'''<br />
**Core: Mupen64Plus-Next<br />
**Video: Angrylion<br />
**RSP: CXD4<br />
**Just like the developers intended! If you want to go all out, set the CPU core to Pure Interpreter, turn off multi-threading and set thread sync level to High in Angrylion's options for the real 30 VI/s experience. Closest you'll get to real hardware until a complete cycle-accurate N64 emulator surfaces.<br />
<br />
[[Category:Recommendations]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Talk:Nintendo_64_emulators&diff=52619Talk:Nintendo 64 emulators2023-01-27T14:42:15Z<p>GPDP1: /* Comparison table is getting crowded */</p>
<hr />
<div>>Its developers have expressed intentions to eventually rewrite the core and brand it as its own emulator, called ParaLLEl.<br />
<br />
Hey, it looks like ParaLLEl is already available in Retroarch. I don't know how good it is exactly as I've only tried Paper Mario so far, but there's no flickering in it as mentioned on the mupen64 comparability wiki. -Anon<br />
<br />
== Graphics comparison table ==<br />
<br />
The main page of the N64 emus is too large probably, so I put this here as a backup source. I've already added it to the Resources sector at three other pages (for 3 comparable systems). [[User:ObiKKa|ObiKKa]] ([[User talk:ObiKKa|talk]]) 18:17, 28 April 2019 (EDT)<br />
<br />
* [https://segaretro.org/Sega_Saturn/Hardware_comparison#Graphics_comparison_table Graphics comparison table] (for Saturn as opposed to PS1, N64, Sega Model 2 arcade hardware and 1995-era PC)<br />
<br />
== What's Depth output? ==<br />
<br />
LLE emulators would support it. If GlideN64 calls that "Use emulator help to read/write frame buffers" option, I think Project64 is not supported.<br />
<br />
I was wondering about this as well. Does it refer perhaps to the N64-style depth compare option in GLideN64? Because Mupen64Plus-Next has that option, unless it's not working for some reason.<br />
<br />
== Ares recommended? ==<br />
<br />
This is just my opinion, but while ares has certainly made strides for such a new emulator, I'm not sure it's good enough to flat-out recommend over even Project64. Its compatibility is still the lowest among the currently-active emulators, and it has serious problems with several high-profile games, such as DK64.<br />
<br />
On that note, perhaps simple64 should be moved back up to recommended. It does have some regressions, but its compatibility is still quite high, and it does fix some issues present in regular Mupen64Plus.<br />
<br />
== Comparison table is getting crowded ==<br />
<br />
There are a huge amount of columns in it, and I think it's getting harder to read and process everything. Compiling every single feature in a single place may not be the best idea, especially if we're talking about features only a few emulators support or even plan on supporting. This also applies to other pages but this one illustrates this problem the most, for me. I think we should bring back separate tables in dedicated sections, and keep general features in the main table. [[User:FulguroBoy|FulguroBoy]] ([[User talk:FulguroBoy|talk]]) 13:21, 27 January 2023 (UTC)<br />
<br />
I respectfully disagree with you about that. Actually I think separating tables/divs in dedicated sections = "it's getting harder to read and process everything." [[User:Ahayri|Ahayri]] ([[User talk:Ahayri|talk]])<br />
<br />
Well, while we're on the subject, I think it makes sense to remove the "libretro" column - it only applies to ParaLLEl-N64 and Mupen64Plus-Next, for which it's already pointed out they're libretro cores, and technically MAME, which nobody in their right mind uses for N64, let alone on the libretro core. [[User:GPDP1|GPDP1]] ([[User:GPDP1|talk]])</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Talk:Nintendo_64_emulators&diff=52618Talk:Nintendo 64 emulators2023-01-27T14:41:33Z<p>GPDP1: /* Comparison table is getting crowded */</p>
<hr />
<div>>Its developers have expressed intentions to eventually rewrite the core and brand it as its own emulator, called ParaLLEl.<br />
<br />
Hey, it looks like ParaLLEl is already available in Retroarch. I don't know how good it is exactly as I've only tried Paper Mario so far, but there's no flickering in it as mentioned on the mupen64 comparability wiki. -Anon<br />
<br />
== Graphics comparison table ==<br />
<br />
The main page of the N64 emus is too large probably, so I put this here as a backup source. I've already added it to the Resources sector at three other pages (for 3 comparable systems). [[User:ObiKKa|ObiKKa]] ([[User talk:ObiKKa|talk]]) 18:17, 28 April 2019 (EDT)<br />
<br />
* [https://segaretro.org/Sega_Saturn/Hardware_comparison#Graphics_comparison_table Graphics comparison table] (for Saturn as opposed to PS1, N64, Sega Model 2 arcade hardware and 1995-era PC)<br />
<br />
== What's Depth output? ==<br />
<br />
LLE emulators would support it. If GlideN64 calls that "Use emulator help to read/write frame buffers" option, I think Project64 is not supported.<br />
<br />
I was wondering about this as well. Does it refer perhaps to the N64-style depth compare option in GLideN64? Because Mupen64Plus-Next has that option, unless it's not working for some reason.<br />
<br />
== Ares recommended? ==<br />
<br />
This is just my opinion, but while ares has certainly made strides for such a new emulator, I'm not sure it's good enough to flat-out recommend over even Project64. Its compatibility is still the lowest among the currently-active emulators, and it has serious problems with several high-profile games, such as DK64.<br />
<br />
On that note, perhaps simple64 should be moved back up to recommended. It does have some regressions, but its compatibility is still quite high, and it does fix some issues present in regular Mupen64Plus.<br />
<br />
== Comparison table is getting crowded ==<br />
<br />
There are a huge amount of columns in it, and I think it's getting harder to read and process everything. Compiling every single feature in a single place may not be the best idea, especially if we're talking about features only a few emulators support or even plan on supporting. This also applies to other pages but this one illustrates this problem the most, for me. I think we should bring back separate tables in dedicated sections, and keep general features in the main table. [[User:FulguroBoy|FulguroBoy]] ([[User talk:FulguroBoy|talk]]) 13:21, 27 January 2023 (UTC)<br />
<br />
I respectfully disagree with you about that. Actually I think separating tables/divs in dedicated sections = "it's getting harder to read and process everything." [[User:Ahayri|Ahayri]] ([[User talk:Ahayri|talk]])<br />
<br />
Well, while we're on the subject, I think it makes sense to remove the "libretro" column - it only applies to ParaLLEl-N64 and Mupen64Plus-Next, for which it's already pointed out they're libretro cores, and technically MAME, which nobody in their right mind uses the last one for N64, let alone on the libretro core. [[User:GPDP1|GPDP1]] ([[User:GPDP1|talk]])</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Ares&diff=52505Ares2023-01-25T05:11:36Z<p>GPDP1: Clarification on ares's N64 RDP emulation</p>
<hr />
<div>{{lowercase title}}<br />
{{Infobox emulator<br />
|title = ares<br />
|logo = ares-logo.png<br />
|screenshot = Ares_Screenshot.PNG<br />
|logowidth = 230<br />
|developer = Near <small>(formerly known as byuu)</small>, LukeUsher<br />
|version = {{Version|ares}}<br />
|active = Yes<br />
|platform = [[Emulators on Windows|Windows]]<br/>[[Emulators on Linux|Linux]]<br/>[[Emulators on macOS|macOS]]<br />
|architecture = x64<br />
|target = [[Atari 2600 emulators|Atari 2600]]</br>[[Nintendo Entertainment System emulators|NES]]</br>[[Super Nintendo emulators|SNES]]</br>[[Nintendo 64 emulators|Nintendo 64]]</br>[[Game Boy/Game Boy Color emulators|Game Boy/Color]]</br>[[Game Boy Advance emulators|Game Boy Advance]]</br>[[WonderSwan emulators|WonderSwan]]</br>[[SG-1000 emulators|Sega SG-1000]]</br>[[Master System emulators|Sega Master System/Game Gear]]</br>[[Sega Genesis emulators|Sega Genesis/Mega Drive]]</br>[[PlayStation emulators|Sony PlayStation]]</br>[[PC Engine (TurboGrafx-16) emulators|PC Engine/TurboGrafx-16]]</br>[[Neo Geo and variants|Neo Geo AES]]</br>[[Neo Geo Pocket emulators|Neo Geo Pocket/Color]]</br>[[MSX emulators|MSX]]</br>[[ColecoVision emulators|ColecoVision]]</br>Pocket Challenge V2<br />
|website = [https://ares-emu.net ares-emu.net]<br />
|license = Internet Systems Consortium (ISC) license<br />
|source = [https://github.com/ares-emulator/ares GitHub]<br />
}}<br />
<br />
'''ares''' is a free and open-source, [[Multi-system_emulators|multi-system emulator]]. It is a descendent of [[higan]] and [[bsnes]], and focuses on accuracy and preservation.<br />
<br />
==Download==<br />
{| cellpadding="4"<br />
|-<br />
|align=center|{{Icon|Win-big|Mac-big}}<br />
|'''[https://github.com/ares-emulator/ares/releases Official releases]'''<br />
|-<br />
|colspan="3"|<hr/><br />
|-<br />
|align=center|{{Icon|Lin-big}}<br />
|'''[https://flathub.org/apps/details/dev.ares.ares Flatpak]'''<br/>'''[https://aur.archlinux.org/packages/ares-emu/ ArchLinux AUR]'''<br />
|}<br />
<br />
==Overview==<br />
ares began development as bsnes on October 14th, 2004. It is available under the Internet Systems Consortium (ISC) license, which is a permissive license that is functionally similar to the BSD and MIT licenses. It used to be under the terms of the Creative Commons (CC) BY-NC-ND 4.0 license, which it made the ares emulator a non-commercial software that does not permit publishing modifications (forks) online. The reason for this was to prevent splintering development between higan and ares.<br />
<br />
Most cores in ares are original and were started when the project was run by Near, although its Nintendo 64 core's graphics emulation is based on Themaister's ParaLLEl-RDP Vulkan renderer as well as MAME's software renderer, and an original Atari 2600 core was added later. Its most useful cores are the ones that have been in development the longest or that have few competing options. Its SNES emulation is derived from that of the original [[bsnes]] project and is the most accurate one around. Its WonderSwan and Neo Geo Pocket emulation are also the most complete and accurate, with the highest compatibility available (100% in the case of the WonderSwan). The 32x emulation has 95% compatibility with commercial games and is by far the best option for that system.<br />
<br />
Other cores are less useful, with known incompatibilities and other emulators available that are both faster and more accurate. The GBA emulation was derived from work done in bsnes for the ST018 coprocessor and is highly accurate, but is slower and less accurate than [[mGBA]]. The Genesis emulation lacks the 100% compatibility with commercial games claimed by other emulators. Its Atari 2600 emulation is well behind [[Stella]] and [[MAME]].<br />
<br />
==Features==<br />
*Native multi-platform UI<br />
*Adaptive sync<br />
*Dynamic rate control<br />
*Save states<br />
*Run-ahead<br />
*Rewind and fast-forward<br />
*Pixel shaders<br />
*Color correction<br />
*6th-order IIR audio filtering<br />
*Input multi-mapping<br />
*Built-in games database<br />
*Debugger<br />
<br />
[[Category:Emulators]]<br />
[[Category:Multi-emulators]]<br />
[[Category:Console emulators]]<br />
[[Category:Home console emulators]]<br />
[[Category:Handheld console emulators]]<br />
[[Category:Computer emulators]]<br />
[[Category:Nintendo Entertainment System emulators]]<br />
[[Category:Super Nintendo emulators]]<br />
[[Category:Nintendo 64 emulators]]<br />
[[Category:Game Boy/Game Boy Color emulators]]<br />
[[Category:Game Boy Advance emulators]]<br />
[[Category:WonderSwan emulators]]<br />
[[Category:SG-1000 emulators]]<br />
[[Category:Master System emulators]]<br />
[[Category:Sega Genesis emulators]]<br />
[[Category:PlayStation emulators]]<br />
[[Category:PC Engine (TurboGrafx-16) emulators]]<br />
[[Category:Neo Geo Pocket/Neo Geo Pocket Color emulators]]<br />
[[Category:MSX emulators]]<br />
[[Category:Windows emulation software]]<br />
[[Category:Linux emulation software]]<br />
[[Category:macOS emulation software]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Talk:Nintendo_64_emulators&diff=51465Talk:Nintendo 64 emulators2022-12-20T00:11:27Z<p>GPDP1: /* Ares recommended? */ new section</p>
<hr />
<div>>Its developers have expressed intentions to eventually rewrite the core and brand it as its own emulator, called ParaLLEl.<br />
<br />
Hey, it looks like ParaLLEl is already available in Retroarch. I don't know how good it is exactly as I've only tried Paper Mario so far, but there's no flickering in it as mentioned on the mupen64 comparability wiki. -Anon<br />
<br />
== Graphics comparison table ==<br />
<br />
The main page of the N64 emus is too large probably, so I put this here as a backup source. I've already added it to the Resources sector at three other pages (for 3 comparable systems). [[User:ObiKKa|ObiKKa]] ([[User talk:ObiKKa|talk]]) 18:17, 28 April 2019 (EDT)<br />
<br />
* [https://segaretro.org/Sega_Saturn/Hardware_comparison#Graphics_comparison_table Graphics comparison table] (for Saturn as opposed to PS1, N64, Sega Model 2 arcade hardware and 1995-era PC)<br />
<br />
== What's Depth output? ==<br />
<br />
LLE emulators would support it. If GlideN64 calls that "Use emulator help to read/write frame buffers" option, I think Project64 is not supported.<br />
<br />
I was wondering about this as well. Does it refer perhaps to the N64-style depth compare option in GLideN64? Because Mupen64Plus-Next has that option, unless it's not working for some reason.<br />
<br />
== Ares recommended? ==<br />
<br />
This is just my opinion, but while ares has certainly made strides for such a new emulator, I'm not sure it's good enough to flat-out recommend over even Project64. Its compatibility is still the lowest among the currently-active emulators, and it has serious problems with several high-profile games, such as DK64.<br />
<br />
On that note, perhaps simple64 should be moved back up to recommended. It does have some regressions, but its compatibility is still quite high, and it does fix some issues present in regular Mupen64Plus.</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Simple64&diff=51404Simple642022-12-13T17:53:20Z<p>GPDP1: Added a note on simple64's slower performance</p>
<hr />
<div>{{lowercase title}}<br />
{{Infobox emulator<br />
|title = simple64<br />
|logo = <br />
|logowidth = <br />
|screenshot = M64p-screenshot.png<br />
|screenshotcaption = The simple64 frontend on Windows 7.<br />
|developer = [https://github.com/loganmc10 loganmc10]<br />
|version = {{Version|simple64}}<br />
|active = Yes<br />
|platform = [[Emulators on Windows|Windows]]<br/>[[Emulators on Linux|Linux]]<br />
|architecture = x64<br />
|target = [[Nintendo 64 emulators|Nintendo 64]]<br />
|compatibility = High<br />
|accuracy = <br />
|website = [https://simple64.github.io/ simple64.github.io]<br />
|prog-lang = C, C++<br />
|support = [https://www.patreon.com/loganmc10 Patreon]<br />
|license = GNU GPLv3<br />
|source = [https://github.com/simple64/simple64 GitHub]<br />
}}<br />
'''simple64''', formerly known as m64p, is an open-source, plugin-based [[Nintendo 64 emulators|Nintendo 64 emulator]] maintained by loganmc10. The project bundles [[Mupen64Plus]] with Parallel RDP, as well as its own frontend, input plugin, and netplay support.<br />
<br />
==Download==<br />
{| cellpadding="4"<br />
|-<br />
|align=center|{{Icon|Win-big|Lin-big}}<br />
|[https://github.com/simple64/simple64/releases '''Official releases''']<br />
|-<br />
|align=center|{{Icon|Win|Lin|Mac}}<br />
|[https://github.com/thekovic/simple64/releases/tag/v2021.5.30 Final GLideN64 build (2021-05-30)]<br />
|-<br />
|colspan="3"|<hr/><br />
|-<br />
|align=center|{{Icon|Win|Lin|Mac}}<br />
|[https://github.com/simple64/simple64-gui simple64-gui]<br><small>The frontend that can also be used separately with Mupen64Plus.</small><br />
|}<br />
==System requirements==<br />
* OS: Windows 10 or Linux <br />
* CPU: Requires AVX2 instructions support. (Intel 4th generation(Haswell) or AMD Zen(Ryzen))<br />
* GPU: Requires Vulkan 1.1 support. (Graphic card after 2010)<br />
<br />
==Overview==<br />
In the project's own words:<br />
<blockquote>''"This is likely the most compatible N64 emulator you’re going to come across. It can play games like Resident Evil 2, Rogue Squadron, Pokemon Snap, and World Driver Championship “out-of-the-box” (without the need to fiddle with settings, plugins, or anything of the sort)."''</blockquote><br />
<br />
The user interface, simple64-gui, was written specifically for simple64 using Qt5 prior to version 2022.07, and using Qt6 from version 2022.07 onward. The supported features:<br />
<br />
* Netplay using a central server hosted in the cloud for players to find sessions<br />
* Discord Rich Presence and automatic voice channel connectivity<br />
* Standard frontend features like pausing, screenshots, save states etc.<br />
* An auto-updater<br />
<br />
Parallel RDP and RSP are based on the work of [https://github.com/Themaister/parallel-rsp Themaister] and are used in the [https://www.libretro.com/index.php/parallel-n64-with-parallel-rsp-dynarec-release-fast-and-accurate-n64-emulation/ Parallel N64 Libretro core]. This makes fast and accurate N64 emulation possible in simple64.<br />
<br />
As of April 12 2021, simple64 no longer runs properly on macOS systems. The application produces an "unable to load video plugin" error and random application crash at startup. As of June 6th 2021, it appears that support for macOS is being completely dropped by loganmc10 with the replacement of both the GlideN64 and Angrylion Plus RDPs with ParaLLEl-RDP and the release of Windows and Linux builds only, as macOS lacks the necessary Vulkan support for ParaLLEl-RDP to work, requiring additional Mac-specific work to make it function. However, as of September 20, 2022, simple64 now uses the "latest version" of ParaLLEl-RDP, which the author claims "should be a step closer to Mac support".<br />
<br />
As of Jul 17, 2022, simple64 has undergone a major overhaul of its core timing code independently of upstream [[Mupen64Plus]], getting rid of the CountPerOp setting and removing all game-specific hacks, thus bringing it more in line with [[Ares]] and [[CEN64]] in accuracy. However, this has resulted in some regressions and compatibility issues, including some games not booting that used to work before. Another side effect of simple64's increased accuracy is slower performance, compounded by the fact that the emulator no longer includes a dynarec core, so older PCs may have problems running some games at full speed (disabling Synchronous RDP in the settings can help, though some games require it to work correctly). Work is ongoing and regressions are being fixed as they appear, but until this task is completed, consult this [https://github.com/simple64/simple64/issues/288 "known issues" list] before using the latest release. If a game you'd like to play is currently listed as having problems or you run into an issue not on that list, try a build from before the major timing changes (such as [https://github.com/simple64/simple64/releases/tag/v2022.07.6 this one]) or try another emulator such as [[RMG]] or [[RetroArch]]'s Mupen64Plus-Next core, which are much closer to upstream Mupen64Plus at this point. New releases are also quite frequent, so be careful about updating if the games you're playing work fine.<br />
<br />
==Netplay==<br />
Follow [https://github.com/simple64/simple64/wiki/Netplay-Guide this guide on the GitHub wiki] to set up netplay.<br />
<br />
==External links==<br />
* [https://discord.gg/tsR3RtYynZ Discord netplay channel]<br />
<br />
[[Category:Emulators]]<br />
[[Category:Console emulators]]<br />
[[Category:Home console emulators]]<br />
[[Category:Nintendo 64 emulators]]<br />
[[Category:Windows emulation software]]<br />
[[Category:Linux emulation software]]<br />
[[Category:Netplay]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=CRT_shaders&diff=51362CRT shaders2022-12-10T05:00:37Z<p>GPDP1: Update on CRT-Guest-Advanced</p>
<hr />
<div>[[File:Retroarch_2013-07-22_17-21-17-60.png|thumb|298px|CRT-Geom-Flat, with default settings]]<br />
CRT shaders are one of the most popular categories of shaders. While there had been many attempts to include some kind of CRT-esque filters in older emulators - usually involving little more than overlaying dark gray or black lines, colloquially referred to as scanlines, over the image - modern CRT shaders are much more complex and configurable.<br />
<br />
Many of these replicate aperture grille CRTs (exemplified primarily by Sony TVs and monitors, though other manufacturers released their own versions of the technology later on), which have sharp images and strong scanlines. If you find that these shaders don't look a damn thing like your old TV, it's probably because you owned a slot mask-style CRT, which typically had less noticeable scanlines, or simply had a smaller set, which tended to be less sharp. The easiest way to tell the difference is to feel the curve of the screen; aperture grilles only curve horizontally if at all. Alternatively, look at the left and right sides of the glass against the frame - if the sides are curved, it's a slot mask; if they're straight, it's an aperture grille. Old TVs usually had slot masks, whereas monitors usually had shadow masks. While slot masks and shadow masks can be emulated to a certain degree even at 1080p, much higher resolutions like 4K or higher are better suited to the task. Aperture grilles are much easier to emulate, and can be satisfactorily replicated at 1080p, though it goes without saying even better results can be achieved with higher resolution.<br />
<br />
It is advisable to use integer scaling when using CRT shaders. This means either using windowed mode (x2,x3,x4) or setting an integer scaling option in the video options. The reason is that non-integer scaled scanlines will result in uneven lines with artifacts, though some shaders use oversampling to try to avoid this. If the resulting letterboxing annoys you and you still want to fill up as much of your screen's real estate as possible, you can also try integer scale overscaling, which scales the image up by another integer to fill the vertical image space while still preserving integer scaling, at the expense of some of the image on the top and bottom being cut off. As an example, at 1080p, turning on overscaling would scale a typical SNES game running at 256x224 to 5x scale i.e. 1280x1120, cutting off twenty pixels from both the top and bottom of the image to reach 1080p. Before you fret, know that at 1080p and 4K the loss from overscaling is usually negligible and well within the area that would've been expected to be cut off on a real CRT anyway due to overscan, and developers almost always took this into account and made sure not to put any crucial game information there, so on many if not most older games, overscaling is completely safe.<br />
<br />
==Download==<br />
All official releases of RetroArch come bundled with a full set of slang and GLSL shaders, including CRT shaders, pulled from their shader repositories on Github, which are regularly maintained and updated. The simplest way to keep up to date with shader development is through RetroArch's built-in updater, though if you are only interested in the CRT shaders, you can alternatively grab them from the following repos:<br />
<br />
[https://github.com/libretro/slang-shaders/tree/master/crt slang shaders] - For use with devices that support Vulkan, OpenGL 3.x, GLES3, and/or D3D10/11/12. This is the most current, regularly maintained repository.<br />
<br />
[https://github.com/libretro/glsl-shaders/tree/master/crt GLSL shaders] - For use with devices that only support up to OpenGL 2.x or GLES2. Largely deprecated, though still sporadically maintained.<br />
<br />
[https://github.com/libretro/common-shaders/tree/master/crt Cg shaders] - For use on platforms that only support Cg or HLSL runtimes, such as the PS3. Deprecated.<br />
<br />
==Types==<br />
===CRT-Geom===<br />
[[File:Retroarch_2013-07-22_17-21-17-60.png|thumb|298px|CRT-Geom-Flat, with default settings]]<br />
{{Main|CRT Geom}}<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-geom.slang crt-geom.slang]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-cgwg-fast.slang crt-cgwg-fast.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/geom-deluxe crt-geom-deluxe]<br />
<br />
A very versatile and modifiable shader that simulates an aperture grille display (with the mask enabled). One of the first popular CRT shaders. The deluxe version adds more features, including more mask types. Visit the main article for more details.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
----<br />
===CRT-Caligari===<br />
[[File:crt-caligari-sm.png|thumb|298px|CRT-Caligari, with default settings at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-caligari.slang crt-caligari.slang]<br />
<br />
An older CRT shader similar to CRT-Geom that uses different methods to achieve its effects.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
----<br />
===CRT-Easymode===<br />
[[File:crt-easymode.png|thumb|298px|CRT-Easymode, with default settings at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-easymode.slang crt-easymode.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-easymode-halation crt-easymode-halation]<br />
<br />
A fast, relatively simple CRT shader with easy-to-understand settings. Similar to CRT-Geom in its effects.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
----<br />
===CRT-Hyllian===<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/hyllian crt-hyllian]<br />
*[https://forums.libretro.com/t/crt-hyllian-and-its-variants/38137 Hyllian's shader development thread]<br />
<br />
Aims only for picture quality, so it avoids things that degrade the image just for accuracy. It, however, uses far less power to run than most other CRT shaders, so it is possible to run this on lower end systems. <br />
<br />
Recently, after a long period of inactivity, Hyllian has restarted shader development anew, releasing all-new versions of this shader under heavy inspiration from CRT-Guest-Advanced and others. They can be acquired at his thread on the libretro forums, linked above.<br />
<br />
<br />
----<br />
===CRT-Lottes===<br />
[[File:crt-lottes-multipass.png|thumb|298px|CRT-Lottes-Multipass, with default settings at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-lottes.slang crt-lottes.slang]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-lottes-fast.slang crt-lottes-fast.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-lottes-multipass crt-lottes-multipass]<br />
<br />
A newer CRT shader that uses a horizontal shadow mask pattern with blooming. The horizontal pattern works quite well at 1080p, though it isn't entirely accurate to a true vertical slot mask pattern. The multipass version adds scanline bloom and a few other features.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
----<br />
===GTU===<br />
[[File:GTU.png|thumb|298px|GTU, with default settings at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/gtu-v050 GTUv050 slang]<br />
*[https://github.com/hizzlekizzle/quark-shaders/tree/master/GTU.shader GTUv040 Quark]<br />
*[https://github.com/libretro/slang-shaders/tree/master/nes_raw_palette/shaders/gtu-famicom GTU-Famicom slang]<br />
*[https://github.com/hunterk/interpolation-shaders/raw/master/GTUv050test.tar.gz GTUv50 Test program]<br />
<br />
A CRT shader that focuses more on simulating blur and blending effects and color levels of CRT screens rather than the physical attributes like phosphors and curvature. Highly configurable, can be really sharp, or really blurry or anywhere in between, with optional scanlines and contrast and gamma settings. Settings are stored in a separate "config.h" file for easy editing. GTU-Famicom is a variant that takes an image from an NES with "raw" colors and processes it to output an NTSC image much like an actual NES PPU.<br />
<br />
The test program is a program that can adjust various attributes, such as horizontal and vertical blur, scanlines, etc. It is useful for testing settings to use with the shader, and also to understand how CRT shaders work in general.<br />
<br />
<br />
<br />
<br />
<br />
<br />
----<br />
===ZFast_CRT===<br />
[[File:crt-zfast.png|thumb|298px|ZFast_CRT, with aperture grille mask enabled at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/zfast_crt zfast_crt]<br />
<br />
An extremely fast CRT shader made to run at full speed on extremely low-end hardware like the Raspberri Pi 3. Probably the fastest shader on this list.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
----<br />
===CRT-Royale===<br />
{{Main|CRT-Royale}}<br />
[[File:crt-royale.png|thumb|298px|CRT-Royale, with default settings at 1080p (view original for full details)]]<br />
<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-royale CRT-Royale]<br />
*[https://github.com/libretro/slang-shaders/blob/master/presets/crt-royale-kurozumi.slangp CRT-Royale-Kurozumi]<br />
<br />
A highly advanced multi-pass CRT shader that simulates almost every aspect of the CRT screen. There are tons of parameters to configure, such as phosphor type (aperture grille, slot mask, and EDP shadow mask) and size (i.e. dot pitch), convergence offsets, scanline blooming and many others. Higher resolution is better for this shader, especially with EDP shadow mask phosphor layout and with smaller phosphor dot pitch values. This shader is really complicated compared to most other CRT shaders, reading the README and the documentation in the user-settings.h is a must.<br />
<br />
CRT-Royale-Kurozumi is a preconfigured CRT-Royale made to look like a professional CRT monitor, specifically Sony's PVM/BVM line of monitors.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
----<br />
===CRT-Guest-Advanced===<br />
[[File:crt-guest-dr-venom.png|thumb|298px|CRT-Guest-Dr-Venom, with default settings at 1080p. The newer Advanced shader's default settings look identical (view original for full details)]]<br />
*[https://forums.libretro.com/t/new-crt-shader-from-guest-crt-guest-advanced-updates/25444 Guest's shader development thread]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/guest crt-guest-advanced]<br />
*[https://github.com/libretro/glsl-shaders/tree/master/crt/shaders/guest crt-guest-dr-venom]<br />
<br />
This is the most advanced, feature-rich CRT shader of all. The standard version has even more parameters to configure than CRT-Royale, and while it is slower as a result, most modern GPUs can handle it just fine. If greater speed is desired, there are several faster presets available, as well as variants that add other neat features such as NTSC emulation and better support for games that render at 480p or higher. It is also still in active development and continues to regularly gain features and optimizations. Take heed, however: while it is hosted on the RetroArch shader repositories, it is only updated in that platform when Guest himself deems it ready. Much more regular WIP releases are made in the libretro forums in the shader's dedicated thread, linked above. The version in the RetroArch repo is relatively up-to-date, but it might not hurt to check on Guest's thread for newer developments.<br />
<br />
CRT-Guest-Dr-Venom is the precursor to CRT-Guest-Advanced. It is now considered mostly obsolete, as it is not as feature-filled as Guest's newest shaders and has even been superseded in speed by the faster Advanced presets. As such, it should only be used if your device is unable to load slang shaders, as it has recently been removed from the slang shader repository but remains available as a glsl shader, though the slang version can still be acquired in the first post of Guest's thread.<br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===Sony Megatron===<br />
[[File:sony-megatron.png|thumb|298px|Sony Megatron, using the reference preset in SDR mode with the "1000 TVL" aperture grille mask (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/tree/master/hdr Sony Megatron]<br />
*[https://forums.libretro.com/t/sony-megatron-colour-video-monitor/36109 Sony Megatron development and discussion thread]<br />
<br />
This shader is quite unique among CRT shaders, and shaders in general. It is currently the only shader that takes advantage of HDR support for greater color depth and brightness, allowing for highly accurate CRT emulation on HDR-capable displays, though it is also usable on regular SDR displays through a parameter change. Unlike other CRT shaders, its inner workings are actually fairly simple and it doesn't have many bells and whistles, focusing mainly on drawing scanlines and accurate phosphor masks as well as color correction, which coincidentally also makes it one of the fastest shaders featured on this page. As it is primarily meant for use on bright HDR-capable displays, it draws phosphor masks at full strength with no attempt at mitigating the resulting loss in brightness through parameters such as bloom, glow or mask strength typically seen in other CRT shaders, instead counting on the display to make up for it. On an SDR display, it is highly recommended to use it with the backlight turned up all the way, as otherwise the image will likely be too dim to view comfortably. There are presets emulating various CRT models and types, including several PVM models, certain arcade displays, and even PC monitors.<br />
<br />
==Future==<br />
<br />
===Phosphor Mask Emulation===<br />
At the frontier of CRT shader development has been phosphor mask emulation. As stated previously, there are three overarching mask types: aperture grilles, shadow masks and slot masks. Aperture grilles were used primarily by Sony TVs, professional displays and PC monitors (with a few other brands such as Mitsubishi releasing their own version after Sony's Trinitron patent expired in the late 90's), shadow masks by the majority of PC CRT monitors from the late 80's onwards, and slot masks by just about every non-Sony consumer-level CRT TV, the vast majority of arcade monitors, and very early home computer/PC monitors. A key part of CRT emulation, then, depends on accurately replicating the look of these masks.<br />
<br />
However, even within each of these mask types, there is a lot of variance, as some CRTs were much sharper and were able to resolve a lot more detail than others. This is encapsulated in a specification known as TVL, or television lines, defined as the number of vertical white lines a mask can resolve along the horizontal dimension in a stretch equal to the height of the tube's viewable area (this means TVL is calculated by measuring the screen's height, then counting the number of resolved lines across a horizontal span equal to that height, not across the entire length of the screen). A higher TVL count is the result of higher phosphor density and results in a sharper, more detailed image, as well as more prominent scanlines in low-res content. Most consumer-level CRTs had a relatively low TVL count, whereas professional monitors such as Sony's PVM and BVM series had much higher TVL. In PC monitors, the usual specification to determine sharpness was instead dot pitch, or the distance between two phosphors of the same color. The lower the dot pitch, the sharper the monitor and the more detail it could resolve.<br />
<br />
Taking into account the three mask types and the variance in TVL and dot pitch, then, along with many other variables, it is no wonder no two CRTs looked alike.<br />
<br />
==External Links==<br />
*[http://filthypants.blogspot.com/2015/04/more-crt-shaders.html More CRT Shaders (filthypants.blogspot.com)] - hunterk's comparison of current CRT shaders. <br />
<br />
[[Category:FAQs]]<br />
[[Category:Shaders/Filters]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Mupen64Plus&diff=51259Mupen64Plus2022-11-30T18:13:18Z<p>GPDP1: Update on RMG as a Mupen64Plus frontend</p>
<hr />
<div>{{Infobox emulator<br />
|logo = Mupen64plus-r1.pnd.png<br />
|logowidth = 138<br />
|version = {{Version|Mupen64Plus}}<br />
|active = Yes<br />
|target = [[Nintendo 64 emulators|Nintendo 64]]<br />
|platform = Multi-platform<br />
|developer = bsmiles32, Francisco Zurita, Milan Nikolic, Gilles Siberlin, littleguy77, Logan, Dorian Fevrier, Richard Goedeken<br />
|website = [http://www.mupen64plus.org Mupen64Plus.org]<br />
|license = GNU GPLv2<br />
|source = [https://github.com/mupen64plus GitHub]<br />
}}<br />
<br />
'''Mupen64Plus''' is an open-source, multi-platform, plugin-based [[Nintendo 64 emulators|Nintendo 64 emulator]] that forks from and updates Mupen64. Its developers elected to move away from Zilmar's plugin spec and developed their own set, meaning plugins from other N64 emulators won't work with it. It also has [https://github.com/libretro/mupen64plus-libretro-nx a forked libretro core] under active development.<br />
<br />
==Download==<br />
{| cellpadding="4"<br />
|-<br />
|align=center|{{Icon|Win|Lin|Mac}}<br />
|'''[https://github.com/mupen64plus/mupen64plus-core/releases Latest Stable/Beta releases]'''<br />
|-<br />
|colspan="3"|<hr/><br />
|-<br />
|align=center|{{Icon|Win-big}}<br />
|[https://bitbucket.org/ecsv/mupen64plus-mxe-daily/downloads/ Windows Dev builds]<br/><small>i686-w64 for x86, x86_64-w64 for x64</small><br />
|-<br />
|align=center|{{Icon|APK-big}}<br />
|[https://play.google.com/store/apps/details?id=org.mupen64plusae.v3.fzurita&hl=en Mupen64Plus FZ]<br/><small>Beta port of Mupen64Plus to Android</small><br />
|-<br />
|align=center|{{Icon|Pandora-big}}<br />
|[https://repo.openpandora.org/?page=detail&app=mupen64plus 2.2]<br/><small>Port of Mupen64Plus to Pandora</small><br />
|-<br />
|align=center|{{Icon|Pyra-big}}<br />
|[https://pyra-handheld.com/repo/apps/39 0.1]<br/><small>Port of Mupen64Plus to DragonBox Pyra</small><br />
|-<br />
|align=center|{{Icon|Win|Lin}}<br />
|[[simple64]]<br/><small>mupen64plus + Parallel RDP + a GUI</small><br />
|}<br />
<br />
==Review==<br />
Mupen64Plus, as released by the core development team, lacks a GUI. It is run either directly from the command line with arguments or by dragging and dropping ROM files onto the executable. Emulator and plugin settings are changed by editing the included mupen64plus.cfg file. If a GUI is desired and/or you don't want to bother with command lines or config files, there are several third party frontends and forks available that provide a more streamlined experience. See the Frontends section below for more.<br />
<br />
Mupen64Plus uses its own plugin spec, so it is not compatible with plugins targeting the older zilmar plugin spec used by emulators such as Project64 unless they have been specifically ported to the new spec. However, just about every plugin worth using has now been ported or simultaneously targets both.<br />
<br />
By default, Mupen64Plus applies a ton of audio buffering, causing extremely delayed audio, more so than most other emulators. This can be mitigated by lowering the buffer settings in the mupen64plus.cfg file, though lowering it too much will cause audio crackling. For improved audio latency and sync, consider using Mupen64Plus-Next through RetroArch.<br />
<br />
==Front-ends==<br />
This section will only cover frontends and packages that build on top of the regular mainline Mupen64Plus core and plugins. Multi-emulator programs such as BizHawk, OpenEmu and RetroArch also use a version of Mupen64Plus for their N64 emulation, though they do so by turning the emulator into a core that interfaces with the frontend through an API such as RetroArch's libretro. As such, their versions of Mupen64Plus are considered forks.<br />
<br />
* [https://code.google.com/p/mupen64plus/wiki/ThirdPartyPlugins#Third-Party_Front-end_and_Launcher_Applications Front-ends]<br />
* [http://m64py.sourceforge.net/ M64Py] is highly recommended for a Mupen64Plus frontend. Not only does it come with everything set up, but it also comes with every plugin maintained by the Mupen64Plus development team plus GLideN64. This is great since it's very hard to find some of the plugins without compiling them from the source code. Sadly, it's not perfect, since the input config utility doesn't work with some gamepads.<br />
* [https://github.com/dh4/mupen64plus-qt mupen64plus-qt]<br />
* [https://github.com/simple64/simple64-gui/ simple64-gui] is a nice GUI created in Qt5 in 2017 and updated to Qt6 in 2022. [[simple64]] is a package created by the same author, which combines recent builds of Mupen64Plus with the ParaLLEl-RDP and RSP plugins and simple64-gui. This is arguably the easiest works-out-of-the-box package for beginners, as there's nothing necessary to configure except controls, though this comes at the expense of not being able to use other plugins.<br />
* [https://github.com/Rosalie241/RMG Rosalie's Mupen GUI] is the newest up-and-coming GUI, and aims to provide both ease of use and a complete emulation package. Each release comes with a recent build of Mupen64Plus, RMG itself, and up-to-date builds of GLideN64, ParaLLEl-RDP, Angrylion Plus, Mupen64Plus HLE RSP, ParaLLEl-RSP and CXD4 RSP, with the option of using other plugins as well. Almost all configuration is done through the UI, with little need to dive into the command line or config files. Highly recommended if you desire more options than those afforded by simple64.<br />
<br />
==Using Mupen64Plus==<br />
'''Windows'''<br />
# First create this directory: <code>C:\Users\<username>\AppData\Roaming\Mupen64Plus</code><br />
# Copy all the .ini and .cfg files into this folder, then create a folder in there called "save".<br />
# To play games, you can do the following:<br />
#* Drag and drop your ROM onto mupen64plus.exe.<br />
#* Alternatively, associate .n64/.z64/.v64 files to mupen64plus.exe via Default Apps, then double-click the ROMs to play them.<br />
# You can change plugins and settings by editing the mupen64plus.cfg file.<br />
<br />
==Recommended plugin setups==<br />
Mupen64Plus has its own set of plugins, which are incompatible with plugins used in other emulators. The following is an overview of recommended setups.<br />
<br />
'''Commonly used'''<br />
* Video: Glide64mk2<br />
* RSP: cxd4-ssse3<br />
* Glide64mk2 is just Glide64 with additional tweaks and enhancements for use with Mupen64Plus. The cxd4 plugin is a port of BatCat's RSP plugin for Project64. You will need to enable "DisplayListToGraphicsPlugin" in the cxd4-ssse3 settings for this to work. This appears to be the best combination for use with most games, though toasters may have performance issues. If the mk2 variant is too slow, try regular Glide64.<br />
<br />
'''Best performance and graphics'''<br />
* Video: Rice<br />
* RSP: rsp-hle<br />
* These are Mupen64Plus's default plugins. Rice's Video is a plugin used on other N64 emulators, most known for its support for hi-res texture packs, now enhanced for Mupen64plus. It also has support for bilinear, trilinear, and anisotropic filtering, texture scaling, and up to 16x MSAA. It is not quite up to Glide64's level, but it does well enough for many games and is quite fast. The default RSP plugin appears to be just an enhanced port of vanilla Mupen64's RSP. Use this combination if you have a lower end PC and can't handle the Commonly Used setup.<br />
<br />
'''Accuracy/Rogue Squadron'''<br />
* Video: z64<br />
* RSP: cxd4-ssse3<br />
* z64 is a port of z64gl, a low-level emulation video plugin for N64 emulators. It comes with its own accompanying z64 RSP, but cxd4 (a port of BatCat's RSP Interpreter plugin) appears to be more accurate and very well optimized. This setup is capable of playing difficult games like Rogue Squadron with very few graphical glitches, and it is faster than on Project64 to boot.<br />
<br />
[[Category:Emulators]]<br />
[[Category:Console emulators]]<br />
[[Category:Home console emulators]]<br />
[[Category:Nintendo 64 emulators]]<br />
[[Category:Windows emulation software]]<br />
[[Category:Linux emulation software]]<br />
[[Category:macOS emulation software]]<br />
[[Category:Custom Assets]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Vsync&diff=51257Vsync2022-11-30T09:31:27Z<p>GPDP1: Added some more examples of emulators that utilize Dynamic Rate Control</p>
<hr />
<div>'''Vsync''' (short for vertical synchronization) is used for synchronizing the game's video output to your display's refresh rate to prevent screen tearing.<br />
<br />
Vsync in emulators has historically been problematic, with latency issues caused by driver buffering and stuttering caused by the game running at a different refresh rate than the emulator. Emulators that synchronize on audio may also experience Vsync stuttering when the audio buffers overrun or underrun due to timing imperfections. Some methods for improving Vsync performance on fixed frame rate emulators are discussed below.<br />
<br />
==Static Rate Control==<br />
This audio synchronization method adjusts the audio input rate of the emulated system at startup to match the output rate of the host system, within a certain limit. This allows Vsync to work smoothly even if the game's video refresh rate is not the same as the current display refresh rate. Sufficiently small adjustments should not result in noticeable audio pitch or speed differences, but larger adjustments will be noticeable, so it's usually limited to only up to 5% change in audio rate (on a 60Hz display, this will allow 57Hz-63Hz games to be Vsynced smoothly). The adjustment is not changed after emulator start-up, so slight deviations in frame timing on your system can still cause Vsync stuttering unless you are able to give an exact measurement of your system's timings, which is very difficult or impossible in many cases. May not work well on emulators that use a variable frame rate (i.e not fixed at 50 or 60 FPS for the emulated display).<br />
<br />
This method is known to be implemented in [[higan]] and [[RetroArch]].<br />
<br />
==Dynamic Rate Control==<br />
This method readjusts audio input rate on the fly to avoid having the audio buffers overrun or underrun due to timing imperfections, which keeps Vsync running smoothly. The amount of adjustment is determined by the dynamic rate control delta, which is usually set at 0.5% by default which is thought to be inaudible to the human ear. Combined with Static Rate Control at startup, this can allow emulation to be almost perfectly synchronized to your display without requiring extremely exact system timing information.<br />
<br />
This method is known to be implemented in [[nemulator]], [[RetroArch]], [[Mesen]], [[BizHawk]] and [[Ares]].<br />
<br />
==Hard GPU Sync==<br />
This method is for reducing latency associated with Vsync buffering in the video driver. Vendors typically implement buffering in their video drivers to get better scores on benchmarks and better performance on PC games, but this is detrimental to latency, which is especially bad for emulation of older games that were not made with this latency in mind. Hard GPU Sync forces the driver to the only buffer for a specified number of frames at most using the OpenGL extension ARB_sync, potentially improving latency. Buffering for 0 frames is quite demanding on performance and requires the emulator to run many times faster than is necessary to run full speed at 60fps to avoid frame drops. Buffering for 1 or more frames reduces performance requirements. DRM/KMS on Linux can be utilized in a similar manner but with much better performance due to direct control over video buffers.<br />
<br />
This method is only known to be implemented in [[RetroArch]].<br />
<br />
==G-sync and FreeSync==<br />
These methods are replacements for Vsync that are being developed by Nvidia and AMD, respectively. These require a new display that supports them and they allow the display to have a variable frame rate to synchronize to the game instead of the game being synchronized to the display.<br />
<br />
[[MAME]] can make use of this functionality to run arcade games at their native refresh rate with no stuttering and no audio pitch and speed differences. [[RetroArch]] can make use of it as well if static syncing and dynamic rate control are disabled by setting "Sync to Exact Content Framerate" to on (Vsync still must be on within RetroArch for this to work).<br />
<br />
==External Links==<br />
*[https://github.com/libretro/RetroArch/wiki/Getting-optimal-vsync-performance RetroArch guide to getting optimal Vsync performance]<br />
*[https://github.com/libretro/libretro.github.com/raw/master/documents/ratecontrol.pdf Technical paper explaining the details of how Dynamic Rate Control works.]<br />
<br />
[[Category:FAQs]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Nintendo_64_emulators&diff=51240Nintendo 64 emulators2022-11-30T01:01:12Z<p>GPDP1: More info on Project64 nightlies and recent regressions</p>
<hr />
<div>{{Infobox console<br />
|title = Nintendo 64<br />
|logo = Nintendo64Console.png<br />
|developer = [[:Nintendo]]<br />
|type = [[:Category:Home consoles|Home video game console]]<br />
|generation = [[:Category:Fifth-generation video game consoles|Fifth generation]]<br />
|release = 1996<br />
|discontinued = 2002<br />
|predecessor = [[Super Nintendo emulators|SNES]]<br />
|successor = [[GameCube emulators|GameCube]]<br />
|emulated = {{✓}}<br />
}}<br />
<br />
{{for|other emulators that run on N64 hardware|Emulators on N64}} <br />
<br />
The '''Nintendo 64''' is a 64-bit fifth-generation console released by Nintendo on September 29, 1996 for {{inflation|USD|199.99|1996}}.<br />
<br />
Nintendo was the second company approached by Silicon Graphics Inc. (SGI), who wanted to roll out their previously enterprise-only technology in the consumer space. They originally pitched their idea to Sega, but it's assumed that Nintendo's offer was more appealing. With the NEC VR4300 CPU clocked at 93.75 MHz, 4MB of RAM, and an SGI RCP GPU, Nintendo had finalized much of the hardware at least a year before launch, preventing video games from needing drastic rewrites as a result of architectural changes. A separate add-on was later released called the "Expansion Pak" that added an additional 4MB of RAM, totaling 8MB. The development workstations were often Unix-based, something that would later help reverse engineers in some projects.<br />
<br />
==Emulators==<br />
<div style="max-width:100%; overflow:auto;"><br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Platform(s)<br />
! scope="col"|Latest version<br />
! scope="col"|Plugins<br />
! scope="col"|Controller Pak<br />
! scope="col"|Rumble Pak<br />
! scope="col"|Transfer Pak<br />
! scope="col"|64DD<br />
! scope="col"|Depth<br/>output<br />
! scope="col"|Texture<br/>enhancement<br />
! scope="col"|Netplay<br />
! scope="col"|[[libretro]]<br />
! scope="col"|<abbr title="Free/Libre and Open-Source Software">FLOSS</abbr><br />
! scope="col"|Active<br />
! scope="col"|[[Recommended emulators|Recommended]]<br />
|-<br />
!colspan="15"|PC / x86<br />
|-<br />
|[[RetroArch|Mupen64Plus-Next (mupen64plus_next_libretro)]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/ nightly]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<ref group=N name=texture>Only supports texture packs, and not filtering or upscaling</ref><br />
|{{✓}}<br />
|{{✓}}<ref group=N name=libretro>Available exclusively as a libretro core</ref><br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[RMG]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/Rosalie241/RMG/releases {{RMGVer}}]<br >[https://github.com/Rosalie241/RMG/actions Dev]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<ref group=N name=Glide>Only with GLideN64</ref><br />
|{{✓}}<ref group=N name=Glide/><br />
|{{~}}<ref group=N name=input>Requires replacing the input plugin to one with netplay support</ref><br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Project64]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://www.pj64-emu.com/public-releases {{Project64Ver}}]<br >[https://www.pj64-emu.com/nightly-builds Dev] <br > [https://github.com/Rosalie241/PJ64Launcher/releases/latest keygen]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<ref group=N name=input/><br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[ares]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/ares-emulator/ares/releases {{aresVer}}]<br >[https://github.com/ares-emulator/ares/actions git]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|{{~}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[simple64]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/simple64/simple64/releases {{Simple64Ver}}]<br >[https://github.com/simple64/simple64/actions git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<ref group=N name=RMGMupen>Stick to RMG or Mupen64Plus-Next until dev finishes working out the timings.</ref><br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://github.com/mupen64plus/mupen64plus-core/releases git]<br/>[https://bitbucket.org/ecsv/mupen64plus-mxe-daily/downloads/ Dev Builds]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<ref group=N name=Glide/><br />
|{{✓}}<ref group=N name=Glide/><br />
|{{~}}<ref group=N name=input/><br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[BizHawk]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[http://tasvideos.org/BizHawk/ReleaseHistory.html {{BizHawkVer}}]<br/>[https://gitlab.com/TASVideos/BizHawk/-/pipelines Dev builds]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}[https://github.com/TASEmulators/BizHawk/issues/2454 *]<br />
|{{✓}}<ref group=N name=Glide/><br />
|{{✓}}<ref group=N name=Glide/><br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[1964]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://archive.org/details/goldeneye-007perfect-dark-1964-mouse-keyboard-60fps 1964 GEPD]<br />[http://www.emulation64.com/files/getfile/936/ 1.1] (Official)<br />[http://files.emulation64.fr/Emulateurs/EMU_1964_146.zip 1.2 r146] (Unofficial SVN)<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<ref group=N name=input/><br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<ref group=N name=1964GEPD>Recommended to use 1964 GEPD for Goldeneye 007 or Perfect Dark, this emulator is primarily made for GoldenEye/Perfect Dark and their ROM hacks. It has poor ROM support outside of these games.</ref><br />
|-<br />
|[[CEN64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/tj90241/cen64 git]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[RetroArch|ParaLLEl-N64 (parallel_n64_libretro)]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/ nightly]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{✓}}<ref group=N name=libretro/><br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<ref group=N name=obsolete>Obsolete and replaced by Mupen64Plus-Next</ref><br />
|-<br />
|simple64 (Final GLideN64)<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/thekovic/simple64/releases/tag/v2021.5.30 Final GLideN64]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<ref group=N name=RMGGlide>RMG with GLideN64 recommended.</ref><br />
|-<br />
|[[Project64 Netplay]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://github.com/Project64Netplay/Project64-Netplay-2x git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|Rokuyon<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/Hydr8gon/rokuyon git]<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[DaedalusX64]]<br />
|align=left|{{Icon|Linux|macOS}}<br />
|[https://github.com/DaedalusX64/daedalus/releases/latest git]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|{{✗}}<br />
|-<br />
|[[Sixtyforce]]<br />
|align=left|{{Icon|macOS}}<br />
|[http://sixtyforce.com/download/ {{SixtyforceVer}}]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Larper64<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://drive.google.com/file/d/1IWyw5UG9Uf24KG0zrcXSFoOmcQoHWmyc/view {{Larper64Ver}}]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|[[UltraHLE]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://web.archive.org/web/20070312015944/http://www.emuunlim.com/UltraHLE/ultrahle.zip 1.0]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|[[MAME]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[http://www.mamedev.org/release.html {{MAMEVer}}]<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[Ryu64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/Ryu64Emulator/Ryu64 git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|R64Emu<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/rasky/r64emu git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
!colspan="15"|Mobile / ARM<br />
|-<br />
|[[Mupen64Plus]] FZ<br />
|align=left|{{Icon|Android}}<br />
|[https://play.google.com/store/apps/details?id=org.mupen64plusae.v3.fzurita 3.0.322 (beta)]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<ref group=N name=texture/><br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Pandora|Pyra}}<br />
|[http://repo.openpandora.org/?page=detail&app=mupen64plus Pandora]<br/>[https://pyra-handheld.com/repo/apps/39 Pyra]<br />
|{{?}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
!colspan="15"|Consoles<br />
|-<br />
|[[Virtual Console]]<br />
|align=left|{{Icon|Wii|WiiU}}<br />
|N/A<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|[[DaedalusX64]]<br />
|align=left|{{Icon|PSP|3DS}}<br>{{Icon|Vita|PS2}}<br />
|[https://github.com/DaedalusX64/daedalus/releases/latest PSP]<br/>[https://github.com/masterfeizz/DaedalusX64-3DS/releases 3DS]<br/>[https://github.com/Rinnegatamante/DaedalusX64-vitaGL/releases VitaGL]<br/>[https://www.ps2-home.com/forum/viewtopic.php?f=99&p=39957#p39957 PS2]<br />
|?<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|{{✓}}<br/><small>(PSP)</small><br />
|-<br />
|Not64<br />
|align=left|{{Icon|GCN|Wii}}<br />
|[https://github.com/Extrems/Not64/releases/latest git]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|Surreal64 CE<br />
|align=left|{{Icon|Xbox}}<br />
|[https://digiex.net/threads/surreal64-ce-b6-0-download-n64-emulator-for-xbox.13677 Beta 6.0]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|mupen64-360<br />
|align=left|{{Icon|Xbox360}}<br />
|[https://digiex.net/threads/mupen64-360-xbox-360-nintendo-64-n64-emulator-download.9352 0.96 beta]<br />
|?<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|[https://code.google.com/p/mupen64gc/ Wii64]<br />
|align=left|{{Icon|GCN|Wii}}<br />
|[https://code.google.com/archive/p/mupen64gc/downloads 1.1 beta]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|}<br />
</div><br />
<references group=N /><br />
<br />
===Comparisons===<br />
Although many Nintendo 64 emulators have been made and many games can be run between them, until recently complete compatibility and/or accuracy left a bit to be desired. For half a decade, Mupen64Plus and Project64 have vied for the most playable emulator, and which was more compatible often depended on when and in what configuration each emulator has been tested. As of August 2017, both emulators have roughly equal compatibility and accuracy when running with the same [[recommended N64 plugins]] setup, though both default to Glide64, a now relatively lackluster plugin.<br />
<br />
;[[Mupen64Plus]]<br />
:A multi-platform emulator based on Hacktarux's Mupen64. It's about as accurate as Project64,<ref>loganmc10. [https://github.com/mupen64plus/mupen64plus-core/pull/336 ''Ignore TLB write if TLB entry is unmapping itself'']. "By the way, once this, along with the other PR's I have waiting are merged, we are at "compatibility parity" with Project64 as far as I can tell. I don't know of any game that doesn't boot with mupen64plus that works in PJ64."</ref> when both emulators are run with GLideN64. However, Mupen64Plus lacks a native GUI, instead being launched either from the command line or by dragging and dropping ROMs onto the executable and editing the config with a text editor. It also only comes bundled with outdated video plugins, so to ensure the best possible compatibility, sourcing better third-party plugins such as GLideN64 is a must. [[BizHawk]] and [[OpenEmu]] use forks of Mupen64Plus and its plugins for their N64 emulation, but they seem to be shallow. As of 2022 Project64-style overclocking for faster frame rates has been added under the option 'CountPerOpDenomPot'.<br />
<br />
:;Mupen64Plus-Next and ParaLLEl-N64<br />
:Both are heavily-modified forks developed as [[libretro]] cores. They introduce many features and optimizations not present in mainline alongside [[RetroArch]]'s general features, including 3-point texture filtering for Glide64, superior A/V sync and latency, and even an initially exclusive LLE Vulkan renderer based on Angrylion's pixel-perfect RDP plugin now known as ParaLLEl-RDP, making it a better alternative to the standalone version in some cases. 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.<br />
<br />
::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), considerably cleans up the Core Options menu for easier configuration and 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.<br />
<br />
:;[[simple64]]<br />
:A fork of Mupen64Plus with a custom-made Qt GUI. This is probably the easiest "just works out of the box" solution for Nintendo 64 emulation, as it comes bundled with ParaLLEl-RDP and ParaLLEl-RSP, ensuring both excellent compatibility and good speed without needing to mess with plugins or settings, provided your hardware supports Vulkan. However, unlike other emulators, it does not allow you to use other plugins. While it began as a shallow fork, it has increasingly become something closer to a hard fork, as its developer has opted to make various accuracy-focused changes to the emulation core that will require additional work to port back to upstream or to other forks. It also currently features only a cached interpreter core, as the dynarecs used by Mupen64Plus are incompatible with the core timing changes made by the developer. While this makes simple64 more accurate than most other N64 emulators, it also results in slower performance. If more speed and enhancements are desired, there is an older build that is closer to upstream and uses GLideN64 as its graphics plugin - unfortunately lacking the texture enhancement suite required for use of texture packs and upscaling.<br />
<br />
:;[[RMG]]<br />
:Rosalie's Mupen GUI is a project aiming to close the gap between Project64 and Mupen64Plus in terms of user experience. Its interface is about on par with simple64's in terms of cleanliness and ease of use, but unlike simple64, it remains a shallow fork of upstream Mupen64Plus and allows you to use other plugins. The latest development versions come bundled with GLideN64, Angrylion RDP Plus and ParaLLEl-RDP for video plugins, and mupen64plus-hle-rsp, CXD4 and ParaLLEl-RSP for RSP plugins, though it can still use the older plugins that come with regular Mupen64Plus in case your PC cannot handle the newer plugins. If you prefer GLideN64, this is a superior alternative compared to simple64, as the last version of simple64 that uses GLideN64 is becoming increasingly outdated.<br />
<br />
:;Wii64 and Not64<br />
:Both are based on Mupen64, with Not64 being a fork of Wii64. Not64 claims to be better optimized 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 releases whenever possible.<br />
<br />
;[[Project64]]<br />
: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 stable 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 some of the Mupen64Plus attempts and supports features such as Transfer Pak emulation and 64DD emulation. It now comes with GLideN64 out-of-the-box, but the default audio plugin isn't even the best in the box. Annoyingly, it also nags you with a timed, unskippable message asking for donations to the project upon launch, though this can be gotten around through a [https://github.com/Rosalie241/PJ64Launcher/releases/tag/1.3.0 script]. An alternative is to download it through [https://github.com/Rosalie241/BetterMajorasMaskInstaller/releases/tag/4.0.2 Rosalie's BetterMajorasMaskInstaller], which downloads the latest nightly version of Project64 with the nagging message removed and installs several useful third-party plugins (it also offers to install HD texture packs for OoT and MM, but you can opt out of those), though take heed - Project64 is currently in the middle of a major code rewrite in preparation for the upcoming 4.0 version, and more than a few regressions and bugs have crept into the nightlies as a result, so it might be better to just grab the latest plugins and stick to version 3.0.1. For the most part, it works well in [[Wine]], but, if you're on a different platform, use Mupen64Plus instead.<br />
<br />
;[[Ares]]<br />
:An open-source multi-system emulator and successor to Near's [[higan]] project, with a mostly original N64 core. Unlike other N64 emulators, it aims for high accuracy and does not employ HLE RSP or RDP emulation of any kind, nor does it use game-specific hacks. It uses Themaister's ParaLLEl-RDP Vulkan renderer (with the MAME renderer as a software-based fallback) for pixel-perfect LLE graphics. While it is currently less compatible than Mupen64Plus or Project64, it is quickly catching up to them [https://ares-emu.net/compatibility/15 (only a handful of games are currently listed as partially or not working)], and it currently passes several stringent [https://github.com/ares-emulator/ares/pull/613 accuracy tests] the other emulators do not. However, it remains to be seen how accurate its developers are willing to make it [https://github.com/ares-emulator/ares/commit/3142bd3aef3a0b7c9d97517c70f41e0eb27542ea without compromising speed] and playability on current machines.<br />
<br />
;[[CEN64]]<br />
:Aims for cycle accuracy while at the same time aiming to eventually be usable on modern PC hardware. It lacks many features and has spotty compatibility, but it can already emulate some well-known edge cases such as picture recognition in Pokemon Snap. Unfortunately, its creator appears to have abandoned the project [https://github.com/n64dev/cen64/releases/tag/v0.3 citing lack of satisfaction with the program's performance in its current interpreter-based incarnation], and while the baton has been collectively passed to the n64dev community for further development, progress has been slow.<br />
<br />
;[[1964]]<br />
:Along with its various versions and forks, it was once a decent, speedy open-source alternative to Project64 and Mupen64, though it usually lagged behind the two compatibility-wise. Nowadays it has completely fallen off the radar as development has halted, and there is no longer a central code repo to speak of. There is little reason to use it nowadays outside of historical purposes, very specific edge cases, or if your device is too slow to run Mupen64Plus or Project64.<br />
<br />
;Daedalus<br />
:Is a Nintendo 64 emulator for PC which was ported to the PSP under the name of DaedalusX64. The PSP version later became the main version and got ported to platforms such as the Dreamcast, the PS2, the PS Vita, and the 3DS. On PSP, several games are able to reach full speed and most of them work with few emulation issues.<br />
<br />
;[[Sixtyforce]]<br />
:Is macOS-only, closed-source, and asks you to pay for full access to its features. It was once one of the only choices for Mac users, particularly those with older Macs since it's the only emulator with a <abbr title="Power PC">PPC</abbr> [[Dynamic recompilation|dynarec]]), but, with the switch to x86 and Mupen64Plus being ported to macOS, it has now become less relevant. However, development is still ongoing and is currently in its [https://sixtyforce.com/rosetta/ third rewrite] to support the upcoming [https://en.wikipedia.org/wiki/Apple-designed_processors Apple Silicon].<br />
<br />
;[[UltraHLE]]<br />
: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.<br />
<br />
;[[Ryu64]]<br />
:Is a Nintendo 64 emulator made in C#. The 'Ryu' word is named after the "RyuJIT" used in both Visual Basic & C#. But it might have been inspired by the lead author's sole (so far) [https://github.com/Ryujinx/Ryujinx/commits?author=Dudejoe870 commit] at Switch emulator, [[Ryujinx]]'s Git repository, and his depreciated [https://github.com/Dudejoe870/RyujinxAutoUpdate Ryujinx Auto Updater] tool. "86RYU", an x86 JIT compiler, is being developed alongside this emulator too.<br />
<br />
;[[BizHawk]]<br />
:Another out-of-the-box solution (supports GLideN64 and Angrylion) for n64.<br />
<br />
;n64oid<br />
:An Android exclusive Nintendo 64 emulator. It is similar to Project 64 1.6 in terms of compatibility, although it is unknown who authored it, as the APK for n64oid circulates on many legally questionable APK sites. n64oid has the infamous problem in Mario Kart 64 of the screen in Wario Stadium not displaying properly, as it displays nothing but black. It upscales all games to widescreen, which works well most of time, but on many phones it will have performance issues. The emulator is relatively poor, but it is much easier to set up than other options. The emulator features a menu with many similarities to the mobile edition of Snes9x EX+, and the My Boy! family of Android emulators for Game Boy systems.<br />
<br />
==Emulation issues==<br />
{{Main|Recommended N64 plugins}}<br />
<br />
Nintendo 64 emulation is now decent. A lot of the major problems that N64 emulation had in the past, have been fixed for quite some time now. The only catch is that the accurate emulators have higher system requirements. The main remaining problem is the lack of accurate cycle counting.<br />
<br />
===[[High/Low level emulation|High-level vs. low-level]] graphics===<br />
<br />
One of the biggest hurdles to emulating the Nintendo 64 was the Reality Display Processor (RDP), which used a custom design that had to be fine-tuned to get more performance out of the system using microcode. To emulate the RDP accurately, one would have to execute said microcode the way the RDP did, which differed from PC graphics cards of the day. To complicate matters further, API standards that were available on PCs two decades ago were nowhere near as flexible as they are today. If you wanted to make an accurate GPU-accelerated RDP plugin in 2003, you simply couldn't with the APIs of the time (OpenGL 1.x and Direct3D 9). For the average user, hardware-accurate GPU acceleration would be out of reach for a long time.<br />
<br />
[[UltraHLE]] offered a compromise. In contrast to earlier consoles, whose video chips in hindsight had been easy to render to the host CPU's framebuffer, performant RDP emulation had to take shortcuts, including programming around specific games' microcode to cleanly translate their graphics commands into API calls using Direct3D, OpenGL, and even Glide. With this, the theoretical system requirements plummeted, 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 is an improvement is subjective and a common point of discussion. Unfortunately it proved to be hit and miss, owing to the nature of per-game microcode detection and having to tweak settings to prevent some games from running into graphical glitches.<br />
<br />
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).<br />
<br />
On the high-level side, gonetz and one or two assistants spent a large portion of development improving GlideN64's microcode handling 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 framebuffer is used as well as performance issues), VI emulation, and how combine/blending modes are emulated (such as noise issues and combiner accuracy).<br />
<br />
<gallery widths="300" mode="packed"><br />
Majora's mask accurate.png| Low-level emulation of Majora's Mask using SoftGraphic<br />
Project64 2013-07-26 14-20-17-55.png| High-level emulation of Majora's Mask using Jabo's Direct3D<br />
</gallery><br />
<br />
===[[Texture filtering]]===<br />
The Nintendo 64 was the first consumer device to be able to filter textures when rendering 3D objects. However, unlike every console and PC graphics card made after the N64, its implementation of bilinear was primitive in that, in order to reduce strain on the system, it only used three samples as opposed to four, resulting in slightly jagged, asymmetrically-filtered textures. Instead of faithfully applying this "imperfect" version of bilinear filtering, HLE plugins instead applied conventional bilinear filtering, interpolating straight from the source texture up to the output resolution the same way a PC game would. While that method is technically superior, it can result in textures that look even blurrier than on real hardware.<br />
<br />
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 pre-rendered backgrounds or menu screens, may look as though they are separated into squares (see images below; note how OoT's Quest Status screen appears to be divided into a grid). 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 oftentimes low resolutions.<br />
<br />
Modern emulators and plugins have taken some steps which help remedy these problems. For instance, GLideN64 now supports N64-style three-point texture filtering, which results in a more faithful look. It is also capable of rendering at 320x240, which sidesteps the issues with filtered text, UI elements, and menu screens, while still retaining texture filtering. Pixel-accurate plugins such as Angrylion and ParaLLEl-RDP do not have these problems at all.<br />
<gallery widths="300" mode="packed"><br />
Project64_2013-06-26_17-44-58-31.png|Conker's Bad Fur Day copyright screen, displaying issues with filtered text.<br />
Mupen64plus_2013-08-18_20-35-50-08.png|Ocarina of Time's menu subscreen, displaying issues with filtering.</gallery><br />
<br />
===Timing issues===<br />
One of the biggest remaining problems in N64 emulation is lack of accurate core timings, which in practice means games do not always run at the speed they would on real hardware. While this technically affects all games, the majority are only affected to a negligible degree, and in some instances (particularly in Rare games) this can actually result in less framerate drops and lag, which can be seen as beneficial. However, some game engines actually depend on accurate timings for proper game behavior, and not properly emulating them can result in considerable to major issues. Some notable examples include the following:<br />
* Intros and cutscenes playing too fast and not properly syncing up with musical cues. Seen in Goldeneye's intro and Body Harvest's beginning cutscene.<br />
* Gameplay demos running at hyper speed. Earthworm Jim 3D is most notorious for this, though the main game itself is largely unaffected.<br />
* Game physics not working properly due to being tied to framerate. A good example is Donkey Kong 64, which is programmed to boost the character's speed and momentum proportional to in-game lag (most likely to make up for the game's frequent framerate drops), which can be exploited for certain glitches and sequence breaks on real hardware. Emulators currently run the game too well and with too little lag, making most of these tricks impossible to pull off.<br />
* Possibly the most affected game is Knife's Edge, which runs like it's on permanent fast-forward, making it all but unplayable. Messing with timing-related settings such as CounterFactor can mitigate this somewhat, but nowhere near enough to fix the issue.<br />
Fortunately, tackling these problems has recently become a core focus of development in some N64 emulators, and attempts are underway to improve the situation. [[Ares]] currently has the most accurate timings overall, and already runs Earthworm Jim 3D's demos much better than other emulators. Meanwhile, [[simple64]] has recently pushed various timing-related commits aimed at improving accuracy, and as a result it may now be the only emulator that runs Donkey Kong 64 properly. As these efforts progress, it should be noted that a side-effect of improved timings may be greater in-game lag. This should not be seen as the emulator becoming slower, but rather the emulator behaving exactly like real hardware does, as many N64 games were notorious for framerate drops.<br />
<br />
==Peripherals==<br />
===Voice Recognition Unit emulation===<br />
The Voice Recognition Unit (VRU) is an accessory used primarily by ''Hey You, Pikachu''. No emulator or input plugin supports this, although there is an on-going effort to get it working.<ref name="emutalk">{{cite web|url=http://www.emutalk.net/threads/55279|title=Hey You! Pikachu - Possible HLE Implementation|publisher=emutalk|accessdate=2018-06-17|date=2014-10-27, Last edit: 2016-04-04}}</ref><br />
===''Densha De Go!'' Controller===<br />
Also available for the [[PlayStation emulators|PlayStation]], ''Densha De Go! 64'' is a Japan-only train simulator released by [[Wikipedia:Taito|Taito]] that is compatible with an optional special controller that plugs into the player 3 port.<ref name="ArcadeUSA">{{cite web|url=https://www.youtube.com/watch?v=cCcPAGhcnck|title=Densha De Go! Nintendo 64 Controller!|publisher=YouTube|accessdate=2018-06-17|date=2017-01-20}}</ref> No emulator supports it.<br />
<br />
===Pokémon Snap Station===<br />
There was a special kiosk designed to promote ''Pokémon Snap'' called the ''Pokémon Snap Station'', which is also compatible with the North American ''Pokémon Stadium'' with its gallery mode. It is just a Nintendo 64 with special hardware designed for the station.<ref name="Sixty Formula">{{cite web|url=https://www.youtube.com/watch?v=AMbjvGvPkV4|title=The Pokemon Snap Station|publisher=YouTube|accessdate=2018-06-17|date=2016-05-21}}</ref><ref name="MetalJesusRocks">{{cite web|url=https://www.youtube.com/watch?v=5_UGpRN6AnM&t=3m35s|title=VIDEO GAME KIOSKS - Extreme Game Collecting!|publisher=YouTube|accessdate=2018-06-17|date=2016-05-25}}</ref> Although the special cartridge boots in emulators compatible with the regular version, the printing functions are inaccessible due to no emulation of the printer for the player 4 slot, credit system, or the special board to switch between the regular and special cartridges.<br />
<br />
===Transfer Pak emulation===<br />
A few games, such as ''Mario Golf'', ''Mario Tennis'', ''Mario Artist: Paint Studio'', and the ''Pokémon Stadium'' games, can use the Transfer Pak, an attachment that allows interfacing with specific [[Game Boy/Game Boy Color emulators|Game Boy/Color]] games for certain features. Most N64 emulators can emulate the Transfer Pak's functionality to one degree or another, with the most robust being Project64 with N-Rage's input plugin, but a couple of things are difficult to emulate or are not emulated at all:<br />
<br />
*Taking pictures with the Japanese ''Game Boy Camera'' (called ''Pocket Camera'') while in Transfer Pak mode playing ''Mario Artist: Paint Studio'' displays static.<br />
*Playing the Gen 1 and 2 Pokemon games through the Game Boy Tower in Pokemon Stadium 1 and 2 is notoriously finicky. At the moment, only Project64, using the N-Rage input plugin, can properly load either game's Game Boy Tower at all, with other emulators either crashing or failing to establish the connection. Even here, extra steps must be taken: for Pokemon Stadium 2, simply set the CPU core to Interpreter and Counter factor set to 1 in the emulator's game settings. For the first Stadium game, in addition to the aforementioned settings, Delay SI Interrupt must also be turned on, and an LLE RSP plugin other than the default Projec64 RSP must be used, such as ParaLLEl-RSP.<br />
<br />
===64DD emulation===<br />
The 64DD (an abbreviation for "64 Disk Drive") was a peripheral which allowed a proprietary disk format to be used with the N64. These disks had more space at a cheaper manufacturing cost. The peripheral was a commercial failure and was never released outside of Japan. Internal evidence suggests that, much like the GBA e-Reader, it wasn't even intended for a European release.<br />
<br />
Expansion disks are region-coded to either Japan or the US (obviously unused) and won't work with N64 games from the wrong region. Only F-Zero X has an official disk, but Ocarina of Time, Mario Party, and Pokemon Stadium (JP) have fully implemented but unused disk support.<br />
<br />
The special AV-In cartridge (NUS-028) that ''Mario Artist: Talent Studio'' can use doesn't work because it requires an RCA cable signal.<br />
<br />
Recently, there has been an effort to emulate the 64DD, and now [[Project64]] and [[MAME]] can run several commercial 64DD games as part of its N64 emulator. This is being ported to [[CEN64]] with the help of [https://twitter.com/LuigiBlood LuigiBlood]. The latest newcomer is Mupen64Plus which is the base of other emulators such as [[simple64]] and [[RMG]].<br />
<br />
<div style="max-width:100%; overflow:auto;"><br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Platform(s)<br />
! scope="col"|Latest Version<br />
! scope="col"|N64 Mouse<br />
! scope="col"|64DD Emulation<br />
! scope="col"|Active<br />
! scope="col"|[[Recommended emulators|Recommended]]<br />
|-<br />
! colspan="7"|PC / x86<br />
|-<br />
|[[RetroArch|Mupen64Plus-Next (mupen64plus_next_libretro)]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/ nightly]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Project64]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://64dd.org/downloads.html 64DD.org Builds]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[ares]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/ares-emulator/ares/releases {{aresVer}}]<br >[https://github.com/ares-emulator/ares/actions git]<br />
|{{✓}}<br />
|[https://twitter.com/LuigiBlood/status/1568694009496756225 High]<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[RetroArch|ParaLLEl-N64 (parallel_n64_libretro)]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/ nightly]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[CEN64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/tj90241/cen64 git]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[MAME]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[http://www.mamedev.org/release.html {{MAMEVer}}]<br />
|{{✗}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[simple64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/simple64/simple64/releases {{Simple64Ver}}]<br >[https://github.com/simple64/simple64/actions git]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|?<br />
|-<br />
|[[RMG]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/Rosalie241/RMG/releases {{RMGVer}}]<br >[https://github.com/Rosalie241/RMG/actions Dev]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|?<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://github.com/mupen64plus/mupen64plus-core/releases git]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|?<br />
|}<br />
</div><br />
<br />
* Project64's latest versions emulate the N64 mouse and can load Zoinkity's hacked 64DD cartridge conversions at playable speeds. You'll need to set every game to have 8MB of Memory by default manually. Games do not save, some need "32-bit engine" to be unchecked (like Talent Studio), and some (like Polygon Studio to fix models and Paint Studio to fix stamps) need the Angrylion GFX plugin rather than GlideN64, which does the job for the rest.<br />
**The 64DD hardware started to be emulated around 2.3's release with the help of [https://github.com/LuigiBlood LuigiBlood]. Saving works but in the form of NDR files. NDR files are copied versions of NDD images with save data included as to not write to the clean unaltered images. In order to play 64DD games in their original forms, 8MB of memory is still needed because the real hardware needed the Expansion Pak upgrade. The IPL is also needed.<br />
<br />
* MAME includes early basic 64DD emulation as well but is much slower. Disk images need to be in head/track format. See [https://github.com/Happy-yappH/ddconvert.git here] for more information. It does not currently support disk swapping or saving disk to files. Writes only update the copy in memory, and, once the MAME process ends, the changes are lost. Current usage: <code>mame n64dd -quickload disk -cart cart -nodrc</code> (both disk and cart are optional)<br />
<br />
* CEN64, like Project64, had 64DD emulation ported to it from MAME. However, it focuses on accuracy and plays much slower than other emulators, aside from the 64DD emulation itself is imperfect.<br />
<br />
==Hardware variants==<br />
===iQue Player emulation===<br />
Before the GBA, DS, and 3DS, Nintendo released a modified version of their Nintendo 64 system for the Chinese market, which was called the iQue Player, through their not-quite-subsidiary iQue. Fourteen games were translated into Simplified Chinese, including Sin and Punishment, Ocarina of Time (the Majora's Mask port was canceled), Super Mario 64, and others.<br />
<br />
Unlike the Chinese releases of their more recent systems and their games, iQue Player releases are regular N64 roms wrapped with several layers of encryption, as well as a ticket and signature system like that on Wii, DSi, 3DS, Wii U, and Switch. The Chinese ROM-hacking scene is very active though and has translated the Japanese regular N64 releases for many of these to their language already, which explains some of the Chinese ROMs floating for those. However, recently, almost all pieces of iQue Player software were decrypted to regular .z64 ROM format.<br />
<br />
Several of the Chinese game localizations already run on N64 emulators, but as some hardware features of the iQue Player are not yet supported, some games, as well as the system menu and features in games such as saving, do not work yet.<br />
<br />
===Aleck 64 arcade emulation===<br />
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). 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.<br />
<br />
The Aleck 64 ROMs were dumped, and Zoinkity is working on converting them to regular N64 ROMs (with controls remapped to N64 controller buttons). They generally require an 8MB Expansion Pak to run at all and 4K EEPROM to save settings and scores. The ones covered by these patches are:<br />
<br />
* Donchan Puzzle Hanabi de Doon!<br />
* Eleven Beat: World Tournament<br />
* Hi Pai Paradise<br />
* Hi Pai Paradise 2<br />
* Kuru Kuru Fever<br />
* Magical Tetris Challenge<br />
* Mayjinsen 3 / Meijin-Sen<br />
* Star Soldier: Vanishing Earth (also ported to N64)<br />
* Super Real Mahjong VS<br />
* Tower & Shaft<br />
* Vivid Dolls (official eroge game on a Nintendo console)<br />
<br />
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.<br />
<br />
The remaining ones from the system's library not yet covered are:<br />
* Rev Limit<br />
* Variant Schwanzer<br />
<br />
==Virtual Console games in Dolphin==<br />
A number of N64 games were released for the Wii's Virtual Console service throughout its lifespan. While the emulators at the heart of each Virtual Console title were of average accuracy (rather than using one generic emulator used for every game, each title had an emulator specifically tailored to that game), they were good enough to render the games in full playable capacity with few to no glaring errors. Many of these titles are emulated well through Dolphin, and for a good while, due to persistent long-standing inaccuracies in N64 emulators and plugins, this was the best way to emulate certain N64 games, particularly Pokemon Snap and Mario Tennis. The system requirements are much higher than running them on regular N64 emulators, but it's doable for many games. Today, regular N64 emulators and plugins have advanced to the degree that this has become unnecessary, relegating this method of N64 game emulation to little more than a curiosity, at least on PC.<br />
<br />
The following games are on the N64 Virtual Console for Wii:<br />
<br />
{|width="100%"<br />
|- valign="top"<br />
|<br />
* 1080 Snowboarding<br />
* Bomberman Hero<br />
* Cruis'n USA<br />
* Custom Robo V2 (Japan only)<br />
* F-Zero X<br />
* Kirby 64: The Crystal Stars<br />
* The Legend of Zelda: Majora's Mask<br />
* The Legend of Zelda: Ocarina of Time<br />
|<br />
* Mario Golf<br />
* Mario Kart 64<br />
* Mario Party 2<br />
* Mario Tennis<br />
* Ogre Battle 64: Person of Lordly Caliber<br />
* Paper Mario<br />
* Pokemon Puzzle League<br />
|<br />
* Pokemon Snap<br />
* Sin & Punishment (English)<br />
* Star Fox 64<br />
* Super Mario 64<br />
* Super Smash Bros.<br />
* Wave Race 64<br />
* Yoshi's Story<br />
|}<br />
<br />
==References==<br />
<references/><br />
<br />
{{Nintendo}}<br />
<br />
[[Category:Consoles]]<br />
[[Category:Home consoles]]<br />
[[Category:Fifth-generation video game consoles]]<br />
[[Category:Nintendo consoles]]<br />
[[Category:Nintendo 64 emulators|*]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Nintendo_64_emulators&diff=51006Nintendo 64 emulators2022-11-16T06:22:23Z<p>GPDP1: Update on RMG</p>
<hr />
<div>{{Infobox console<br />
|title = Nintendo 64<br />
|logo = Nintendo64Console.png<br />
|developer = [[:Nintendo]]<br />
|type = [[:Category:Home consoles|Home video game console]]<br />
|generation = [[:Category:Fifth-generation video game consoles|Fifth generation]]<br />
|release = 1996<br />
|discontinued = 2002<br />
|predecessor = [[Super Nintendo emulators|SNES]]<br />
|successor = [[GameCube emulators|GameCube]]<br />
|emulated = {{✓}}<br />
}}<br />
<br />
{{for|other emulators that run on N64 hardware|Emulators on N64}} <br />
<br />
The '''Nintendo 64''' is a 64-bit fifth-generation console released by Nintendo on September 29, 1996 for {{inflation|USD|199.99|1996}}.<br />
<br />
Nintendo was the second company approached by Silicon Graphics Inc. (SGI), who wanted to roll out their previously enterprise-only technology in the consumer space. They originally pitched their idea to Sega, but it's assumed that Nintendo's offer was more appealing. With the NEC VR4300 CPU clocked at 93.75 MHz, 4MB of RAM, and an SGI RCP GPU, Nintendo had finalized much of the hardware at least a year before launch, preventing video games from needing drastic rewrites as a result of architectural changes. A separate add-on was later released called the "Expansion Pak" that added an additional 4MB of RAM, totaling 8MB. The development workstations were often Unix-based, something that would later help reverse engineers in some projects.<br />
<br />
==Emulators==<br />
<div style="max-width:100%; overflow:auto;"><br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Platform(s)<br />
! scope="col"|Latest version<br />
! scope="col"|Plugins<br />
! scope="col"|Controller Pak<br />
! scope="col"|Rumble Pak<br />
! scope="col"|Transfer Pak<br />
! scope="col"|64DD<br />
! scope="col"|Depth<br/>output<br />
! scope="col"|Texture<br/>enhancement<br />
! scope="col"|Netplay<br />
! scope="col"|[[libretro]]<br />
! scope="col"|<abbr title="Free/Libre and Open-Source Software">FLOSS</abbr><br />
! scope="col"|Active<br />
! scope="col"|[[Recommended emulators|Recommended]]<br />
|-<br />
!colspan="15"|PC / x86<br />
|-<br />
|[[RetroArch|Mupen64Plus-Next (mupen64plus_next_libretro)]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/ nightly]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<ref group=N name=texture>Only supports texture packs, and not filtering or upscaling</ref><br />
|{{✓}}<br />
|{{✓}}<ref group=N name=libretro>Available exclusively as a libretro core</ref><br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[RMG]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/Rosalie241/RMG/releases {{RMGVer}}]<br >[https://github.com/Rosalie241/RMG/actions Dev]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<ref group=N name=Glide>Only with GLideN64</ref><br />
|{{✓}}<ref group=N name=Glide/><br />
|{{~}}<ref group=N name=input>Requires replacing the input plugin to one with netplay support</ref><br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Project64]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://www.pj64-emu.com/public-releases {{Project64Ver}}]<br >[https://www.pj64-emu.com/nightly-builds Dev] <br > [https://github.com/Rosalie241/PJ64Launcher/releases/latest keygen]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<ref group=N name=input/><br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[ares]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/ares-emulator/ares/releases {{aresVer}}]<br >[https://github.com/ares-emulator/ares/actions git]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|{{~}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[simple64]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/simple64/simple64/releases {{Simple64Ver}}]<br >[https://github.com/simple64/simple64/actions git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<ref group=N name=RMGMupen>Stick to RMG or Mupen64Plus-Next until dev finishes working out the timings.</ref><br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://github.com/mupen64plus/mupen64plus-core/releases git]<br/>[https://bitbucket.org/ecsv/mupen64plus-mxe-daily/downloads/ Dev Builds]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<ref group=N name=Glide/><br />
|{{✓}}<ref group=N name=Glide/><br />
|{{~}}<ref group=N name=input/><br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[BizHawk]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[http://tasvideos.org/BizHawk/ReleaseHistory.html {{BizHawkVer}}]<br/>[https://gitlab.com/TASVideos/BizHawk/-/pipelines Dev builds]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}[https://github.com/TASEmulators/BizHawk/issues/2454 *]<br />
|{{✓}}<ref group=N name=Glide/><br />
|{{✓}}<ref group=N name=Glide/><br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[1964]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://archive.org/details/goldeneye-007perfect-dark-1964-mouse-keyboard-60fps 1964 GEPD]<br />[http://www.emulation64.com/files/getfile/936/ 1.1] (Official)<br />[http://files.emulation64.fr/Emulateurs/EMU_1964_146.zip 1.2 r146] (Unofficial SVN)<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<ref group=N name=input/><br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<ref group=N name=1964GEPD>Recommended to use 1964 GEPD for Goldeneye 007 or Perfect Dark, this emulator is primarily made for GoldenEye/Perfect Dark and their ROM hacks. It has poor ROM support outside of these games.</ref><br />
|-<br />
|[[CEN64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/tj90241/cen64 git]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[RetroArch|ParaLLEl-N64 (parallel_n64_libretro)]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/ nightly]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{✓}}<ref group=N name=libretro/><br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<ref group=N name=obsolete>Obsolete and replaced by Mupen64Plus-Next</ref><br />
|-<br />
|simple64 (Final GLideN64)<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/thekovic/simple64/releases/tag/v2021.5.30 Final GLideN64]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<ref group=N name=RMGGlide>RMG with GLideN64 recommended.</ref><br />
|-<br />
|[[Project64 Netplay]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://github.com/Project64Netplay/Project64-Netplay-2x git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|Rokuyon<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/Hydr8gon/rokuyon git]<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[DaedalusX64]]<br />
|align=left|{{Icon|Linux|macOS}}<br />
|[https://github.com/DaedalusX64/daedalus/releases/latest git]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|{{✗}}<br />
|-<br />
|[[Sixtyforce]]<br />
|align=left|{{Icon|macOS}}<br />
|[http://sixtyforce.com/download/ {{SixtyforceVer}}]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Larper64<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://drive.google.com/file/d/1IWyw5UG9Uf24KG0zrcXSFoOmcQoHWmyc/view {{Larper64Ver}}]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|[[UltraHLE]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://web.archive.org/web/20070312015944/http://www.emuunlim.com/UltraHLE/ultrahle.zip 1.0]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|[[MAME]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[http://www.mamedev.org/release.html {{MAMEVer}}]<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[Ryu64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/Ryu64Emulator/Ryu64 git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|R64Emu<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/rasky/r64emu git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
!colspan="15"|Mobile / ARM<br />
|-<br />
|[[Mupen64Plus]] FZ<br />
|align=left|{{Icon|Android}}<br />
|[https://play.google.com/store/apps/details?id=org.mupen64plusae.v3.fzurita 3.0.322 (beta)]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<ref group=N name=texture/><br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Pandora|Pyra}}<br />
|[http://repo.openpandora.org/?page=detail&app=mupen64plus Pandora]<br/>[https://pyra-handheld.com/repo/apps/39 Pyra]<br />
|{{?}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
!colspan="15"|Consoles<br />
|-<br />
|[[Virtual Console]]<br />
|align=left|{{Icon|Wii|WiiU}}<br />
|N/A<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|[[DaedalusX64]]<br />
|align=left|{{Icon|PSP|3DS}}<br>{{Icon|Vita|PS2}}<br />
|[https://github.com/DaedalusX64/daedalus/releases/latest PSP]<br/>[https://github.com/masterfeizz/DaedalusX64-3DS/releases 3DS]<br/>[https://github.com/Rinnegatamante/DaedalusX64-vitaGL/releases VitaGL]<br/>[https://www.ps2-home.com/forum/viewtopic.php?f=99&p=39957#p39957 PS2]<br />
|?<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|{{✓}}<br/><small>(PSP)</small><br />
|-<br />
|Not64<br />
|align=left|{{Icon|GCN|Wii}}<br />
|[https://github.com/Extrems/Not64/releases/latest git]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|Surreal64 CE<br />
|align=left|{{Icon|Xbox}}<br />
|[https://digiex.net/threads/surreal64-ce-b6-0-download-n64-emulator-for-xbox.13677 Beta 6.0]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|mupen64-360<br />
|align=left|{{Icon|Xbox360}}<br />
|[https://digiex.net/threads/mupen64-360-xbox-360-nintendo-64-n64-emulator-download.9352 0.96 beta]<br />
|?<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|[https://code.google.com/p/mupen64gc/ Wii64]<br />
|align=left|{{Icon|GCN|Wii}}<br />
|[https://code.google.com/archive/p/mupen64gc/downloads 1.1 beta]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|}<br />
</div><br />
<references group=N /><br />
<br />
===Comparisons===<br />
Although many Nintendo 64 emulators have been made and many games can be run between them, until recently complete compatibility and/or accuracy left a bit to be desired. For half a decade, Mupen64Plus and Project64 have vied for the most playable emulator, and which was more compatible often depended on when and in what configuration each emulator has been tested. As of August 2017, both emulators have roughly equal compatibility and accuracy when running with the same [[recommended N64 plugins]] setup, though both default to Glide64, a now relatively lackluster plugin.<br />
<br />
;[[Mupen64Plus]]<br />
:A multi-platform emulator based on Hacktarux's Mupen64. It's about as accurate as Project64,<ref>loganmc10. [https://github.com/mupen64plus/mupen64plus-core/pull/336 ''Ignore TLB write if TLB entry is unmapping itself'']. "By the way, once this, along with the other PR's I have waiting are merged, we are at "compatibility parity" with Project64 as far as I can tell. I don't know of any game that doesn't boot with mupen64plus that works in PJ64."</ref> when both emulators are run with GLideN64. However, Mupen64Plus lacks a native GUI, instead being launched either from the command line or by dragging and dropping ROMs onto the executable and editing the config with a text editor. It also only comes bundled with outdated video plugins, so to ensure the best possible compatibility, sourcing better third-party plugins such as GLideN64 is a must. [[BizHawk]] and [[OpenEmu]] use forks of Mupen64Plus and its plugins for their N64 emulation, but they seem to be shallow. As of 2022 Project64-style overclocking for faster frame rates has been added under the option 'CountPerOpDenomPot'.<br />
<br />
:;Mupen64Plus-Next and ParaLLEl-N64<br />
:Both are heavily-modified forks developed as [[libretro]] cores. They introduce many features and optimizations not present in mainline alongside [[RetroArch]]'s general features, including 3-point texture filtering for Glide64, superior A/V sync and latency, and even an initially exclusive LLE Vulkan renderer based on Angrylion's pixel-perfect RDP plugin now known as ParaLLEl-RDP, making it a better alternative to the standalone version in some cases. 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.<br />
<br />
::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), considerably cleans up the Core Options menu for easier configuration and 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.<br />
<br />
:;[[simple64]]<br />
:A fork of Mupen64Plus with a custom-made Qt GUI. This is probably the easiest "just works out of the box" solution for Nintendo 64 emulation, as it comes bundled with ParaLLEl-RDP and ParaLLEl-RSP, ensuring both excellent compatibility and good speed without needing to mess with plugins or settings, provided your hardware supports Vulkan. However, unlike other emulators, it does not allow you to use other plugins. While it began as a shallow fork, it has increasingly become something closer to a hard fork, as its developer has opted to make various accuracy-focused changes to the emulation core that will require additional work to port back to upstream or to other forks. It also currently features only a cached interpreter core, as the dynarecs used by Mupen64Plus are incompatible with the core timing changes made by the developer. While this makes simple64 more accurate than most other N64 emulators, it also results in slower performance. If more speed and enhancements are desired, there is an older build that is closer to upstream and uses GLideN64 as its graphics plugin - unfortunately lacking the texture enhancement suite required for use of texture packs and upscaling.<br />
<br />
:;[[RMG]]<br />
:Rosalie's Mupen GUI is a project aiming to close the gap between Project64 and Mupen64Plus in terms of user experience. Its interface is about on par with simple64's in terms of cleanliness and ease of use, but unlike simple64, it allows you to use other plugins. The latest development versions come bundled with GLideN64, Angrylion RDP Plus and ParaLLEl-RDP for video plugins, and mupen64plus-hle-rsp, CXD4 and ParaLLEl-RSP for RSP plugins, though it can still use the older plugins that come with regular Mupen64Plus in case your PC cannot handle the newer plugins. If you prefer GLideN64, this is a superior alternative compared to simple64, as the last version of simple64 that uses GLideN64 is becoming increasingly outdated. However, it currently lacks proper Transfer Pak support from within the GUI.<br />
<br />
:;Wii64 and Not64<br />
:Both are based on Mupen64, with Not64 being a fork of Wii64. Not64 claims to be better optimized 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 releases whenever possible.<br />
<br />
;[[Project64]]<br />
: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 some of the Mupen64Plus attempts and supports features such as Transfer Pak emulation and 64DD emulation. It now comes with GLideN64 out-of-the-box, but the default audio plugin isn't even the best in the box. Annoyingly, it also nags you with a timed, unskippable message asking for donations to the project upon launch. It is thus recommended to download it through [https://github.com/Rosalie241/BetterMajorasMaskInstaller/releases/tag/4.0.2 Rosalie's BetterMajorasMaskInstaller], which downloads the latest nightly version of Project64 with the nagging message removed and installs several useful third-party plugins (it also downloads HD texture packs for OoT and MM, but you can opt out of that). For the most part, it works well in [[Wine]], but, if you're on a different platform, use Mupen64Plus instead.<br />
<br />
;[[Ares]]<br />
:An open-source multi-system emulator and successor to Near's [[higan]] project, with a mostly original N64 core. Unlike other N64 emulators, it aims for high accuracy and does not employ HLE RSP or RDP emulation of any kind, nor does it use game-specific hacks. It uses Themaister's ParaLLEl-RDP Vulkan renderer (with the MAME renderer as a software-based fallback) for pixel-perfect LLE graphics. While it is currently less compatible than Mupen64Plus or Project64, it is quickly catching up to them [https://ares-emu.net/compatibility/15 (only a handful of games are currently listed as partially or not working)], and it currently passes several stringent [https://github.com/ares-emulator/ares/pull/613 accuracy tests] the other emulators do not. However, it remains to be seen how accurate its developers are willing to make it [https://github.com/ares-emulator/ares/commit/3142bd3aef3a0b7c9d97517c70f41e0eb27542ea without compromising speed] and playability on current machines.<br />
<br />
;[[CEN64]]<br />
:Aims for cycle accuracy while at the same time aiming to eventually be usable on modern PC hardware. It lacks many features and has spotty compatibility, but it can already emulate some well-known edge cases such as picture recognition in Pokemon Snap. Unfortunately, its creator appears to have abandoned the project [https://github.com/n64dev/cen64/releases/tag/v0.3 citing lack of satisfaction with the program's performance in its current interpreter-based incarnation], and while the baton has been collectively passed to the n64dev community for further development, progress has been slow.<br />
<br />
;[[1964]]<br />
:Along with its various versions and forks, it was once a decent, speedy open-source alternative to Project64 and Mupen64, though it usually lagged behind the two compatibility-wise. Nowadays it has completely fallen off the radar as development has halted, and there is no longer a central code repo to speak of. There is little reason to use it nowadays outside of historical purposes, very specific edge cases, or if your device is too slow to run Mupen64Plus or Project64.<br />
<br />
;Daedalus<br />
:Is a Nintendo 64 emulator for PC which was ported to the PSP under the name of DaedalusX64. The PSP version later became the main version and got ported to platforms such as the Dreamcast, the PS2, the PS Vita, and the 3DS. On PSP, several games are able to reach full speed and most of them work with few emulation issues.<br />
<br />
;[[Sixtyforce]]<br />
:Is macOS-only, closed-source, and asks you to pay for full access to its features. It was once one of the only choices for Mac users, particularly those with older Macs since it's the only emulator with a <abbr title="Power PC">PPC</abbr> [[Dynamic recompilation|dynarec]]), but, with the switch to x86 and Mupen64Plus being ported to macOS, it has now become less relevant. However, development is still ongoing and is currently in its [https://sixtyforce.com/rosetta/ third rewrite] to support the upcoming [https://en.wikipedia.org/wiki/Apple-designed_processors Apple Silicon].<br />
<br />
;[[UltraHLE]]<br />
: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.<br />
<br />
;[[Ryu64]]<br />
:Is a Nintendo 64 emulator made in C#. The 'Ryu' word is named after the "RyuJIT" used in both Visual Basic & C#. But it might have been inspired by the lead author's sole (so far) [https://github.com/Ryujinx/Ryujinx/commits?author=Dudejoe870 commit] at Switch emulator, [[Ryujinx]]'s Git repository, and his depreciated [https://github.com/Dudejoe870/RyujinxAutoUpdate Ryujinx Auto Updater] tool. "86RYU", an x86 JIT compiler, is being developed alongside this emulator too.<br />
<br />
;[[BizHawk]]<br />
:Another out-of-the-box solution (supports GLideN64 and Angrylion) for n64.<br />
<br />
;n64oid<br />
:An Android exclusive Nintendo 64 emulator. It is similar to Project 64 1.6 in terms of compatibility, although it is unknown who authored it, as the APK for n64oid circulates on many legally questionable APK sites. n64oid has the infamous problem in Mario Kart 64 of the screen in Wario Stadium not displaying properly, as it displays nothing but black. It upscales all games to widescreen, which works well most of time, but on many phones it will have performance issues. The emulator is relatively poor, but it is much easier to set up than other options. The emulator features a menu with many similarities to the mobile edition of Snes9x EX+, and the My Boy! family of Android emulators for Game Boy systems.<br />
<br />
==Emulation issues==<br />
{{Main|Recommended N64 plugins}}<br />
<br />
Nintendo 64 emulation is now decent. A lot of the major problems that N64 emulation had in the past, have been fixed for quite some time now. The only catch is that the accurate emulators have higher system requirements. The main remaining problem is the lack of accurate cycle counting.<br />
<br />
===[[High/Low level emulation|High-level vs. low-level]] graphics===<br />
<br />
One of the biggest hurdles to emulating the Nintendo 64 was the Reality Display Processor (RDP), which used a custom design that had to be fine-tuned to get more performance out of the system using microcode. To emulate the RDP accurately, one would have to execute said microcode the way the RDP did, which differed from PC graphics cards of the day. To complicate matters further, API standards that were available on PCs two decades ago were nowhere near as flexible as they are today. If you wanted to make an accurate GPU-accelerated RDP plugin in 2003, you simply couldn't with the APIs of the time (OpenGL 1.x and Direct3D 9). For the average user, hardware-accurate GPU acceleration would be out of reach for a long time.<br />
<br />
[[UltraHLE]] offered a compromise. In contrast to earlier consoles, whose video chips in hindsight had been easy to render to the host CPU's framebuffer, performant RDP emulation had to take shortcuts, including programming around specific games' microcode to cleanly translate their graphics commands into API calls using Direct3D, OpenGL, and even Glide. With this, the theoretical system requirements plummeted, 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 is an improvement is subjective and a common point of discussion. Unfortunately it proved to be hit and miss, owing to the nature of per-game microcode detection and having to tweak settings to prevent some games from running into graphical glitches.<br />
<br />
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).<br />
<br />
On the high-level side, gonetz and one or two assistants spent a large portion of development improving GlideN64's microcode handling 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 framebuffer is used as well as performance issues), VI emulation, and how combine/blending modes are emulated (such as noise issues and combiner accuracy).<br />
<br />
<gallery widths="300" mode="packed"><br />
Majora's mask accurate.png| Low-level emulation of Majora's Mask using SoftGraphic<br />
Project64 2013-07-26 14-20-17-55.png| High-level emulation of Majora's Mask using Jabo's Direct3D<br />
</gallery><br />
<br />
===[[Texture filtering]]===<br />
The Nintendo 64 was the first consumer device to be able to filter textures when rendering 3D objects. However, unlike every console and PC graphics card made after the N64, its implementation of bilinear was primitive in that, in order to reduce strain on the system, it only used three samples as opposed to four, resulting in slightly jagged, asymmetrically-filtered textures. Instead of faithfully applying this "imperfect" version of bilinear filtering, HLE plugins instead applied conventional bilinear filtering, interpolating straight from the source texture up to the output resolution the same way a PC game would. While that method is technically superior, it can result in textures that look even blurrier than on real hardware.<br />
<br />
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 pre-rendered backgrounds or menu screens, may look as though they are separated into squares (see images below; note how OoT's Quest Status screen appears to be divided into a grid). 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 oftentimes low resolutions.<br />
<br />
Modern emulators and plugins have taken some steps which help remedy these problems. For instance, GLideN64 now supports N64-style three-point texture filtering, which results in a more faithful look. It is also capable of rendering at 320x240, which sidesteps the issues with filtered text, UI elements, and menu screens, while still retaining texture filtering. Pixel-accurate plugins such as Angrylion and ParaLLEl-RDP do not have these problems at all.<br />
<gallery widths="300" mode="packed"><br />
Project64_2013-06-26_17-44-58-31.png|Conker's Bad Fur Day copyright screen, displaying issues with filtered text.<br />
Mupen64plus_2013-08-18_20-35-50-08.png|Ocarina of Time's menu subscreen, displaying issues with filtering.</gallery><br />
<br />
===Timing issues===<br />
One of the biggest remaining problems in N64 emulation is lack of accurate core timings, which in practice means games do not always run at the speed they would on real hardware. While this technically affects all games, the majority are only affected to a negligible degree, and in some instances (particularly in Rare games) this can actually result in less framerate drops and lag, which can be seen as beneficial. However, some game engines actually depend on accurate timings for proper game behavior, and not properly emulating them can result in considerable to major issues. Some notable examples include the following:<br />
* Intros and cutscenes playing too fast and not properly syncing up with musical cues. Seen in Goldeneye's intro and Body Harvest's beginning cutscene.<br />
* Gameplay demos running at hyper speed. Earthworm Jim 3D is most notorious for this, though the main game itself is largely unaffected.<br />
* Game physics not working properly due to being tied to framerate. A good example is Donkey Kong 64, which is programmed to boost the character's speed and momentum proportional to in-game lag (most likely to make up for the game's frequent framerate drops), which can be exploited for certain glitches and sequence breaks on real hardware. Emulators currently run the game too well and with too little lag, making most of these tricks impossible to pull off.<br />
* Possibly the most affected game is Knife's Edge, which runs like it's on permanent fast-forward, making it all but unplayable. Messing with timing-related settings such as CounterFactor can mitigate this somewhat, but nowhere near enough to fix the issue.<br />
Fortunately, tackling these problems has recently become a core focus of development in some N64 emulators, and attempts are underway to improve the situation. [[Ares]] currently has the most accurate timings overall, and already runs Earthworm Jim 3D's demos much better than other emulators. Meanwhile, [[simple64]] has recently pushed various timing-related commits aimed at improving accuracy, and as a result it may now be the only emulator that runs Donkey Kong 64 properly. As these efforts progress, it should be noted that a side-effect of improved timings may be greater in-game lag. This should not be seen as the emulator becoming slower, but rather the emulator behaving exactly like real hardware does, as many N64 games were notorious for framerate drops.<br />
<br />
==Peripherals==<br />
===Voice Recognition Unit emulation===<br />
The Voice Recognition Unit (VRU) is an accessory used primarily by ''Hey You, Pikachu''. No emulator or input plugin supports this, although there is an on-going effort to get it working.<ref name="emutalk">{{cite web|url=http://www.emutalk.net/threads/55279|title=Hey You! Pikachu - Possible HLE Implementation|publisher=emutalk|accessdate=2018-06-17|date=2014-10-27, Last edit: 2016-04-04}}</ref><br />
===''Densha De Go!'' Controller===<br />
Also available for the [[PlayStation emulators|PlayStation]], ''Densha De Go! 64'' is a Japan-only train simulator released by [[Wikipedia:Taito|Taito]] that is compatible with an optional special controller that plugs into the player 3 port.<ref name="ArcadeUSA">{{cite web|url=https://www.youtube.com/watch?v=cCcPAGhcnck|title=Densha De Go! Nintendo 64 Controller!|publisher=YouTube|accessdate=2018-06-17|date=2017-01-20}}</ref> No emulator supports it.<br />
<br />
===Pokémon Snap Station===<br />
There was a special kiosk designed to promote ''Pokémon Snap'' called the ''Pokémon Snap Station'', which is also compatible with the North American ''Pokémon Stadium'' with its gallery mode. It is just a Nintendo 64 with special hardware designed for the station.<ref name="Sixty Formula">{{cite web|url=https://www.youtube.com/watch?v=AMbjvGvPkV4|title=The Pokemon Snap Station|publisher=YouTube|accessdate=2018-06-17|date=2016-05-21}}</ref><ref name="MetalJesusRocks">{{cite web|url=https://www.youtube.com/watch?v=5_UGpRN6AnM&t=3m35s|title=VIDEO GAME KIOSKS - Extreme Game Collecting!|publisher=YouTube|accessdate=2018-06-17|date=2016-05-25}}</ref> Although the special cartridge boots in emulators compatible with the regular version, the printing functions are inaccessible due to no emulation of the printer for the player 4 slot, credit system, or the special board to switch between the regular and special cartridges.<br />
<br />
===Transfer Pak emulation===<br />
A few games, such as ''Mario Golf'', ''Mario Tennis'', ''Mario Artist: Paint Studio'', and the ''Pokémon Stadium'' games, can use the Transfer Pak, an attachment that allows interfacing with specific [[Game Boy/Game Boy Color emulators|Game Boy/Color]] games for certain features. Most N64 emulators can emulate the Transfer Pak's functionality to one degree or another, with the most robust being Project64 with N-Rage's input plugin, but a couple of things are difficult to emulate or are not emulated at all:<br />
<br />
*Taking pictures with the Japanese ''Game Boy Camera'' (called ''Pocket Camera'') while in Transfer Pak mode playing ''Mario Artist: Paint Studio'' displays static.<br />
*Playing the Gen 1 and 2 Pokemon games through the Game Boy Tower in Pokemon Stadium 1 and 2 is notoriously finicky. At the moment, only Project64, using the N-Rage input plugin, can properly load either game's Game Boy Tower at all, with other emulators either crashing or failing to establish the connection. Even here, extra steps must be taken: for Pokemon Stadium 2, simply set the CPU core to Interpreter and Counter factor set to 1 in the emulator's game settings. For the first Stadium game, in addition to the aforementioned settings, Delay SI Interrupt must also be turned on, and an LLE RSP plugin other than the default Projec64 RSP must be used, such as ParaLLEl-RSP.<br />
<br />
===64DD emulation===<br />
The 64DD (an abbreviation for "64 Disk Drive") was a peripheral which allowed a proprietary disk format to be used with the N64. These disks had more space at a cheaper manufacturing cost. The peripheral was a commercial failure and was never released outside of Japan. Internal evidence suggests that, much like the GBA e-Reader, it wasn't even intended for a European release.<br />
<br />
Expansion disks are region-coded to either Japan or the US (obviously unused) and won't work with N64 games from the wrong region. Only F-Zero X has an official disk, but Ocarina of Time, Mario Party, and Pokemon Stadium (JP) have fully implemented but unused disk support.<br />
<br />
The special AV-In cartridge (NUS-028) that ''Mario Artist: Talent Studio'' can use doesn't work because it requires an RCA cable signal.<br />
<br />
Recently, there has been an effort to emulate the 64DD, and now [[Project64]] and [[MAME]] can run several commercial 64DD games as part of its N64 emulator. This is being ported to [[CEN64]] with the help of [https://twitter.com/LuigiBlood LuigiBlood]. The latest newcomer is Mupen64Plus which is the base of other emulators such as [[simple64]] and [[RMG]].<br />
<br />
<div style="max-width:100%; overflow:auto;"><br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Platform(s)<br />
! scope="col"|Latest Version<br />
! scope="col"|N64 Mouse<br />
! scope="col"|64DD Emulation<br />
! scope="col"|Active<br />
! scope="col"|[[Recommended emulators|Recommended]]<br />
|-<br />
! colspan="7"|PC / x86<br />
|-<br />
|[[RetroArch|Mupen64Plus-Next (mupen64plus_next_libretro)]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/ nightly]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Project64]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://64dd.org/downloads.html 64DD.org Builds]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[ares]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/ares-emulator/ares/releases {{aresVer}}]<br >[https://github.com/ares-emulator/ares/actions git]<br />
|{{✓}}<br />
|[https://twitter.com/LuigiBlood/status/1568694009496756225 High]<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[RetroArch|ParaLLEl-N64 (parallel_n64_libretro)]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/ nightly]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[CEN64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/tj90241/cen64 git]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[MAME]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[http://www.mamedev.org/release.html {{MAMEVer}}]<br />
|{{✗}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[simple64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/simple64/simple64/releases {{Simple64Ver}}]<br >[https://github.com/simple64/simple64/actions git]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|?<br />
|-<br />
|[[RMG]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/Rosalie241/RMG/releases {{RMGVer}}]<br >[https://github.com/Rosalie241/RMG/actions Dev]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|?<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://github.com/mupen64plus/mupen64plus-core/releases git]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|?<br />
|}<br />
</div><br />
<br />
* Project64's latest versions emulate the N64 mouse and can load Zoinkity's hacked 64DD cartridge conversions at playable speeds. You'll need to set every game to have 8MB of Memory by default manually. Games do not save, some need "32-bit engine" to be unchecked (like Talent Studio), and some (like Polygon Studio to fix models and Paint Studio to fix stamps) need the Angrylion GFX plugin rather than GlideN64, which does the job for the rest.<br />
**The 64DD hardware started to be emulated around 2.3's release with the help of [https://github.com/LuigiBlood LuigiBlood]. Saving works but in the form of NDR files. NDR files are copied versions of NDD images with save data included as to not write to the clean unaltered images. In order to play 64DD games in their original forms, 8MB of memory is still needed because the real hardware needed the Expansion Pak upgrade. The IPL is also needed.<br />
<br />
* MAME includes early basic 64DD emulation as well but is much slower. Disk images need to be in head/track format. See [https://github.com/Happy-yappH/ddconvert.git here] for more information. It does not currently support disk swapping or saving disk to files. Writes only update the copy in memory, and, once the MAME process ends, the changes are lost. Current usage: <code>mame n64dd -quickload disk -cart cart -nodrc</code> (both disk and cart are optional)<br />
<br />
* CEN64, like Project64, had 64DD emulation ported to it from MAME. However, it focuses on accuracy and plays much slower than other emulators, aside from the 64DD emulation itself is imperfect.<br />
<br />
==Hardware variants==<br />
===iQue Player emulation===<br />
Before the GBA, DS, and 3DS, Nintendo released a modified version of their Nintendo 64 system for the Chinese market, which was called the iQue Player, through their not-quite-subsidiary iQue. Fourteen games were translated into Simplified Chinese, including Sin and Punishment, Ocarina of Time (the Majora's Mask port was canceled), Super Mario 64, and others.<br />
<br />
Unlike the Chinese releases of their more recent systems and their games, iQue Player releases are regular N64 roms wrapped with several layers of encryption, as well as a ticket and signature system like that on Wii, DSi, 3DS, Wii U, and Switch. The Chinese ROM-hacking scene is very active though and has translated the Japanese regular N64 releases for many of these to their language already, which explains some of the Chinese ROMs floating for those. However, recently, almost all pieces of iQue Player software were decrypted to regular .z64 ROM format.<br />
<br />
Several of the Chinese game localizations already run on N64 emulators, but as some hardware features of the iQue Player are not yet supported, some games, as well as the system menu and features in games such as saving, do not work yet.<br />
<br />
===Aleck 64 arcade emulation===<br />
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). 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.<br />
<br />
The Aleck 64 ROMs were dumped, and Zoinkity is working on converting them to regular N64 ROMs (with controls remapped to N64 controller buttons). They generally require an 8MB Expansion Pak to run at all and 4K EEPROM to save settings and scores. The ones covered by these patches are:<br />
<br />
* Donchan Puzzle Hanabi de Doon!<br />
* Eleven Beat: World Tournament<br />
* Hi Pai Paradise<br />
* Hi Pai Paradise 2<br />
* Kuru Kuru Fever<br />
* Magical Tetris Challenge<br />
* Mayjinsen 3 / Meijin-Sen<br />
* Star Soldier: Vanishing Earth (also ported to N64)<br />
* Super Real Mahjong VS<br />
* Tower & Shaft<br />
* Vivid Dolls (official eroge game on a Nintendo console)<br />
<br />
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.<br />
<br />
The remaining ones from the system's library not yet covered are:<br />
* Rev Limit<br />
* Variant Schwanzer<br />
<br />
==Virtual Console games in Dolphin==<br />
A number of N64 games were released for the Wii's Virtual Console service throughout its lifespan. While the emulators at the heart of each Virtual Console title were of average accuracy (rather than using one generic emulator used for every game, each title had an emulator specifically tailored to that game), they were good enough to render the games in full playable capacity with few to no glaring errors. Many of these titles are emulated well through Dolphin, and for a good while, due to persistent long-standing inaccuracies in N64 emulators and plugins, this was the best way to emulate certain N64 games, particularly Pokemon Snap and Mario Tennis. The system requirements are much higher than running them on regular N64 emulators, but it's doable for many games. Today, regular N64 emulators and plugins have advanced to the degree that this has become unnecessary, relegating this method of N64 game emulation to little more than a curiosity, at least on PC.<br />
<br />
The following games are on the N64 Virtual Console for Wii:<br />
<br />
{|width="100%"<br />
|- valign="top"<br />
|<br />
* 1080 Snowboarding<br />
* Bomberman Hero<br />
* Cruis'n USA<br />
* Custom Robo V2 (Japan only)<br />
* F-Zero X<br />
* Kirby 64: The Crystal Stars<br />
* The Legend of Zelda: Majora's Mask<br />
* The Legend of Zelda: Ocarina of Time<br />
|<br />
* Mario Golf<br />
* Mario Kart 64<br />
* Mario Party 2<br />
* Mario Tennis<br />
* Ogre Battle 64: Person of Lordly Caliber<br />
* Paper Mario<br />
* Pokemon Puzzle League<br />
|<br />
* Pokemon Snap<br />
* Sin & Punishment (English)<br />
* Star Fox 64<br />
* Super Mario 64<br />
* Super Smash Bros.<br />
* Wave Race 64<br />
* Yoshi's Story<br />
|}<br />
<br />
==References==<br />
<references/><br />
<br />
{{Nintendo}}<br />
<br />
[[Category:Consoles]]<br />
[[Category:Home consoles]]<br />
[[Category:Fifth-generation video game consoles]]<br />
[[Category:Nintendo consoles]]<br />
[[Category:Nintendo 64 emulators|*]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=NanoBoyAdvance&diff=50547NanoBoyAdvance2022-10-17T00:02:11Z<p>GPDP1: How about we not descend into dumb edit warfare over dumb shit no one cares about and settle on a compromise</p>
<hr />
<div>{{Infobox emulator<br />
|logo =<br />
|logowidth =<br />
|version = 1.6 <small>(Stable)</small><br />
|active = Yes<br />
|platform = [[Emulators on Windows|Windows]]<br/>[[Emulators on Linux|Linux]]<br/>[[Emulators on macOS|macOS]]<br />
|target = [[Game Boy Advance emulators|Game Boy Advance]]<br />
|developer = [https://twitter.com/fleroviux fleroviux]<br />
|website =<br />
|source = [https://github.com/nba-emu/NanoBoyAdvance GitHub]<br />
|license = GNU GPLv3<br />
|compatibility =<br />
|bios = [[Emulator_Files#Game Boy Advance / e-Reader|Optional]]<br />
}}<br />
<br />
'''NanoBoyAdvance''' is a free and open-source [[GBA emulators|GBA emulator]] licensed under GPU GPL 3.0 license or later, and focused on accuracy (according to the developer, the goal is to achieve fully cycle-accurate emulation in the future<ref>https://www.reddit.com/r/emulation/comments/rky15h/nanoboyadvance_14_is_released/</ref>), with support for HQ audio mixer (for games which employ Nintendo's MusicPlayer2000 sound engine), RTC emulation, post-processing options and support for controllers. NBA was the first emulator to pass all AGS aging cartridge tests. NBA emulates CPU/DMA with almost-cycle accuracy and its ARM emulation handles nearly all known edge-cases.<br />
<br />
NBA can use it a real console's dumped BIOS or the alternative [https://github.com/Nebuleon/ReGBA/blob/master/bios/gba_bios.bin free alternative not containing copyrighted content] although the latter is less accurate.<br />
<br />
==References==<br />
{{Reflist}}<br />
<br />
==External links==<br />
*[https://github.com/nba-emu/NanoBoyAdvance/releases Latest stable release]<br />
*[https://nightly.link/nba-emu/NanoBoyAdvance/workflows/build/master Nightly builds' repository]<br />
<br />
{{Game Boy Advance emulators}}<br />
[[Category:Emulators]]<br />
[[Category:Console emulators]]<br />
[[Category:Handheld console emulators]]<br />
[[Category:Game Boy Advance emulators]]<br />
[[Category:Windows emulation software]]<br />
[[Category:macOS emulation software]]<br />
[[Category:Linux emulation software]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Talk:Nintendo_64_emulators&diff=50196Talk:Nintendo 64 emulators2022-09-26T18:50:45Z<p>GPDP1: /* What's Depth output? */</p>
<hr />
<div>>Its developers have expressed intentions to eventually rewrite the core and brand it as its own emulator, called ParaLLEl.<br />
<br />
Hey, it looks like ParaLLEl is already available in Retroarch. I don't know how good it is exactly as I've only tried Paper Mario so far, but there's no flickering in it as mentioned on the mupen64 comparability wiki. -Anon<br />
<br />
== Graphics comparison table ==<br />
<br />
The main page of the N64 emus is too large probably, so I put this here as a backup source. I've already added it to the Resources sector at three other pages (for 3 comparable systems). [[User:ObiKKa|ObiKKa]] ([[User talk:ObiKKa|talk]]) 18:17, 28 April 2019 (EDT)<br />
<br />
* [https://segaretro.org/Sega_Saturn/Hardware_comparison#Graphics_comparison_table Graphics comparison table] (for Saturn as opposed to PS1, N64, Sega Model 2 arcade hardware and 1995-era PC)<br />
<br />
== What's Depth output? ==<br />
<br />
LLE emulators would support it. If GlideN64 calls that "Use emulator help to read/write frame buffers" option, I think Project64 is not supported.<br />
<br />
I was wondering about this as well. Does it refer perhaps to the N64-style depth compare option in GLideN64? Because Mupen64Plus-Next has that option, unless it's not working for some reason.</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Nintendo_64_emulators&diff=50137Nintendo 64 emulators2022-09-23T02:29:40Z<p>GPDP1: /* Transfer Pak emulation */</p>
<hr />
<div>{{Infobox console<br />
|title = Nintendo 64<br />
|logo = Nintendo64Console.png<br />
|developer = [[:Nintendo]]<br />
|type = [[:Category:Home consoles|Home video game console]]<br />
|generation = [[:Category:Fifth-generation video game consoles|Fifth generation]]<br />
|release = 1996<br />
|discontinued = 2002<br />
|predecessor = [[Super Nintendo emulators|SNES]]<br />
|successor = [[GameCube emulators|GameCube]]<br />
|emulated = {{✓}}<br />
}}<br />
<br />
{{for|other emulators that run on N64 hardware|Emulators on N64}} <br />
<br />
<br />
The '''Nintendo 64''' is a 64-bit fifth-generation console released by Nintendo on September 29, 1996 for {{inflation|USD|199.99|1996}}.<br />
<br />
Nintendo was the second company approached by Silicon Graphics Inc. (SGI), who wanted to roll out their previously enterprise-only technology in the consumer space. They originally pitched their idea to Sega, but it's assumed that Nintendo's offer was more appealing. With the NEC VR4300 CPU clocked at 93.75 MHz, 4MB of RAM,<ref group=N>Though a separate add-on was later released called the "Expansion Pak" that added an additional 4MB of RAM, totaling 8MB.</ref> and an SGI RCP GPU, Nintendo had finalized much of the hardware at least a year before launch, preventing video games from needing drastic rewrites as a result of architectural changes. The development workstations were often Unix-based, something that would later help reverse engineers in some projects.<br />
<br />
==Emulators==<br />
<div style="max-width:100%; overflow:auto;"><br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Platform(s)<br />
! scope="col"|Latest version<br />
! scope="col"|Plugins<br />
! scope="col"|Controller Pak<br />
! scope="col"|Rumble Pak<br />
! scope="col"|Transfer Pak<br />
! scope="col"|64DD<br />
! scope="col"|Depth<br/>output<br />
! scope="col"|Texture<br/>enhancement<br />
! scope="col"|Netplay<br />
! scope="col"|[[libretro]]<br />
! scope="col"|<abbr title="Free/Libre and Open-Source Software">FLOSS</abbr><br />
! scope="col"|Active<br />
! scope="col"|[[Recommended emulators|Recommended]]<br />
|-<br />
!colspan="15"|PC / x86<br />
|-<br />
|[[simple64]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/simple64/simple64/releases {{Simple64Ver}}]<br >[https://github.com/simple64/simple64/actions git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[RetroArch|Mupen64Plus-Next (mupen64plus_next_libretro)]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/windows/x86_64/latest/ nightly]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}¹<br />
|{{✓}}<br />
|{{✓}}*<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[RMG]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/Rosalie241/RMG/releases {{RMGVer}}]<br >[https://github.com/Rosalie241/RMG/actions Dev]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}⁴<br />
|{{✓}}⁴<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Project64]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://www.pj64-emu.com/public-releases {{Project64Ver}}]<br >[https://www.pj64-emu.com/nightly-builds Dev]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[ares]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/ares-emulator/ares/releases {{aresVer}}]<br >[https://github.com/ares-emulator/ares/actions git]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|{{~}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://github.com/mupen64plus/mupen64plus-core/releases git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}⁴<br />
|{{✓}}⁴<br />
|{{~}}²<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[RetroArch|ParaLLEl-N64 (parallel_n64_libretro)]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/windows/x86_64/latest/ nightly]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{✓}}*<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}⁵<br />
|-<br />
|[[1964]]<br />
|align=left|{{Icon|Windows}}<br />
|[http://www.emulation64.com/files/getfile/936/ 1.1] (Official)<br />[http://files.emulation64.fr/Emulateurs/EMU_1964_146.zip 1.2 r146] (Unofficial SVN)<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}³<br />
|-<br />
|simple64 (Final GLideN64)<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/thekovic/simple64/releases/tag/v2021.5.30 Final GLideN64]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}⁶<br />
|-<br />
|[[BizHawk]]<br />
|align=left|{{Icon|Windows}}<br />
|[http://tasvideos.org/BizHawk/ReleaseHistory.html {{BizHawkVer}}]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}[https://github.com/TASEmulators/BizHawk/issues/2454 *]<br />
|{{✓}}⁴<br />
|{{✓}}⁴<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[CEN64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/tj90241/cen64 git]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[Project64 Netplay]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://github.com/Project64Netplay/Project64-Netplay-2x git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[DaedalusX64]]<br />
|align=left|{{Icon|Linux|macOS}}<br />
|[https://github.com/DaedalusX64/daedalus/releases/latest git]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|{{✗}}<br />
|-<br />
|[[Sixtyforce]]<br />
|align=left|{{Icon|macOS}}<br />
|[http://sixtyforce.com/download/ {{SixtyforceVer}}]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Larper64<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://drive.google.com/file/d/1IWyw5UG9Uf24KG0zrcXSFoOmcQoHWmyc/view {{Larper64Ver}}]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|[[UltraHLE]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://web.archive.org/web/20070312015944/http://www.emuunlim.com/UltraHLE/ultrahle.zip 1.0]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|[[MAME]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[http://www.mamedev.org/release.html {{MAMEVer}}]<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[Ryu64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/Ryu64Emulator/Ryu64 git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|R64Emu<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/rasky/r64emu git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
!colspan="15"|Mobile / ARM<br />
|-<br />
|[[Mupen64Plus]] FZ<br />
|align=left|{{Icon|Android}}<br />
|[https://play.google.com/store/apps/details?id=org.mupen64plusae.v3.fzurita 3.0.322 (beta)]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}¹<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Pandora|Pyra}}<br />
|[http://repo.openpandora.org/?page=detail&app=mupen64plus Pandora]<br/>[https://pyra-handheld.com/repo/apps/39 Pyra]<br />
|?<br />
|{{✓}}<br />
|?<br />
|?<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
!colspan="15"|Consoles<br />
|-<br />
|[[Virtual Console]]<br />
|align=left|{{Icon|Wii|WiiU}}<br />
|N/A<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[DaedalusX64]]<br />
|align=left|{{Icon|PSP|3DS}}<br>{{Icon|Vita|PS2}}<br />
|[https://github.com/DaedalusX64/daedalus/releases/latest PSP]<br/>[https://github.com/masterfeizz/DaedalusX64-3DS/releases 3DS]<br/>[https://github.com/Rinnegatamante/DaedalusX64-vitaGL/releases VitaGL]<br/>[https://www.ps2-home.com/forum/viewtopic.php?f=99&p=39957#p39957 PS2]<br />
|?<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|{{✓}}<br/><small>(PSP)</small><br />
|-<br />
|Not64<br />
|align=left|{{Icon|GCN|Wii}}<br />
|[https://github.com/Extrems/Not64/releases/latest git]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|Surreal64 CE<br />
|align=left|{{Icon|Xbox}}<br />
|[https://digiex.net/threads/surreal64-ce-b6-0-download-n64-emulator-for-xbox.13677 Beta 6.0]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|mupen64-360<br />
|align=left|{{Icon|Xbox360}}<br />
|[https://digiex.net/threads/mupen64-360-xbox-360-nintendo-64-n64-emulator-download.9352 0.96 beta]<br />
|?<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|[https://code.google.com/p/mupen64gc/ Wii64]<br />
|align=left|{{Icon|GCN|Wii}}<br />
|[https://code.google.com/archive/p/mupen64gc/downloads 1.1 beta]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|}<br />
</div><br />
<br />
*<nowiki>* Available exclusively as a libretro core</nowiki><br />
*<nowiki>¹ Only supports texture packs, and not filtering or upscaling</nowiki><br />
*<nowiki>² Requires replacing the input plugin to one with netplay support</nowiki><br />
*<nowiki>³ Highly recommended to use 1964 GEPD for Goldeneye 007 or Perfect Dark</nowiki><br />
*<nowiki>⁴ Only with GLideN64</nowiki><br />
*<nowiki>⁵ Obsolete and replaced by Mupen64Plus-Next</nowiki><br />
*<nowiki>⁶ RMG with GLideN64 recommended.</nowiki><br />
<br />
===Comparisons===<br />
Although many Nintendo 64 emulators have been made and many games can be run between them, until recently complete compatibility and/or accuracy left a bit to be desired. For half a decade, Mupen64Plus and Project64 have vied for the most playable emulator, and which was more compatible often depended on when and in what configuration each emulator has been tested. As of August 2017, both emulators have roughly equal compatibility and accuracy when running with the same [[recommended N64 plugins]] setup, though both default to Glide64, a now relatively lackluster plugin.<br />
<br />
;[[Mupen64Plus]]<br />
:A multi-platform emulator based on Hacktarux's Mupen64. It's about as accurate as Project64,<ref>loganmc10. [https://github.com/mupen64plus/mupen64plus-core/pull/336 ''Ignore TLB write if TLB entry is unmapping itself'']. "By the way, once this, along with the other PR's I have waiting are merged, we are at "compatibility parity" with Project64 as far as I can tell. I don't know of any game that doesn't boot with mupen64plus that works in PJ64."</ref> when both emulators are run with GLideN64. However, Mupen64Plus lacks a native GUI, instead being launched either from the command line or by dragging and dropping ROMs onto the executable and editing the config with a text editor. It also only comes bundled with outdated video plugins, so to ensure the best possible compatibility, sourcing better third-party plugins such as GLideN64 is a must. [[BizHawk]] and [[OpenEmu]] use forks of Mupen64Plus and its plugins for their N64 emulation, but they seem to be shallow. As of 2022 Project64-style overclocking for faster frame rates has been added under the option 'CountPerOpDenomPot'.<br />
<br />
:;Mupen64Plus-Next and ParaLLEl-N64<br />
:Both are heavily-modified forks developed as [[libretro]] cores. They introduce many features and optimizations not present in mainline alongside [[RetroArch]]'s general features, including 3-point texture filtering for Glide64, superior A/V sync and latency, and even an initially exclusive LLE Vulkan renderer based on Angrylion's pixel-perfect RDP plugin now known as ParaLLEl-RDP, making it a better alternative to the standalone version in some cases. 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.<br />
<br />
::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), considerably cleans up the Core Options menu for easier configuration and 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.<br />
<br />
:;[[simple64]]<br />
:A fork of Mupen64Plus with a custom-made Qt GUI. This is probably the easiest "just works out of the box" solution for Nintendo 64 emulation, as it comes bundled with ParaLLEl-RDP and ParaLLEl-RSP, ensuring both excellent compatibility and good speed without needing to mess with plugins or settings, provided your hardware supports Vulkan. However, unlike other emulators, it does not allow you to use other plugins. While it began as a shallow fork, it has increasingly become something closer to a hard fork, as its developer has opted to make various accuracy-focused changes to the emulation core that will require additional work to port back to upstream or to other forks. It also currently features only an interpreter core, as the dynarecs used by Mupen64Plus are incompatible with the core timing changes made by the developer. While this makes simple64 more accurate than most other N64 emulators, it also results in slower performance. If more speed and enhancements are desired, there is an older build that is closer to upstream and uses GLideN64 as its graphics plugin - unfortunately lacking the texture enhancement suite required for use of texture packs and upscaling.<br />
<br />
:;[[RMG]]<br />
:Rosalie's Mupen GUI is a project aiming to close the gap between Project64 and Mupen64Plus in terms of user experience. Its interface is about on par with simple64's in terms of cleanliness and ease of use, but unlike simple64, it allows you to use other plugins. The latest version comes bundled with GLideN64 and ParaLLEl-RDP for video plugins, and mupen64plus-hle-rsp and ParaLLEl-RSP for RSP plugins, though it can still use the older plugins that come with regular Mupen64Plus in case your PC cannot handle the newer plugins. However, it currently does not allow you access to ParaLLEl-RDP's options within its GUI, so if you wish to make use of features such as upscaling or downsampling, you must do so by editing the mupen64plus.cfg file, whereas simple64 does expose these options in its GUI. However, if you prefer GLideN64, this is a superior alternative, as it does have access to its settings GUI, and the last version of simple64 that uses GLideN64 is becoming increasingly outdated.<br />
<br />
:;Wii64 and Not64<br />
:Both are based on Mupen64, with Not64 being a fork of Wii64. Not64 claims to be better optimized 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 releases whenever possible.<br />
<br />
;[[Project64]]<br />
: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 some of the Mupen64Plus attempts and supports features such as Transfer Pak emulation and 64DD emulation. It now comes with GLideN64 out-of-the-box, but the default audio plugin isn't even the best in the box. Annoyingly, it also nags you with a timed, unskippable message asking for donations to the project upon launch. It is thus recommended to download it through [https://github.com/Rosalie241/BetterMajorasMaskInstaller/releases/tag/4.0.2 Rosalie's BetterMajorasMaskInstaller], which downloads the latest nightly version of Project64 with the nagging message removed and installs several useful third-party plugins (it also downloads HD texture packs for OoT and MM, but you can opt out of that). For the most part, it works well in [[Wine]], but, if you're on a different platform, use Mupen64Plus instead.<br />
<br />
;[[Ares]]<br />
:An open-source multi-system emulator and successor to Near's [[higan]] project, with a mostly original N64 core. Unlike other N64 emulators, it aims for high accuracy and does not employ HLE RSP or RDP emulation of any kind, not does it use game-specific hacks. It uses Themaister's ParaLLEl-RDP Vulkan renderer (with the MAME renderer as a software-based fallback) for pixel-perfect LLE graphics. While it is currently less compatible than Mupen64Plus or Project64, it is quickly catching up to them [https://ares-emu.net/compatibility/15 (only a handful of games are currently listed as partially or not working)], and it currently passes several stringent [https://github.com/ares-emulator/ares/pull/613 accuracy tests] the other emulators do not. However, it remains to be seen how accurate its developers are willing to make it [https://github.com/ares-emulator/ares/commit/3142bd3aef3a0b7c9d97517c70f41e0eb27542ea without compromising speed] and playability on current machines.<br />
<br />
;[[CEN64]]<br />
:Aims for cycle accuracy while at the same time aiming to eventually be usable on modern PC hardware. It lacks many features and has spotty compatibility, but it can already emulate some well-known edge cases such as picture recognition in Pokemon Snap. Unfortunately, its creator appears to have abandoned the project [https://github.com/n64dev/cen64/releases/tag/v0.3 citing lack of satisfaction with the program's performance in its current interpreter-based incarnation], and while the baton has been collectively passed to the n64dev community for further development, progress has been slow.<br />
<br />
;[[1964]]<br />
:Along with its various versions and forks, it was once a decent, speedy open-source alternative to Project64 and Mupen64, though it usually lagged behind the two compatibility-wise. Nowadays it has completely fallen off the radar as development has halted, and there is no longer a central code repo to speak of. There is little reason to use it nowadays outside of historical purposes, very specific edge cases, or if your device is too slow to run Mupen64Plus or Project64.<br />
<br />
;Daedalus<br />
:Is a Nintendo 64 emulator for PC which was ported to the PSP under the name of DaedalusX64. The PSP version later became the main version and got ported to platforms such as the Dreamcast, the PS2, the PS Vita, and the 3DS. On PSP, several games are able to reach full speed and most of them work with few emulation issues.<br />
<br />
;[[Sixtyforce]]<br />
:Is macOS-only, closed-source, and asks you to pay for full access to its features. It was once one of the only choices for Mac users, particularly those with older Macs since it's the only emulator with a <abbr title="Power PC">PPC</abbr> [[Dynamic recompilation|dynarec]]), but, with the switch to x86 and Mupen64Plus being ported to macOS, it has now become less relevant. However, development is still ongoing and is currently in its [https://sixtyforce.com/rosetta/ third rewrite] to support the upcoming [https://en.wikipedia.org/wiki/Apple-designed_processors Apple Silicon].<br />
<br />
;[[UltraHLE]]<br />
: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.<br />
<br />
;[[Ryu64]]<br />
:Is a Nintendo 64 emulator made in C#. The 'Ryu' word is named after the "RyuJIT" used in both Visual Basic & C#. But it might have been inspired by the lead author's sole (so far) [https://github.com/Ryujinx/Ryujinx/commits?author=Dudejoe870 commit] at Switch emulator, [[Ryujinx]]'s Git repository, and his depreciated [https://github.com/Dudejoe870/RyujinxAutoUpdate Ryujinx Auto Updater] tool. "86RYU", an x86 JIT compiler, is being developed alongside this emulator too.<br />
<br />
;n64oid<br />
:An Android exclusive Nintendo 64 emulator. It is similar to Project 64 1.6 in terms of compatibility, although it is unknown who authored it, as the APK for n64oid circulates on many legally questionable APK sites. n64oid has the infamous problem in Mario Kart 64 of the screen in Wario Stadium not displaying properly, as it displays nothing but black. It upscales all games to widescreen, which works well most of time, but on many phones it will have performance issues. The emulator is relatively poor, but it is much easier to set up than other options. The emulator features a menu with many similarities to the mobile edition of Snes9x EX+, and the My Boy! family of Android emulators for Game Boy systems.<br />
<br />
==Emulation issues==<br />
{{Main|Recommended N64 plugins}}<br />
<br />
Nintendo 64 emulation is now decent. A lot of the major problems that N64 emulation had in the past, have been fixed for quite some time now. The only catch is that the accurate emulators have higher system requirements. The main remaining problem is the lack of accurate cycle counting.<br />
<br />
===[[High/Low level emulation|High-level vs. low-level]] graphics===<br />
<br />
One of the biggest hurdles to emulating the Nintendo 64 was the Reality Display Processor (RDP), which used a custom design that had to be fine-tuned to get more performance out of the system using microcode. To emulate the RDP accurately, one would have to execute said microcode the way the RDP did, which differed from PC graphics cards of the day. To complicate matters further, API standards that were available on PCs two decades ago were nowhere near as flexible as they are today. If you wanted to make an accurate GPU-accelerated RDP plugin in 2003, you simply couldn't with the APIs of the time (OpenGL 1.x and Direct3D 9). For the average user, hardware-accurate GPU acceleration would be out of reach for a long time.<br />
<br />
[[UltraHLE]] offered a compromise. In contrast to earlier consoles, whose video chips in hindsight had been easy to render to the host CPU's framebuffer, performant RDP emulation had to take shortcuts, including programming around specific games' microcode to cleanly translate their graphics commands into API calls using Direct3D, OpenGL, and even Glide. With this, the theoretical system requirements plummeted, 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 is an improvement is subjective and a common point of discussion. Unfortunately it proved to be hit and miss, owing to the nature of per-game microcode detection and having to tweak settings to prevent some games from running into graphical glitches.<br />
<br />
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).<br />
<br />
On the high-level side, gonetz and one or two assistants spent a large portion of development improving GlideN64's microcode handling 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 framebuffer is used as well as performance issues), VI emulation, and how combine/blending modes are emulated (such as noise issues and combiner accuracy).<br />
<br />
<gallery widths="300" mode="packed"><br />
Majora's mask accurate.png| Low-level emulation of Majora's Mask using SoftGraphic<br />
Project64 2013-07-26 14-20-17-55.png| High-level emulation of Majora's Mask using Jabo's Direct3D<br />
</gallery><br />
<br />
===[[Texture filtering]]===<br />
The Nintendo 64 was the first consumer device to be able to filter textures when rendering 3D objects. However, unlike every console and PC graphics card made after the N64, its implementation of bilinear was primitive in that, in order to reduce strain on the system, it only used three samples as opposed to four, resulting in slightly jagged, asymmetrically-filtered textures. Instead of faithfully applying this "imperfect" version of bilinear filtering, HLE plugins instead applied conventional bilinear filtering, interpolating straight from the source texture up to the output resolution the same way a PC game would. While that method is technically superior, it can result in textures that look even blurrier than on real hardware.<br />
<br />
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 pre-rendered backgrounds or menu screens, may look as though they are separated into squares (see images below; note how OoT's Quest Status screen appears to be divided into a grid). 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 oftentimes low resolutions.<br />
<br />
Modern emulators and plugins have taken some steps which help remedy these problems. For instance, GLideN64 now supports N64-style three-point texture filtering, which results in a more faithful look. It is also capable of rendering at 320x240, which sidesteps the issues with filtered text, UI elements, and menu screens, while still retaining texture filtering. Pixel-accurate plugins such as Angrylion and ParaLLEl-RDP do not have these problems at all.<br />
<gallery widths="300" mode="packed"><br />
Project64_2013-06-26_17-44-58-31.png|Conker's Bad Fur Day copyright screen, displaying issues with filtered text.<br />
Mupen64plus_2013-08-18_20-35-50-08.png|Ocarina of Time's menu subscreen, displaying issues with filtering.</gallery><br />
<br />
===Timing issues===<br />
One of the biggest remaining problems in N64 emulation is lack of accurate core timings, which in practice means games do not always run at the speed they would on real hardware. While this technically affects all games, the majority are only affected to a negligible degree, and in some instances (particularly in Rare games) this can actually result in less framerate drops and lag, which can be seen as beneficial. However, some game engines actually depend on accurate timings for proper game behavior, and not properly emulating them can result in considerable to major issues. Some notable examples include the following:<br />
* Intros and cutscenes playing too fast and not properly syncing up with musical cues. Seen in Goldeneye's intro and Body Harvest's beginning cutscene.<br />
* Gameplay demos running at hyper speed. Earthworm Jim 3D is most notorious for this, though the main game itself is largely unaffected.<br />
* Game physics not working properly due to being tied to framerate. A good example is Donkey Kong 64, which is programmed to boost the character's speed and momentum proportional to in-game lag (most likely to make up for the game's frequent framerate drops), which can be exploited for certain glitches and sequence breaks on real hardware. Emulators currently run the game too well and with too little lag, making most of these tricks impossible to pull off.<br />
* Possibly the most affected game is Knife's Edge, which runs like it's on permanent fast-forward, making it all but unplayable. Messing with timing-related settings such as CounterFactor can mitigate this somewhat, but nowhere near enough to fix the issue.<br />
Fortunately, tackling these problems has recently become a core focus of development in some N64 emulators, and attempts are underway to improve the situation. Ares currently has the most accurate timings overall, and already runs Earthworm Jim 3D's demos much better than other emulators. Meanwhile, simple64 has recently pushed various timing-related commits aimed at improving accuracy, and as a result it may now be the only emulator that runs Donkey Kong 64 properly. As these efforts progress, it should be noted that a side-effect of improved timings may be greater in-game lag. This should not be seen as the emulator becoming slower, but rather the emulator behaving exactly like real hardware does, as many N64 games were notorious for framerate drops.<br />
<br />
==Peripherals==<br />
===Voice Recognition Unit emulation===<br />
The Voice Recognition Unit (VRU) is an accessory used primarily by ''Hey You, Pikachu''. No emulator or input plugin supports this, although there is an on-going effort to get it working.<ref name="emutalk">{{cite web|url=http://www.emutalk.net/threads/55279|title=Hey You! Pikachu - Possible HLE Implementation|publisher=emutalk|accessdate=2018-06-17|date=2014-10-27, Last edit: 2016-04-04}}</ref><br />
===''Densha De Go!'' Controller===<br />
Also available for the [[PlayStation emulators|PlayStation]], ''Densha De Go! 64'' is a Japan-only train simulator released by [[Wikipedia:Taito|Taito]] that is compatible with an optional special controller that plugs into the player 3 port.<ref name="ArcadeUSA">{{cite web|url=https://www.youtube.com/watch?v=cCcPAGhcnck|title=Densha De Go! Nintendo 64 Controller!|publisher=YouTube|accessdate=2018-06-17|date=2017-01-20}}</ref> No emulator supports it.<br />
<br />
===Pokémon Snap Station===<br />
There was a special kiosk designed to promote ''Pokémon Snap'' called the ''Pokémon Snap Station'', which is also compatible with the North American ''Pokémon Stadium'' with its gallery mode. It is just a Nintendo 64 with special hardware designed for the station.<ref name="Sixty Formula">{{cite web|url=https://www.youtube.com/watch?v=AMbjvGvPkV4|title=The Pokemon Snap Station|publisher=YouTube|accessdate=2018-06-17|date=2016-05-21}}</ref><ref name="MetalJesusRocks">{{cite web|url=https://www.youtube.com/watch?v=5_UGpRN6AnM&t=3m35s|title=VIDEO GAME KIOSKS - Extreme Game Collecting!|publisher=YouTube|accessdate=2018-06-17|date=2016-05-25}}</ref> Although the special cartridge boots in emulators compatible with the regular version, the printing functions are inaccessible due to no emulation of the printer for the player 4 slot, credit system, or the special board to switch between the regular and special cartridges.<br />
<br />
===Transfer Pak emulation===<br />
A few games, such as ''Mario Golf'', ''Mario Tennis'', ''Mario Artist: Paint Studio'', and the ''Pokémon Stadium'' games, can use the Transfer Pak, an attachment that allows interfacing with specific [[Game Boy/Game Boy Color emulators|Game Boy/Color]] games for certain features. Most N64 emulators can emulate the Transfer Pak's functionality to one degree or another, with the most robust being Project64 with N-Rage's input plugin, but a couple of things are difficult to emulate or are not emulated at all:<br />
<br />
*Taking pictures with the Japanese ''Game Boy Camera'' (called ''Pocket Camera'') while in Transfer Pak mode playing ''Mario Artist: Paint Studio'' displays static.<br />
*Playing the Gen 1 and 2 Pokemon games through the Game Boy Tower in Pokemon Stadium 1 and 2 is notoriously finicky. At the moment, only Project64, using the N-Rage input plugin, can properly load either game's Game Boy Tower at all, with other emulators either crashing or failing to establish the connection. Even here, extra steps must be taken: for Pokemon Stadium 2, simply set the CPU core to Interpreter and Counter factor set to 1 in the emulator's game settings. For the first Stadium game, in addition to the aforementioned settings, Delay SI Interrupt must also be turned on, and an LLE RSP plugin other than the default Projec64 RSP must be used, such as ParaLLEl-RSP.<br />
<br />
===64DD emulation===<br />
The 64DD (an abbreviation for "64 Disk Drive") was a peripheral which allowed a proprietary disk format to be used with the N64. These disks had more space at a cheaper manufacturing cost. The peripheral was a commercial failure and was never released outside of Japan. Internal evidence suggests that, much like the GBA e-Reader, it wasn't even intended for a European release.<br />
<br />
Expansion disks are region-coded to either Japan or the US (obviously unused) and won't work with N64 games from the wrong region. Only F-Zero X has full support for this feature, but dummied-out expansion data in Ocarina of Time and Mario Party 2 (JP/PAL) exist as well.<br />
<br />
The special AV-In cartridge (NUS-028) that ''Mario Artist: Talent Studio'' can use doesn't work because it requires an RCA cable signal.<br />
<br />
Recently, there has been an effort to emulate the 64DD, and now [[Project64]] and [[MAME]] can run several commercial 64DD games as part of its N64 emulator. This is being ported to [[CEN64]] with the help of [https://twitter.com/LuigiBlood LuigiBlood]. The latest newcomer is Mupen64Plus which is the base of other emulators such as [[simple64]] and [[RMG]].<br />
<br />
<div style="max-width:100%; overflow:auto;"><br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Platform(s)<br />
! scope="col"|Latest Version<br />
! scope="col"|N64 Mouse<br />
! scope="col"|64DD Emulation<br />
! scope="col"|Active<br />
! scope="col"|[[Recommended emulators|Recommended]]<br />
|-<br />
! colspan="7"|PC / x86<br />
|-<br />
|[[RetroArch|Mupen64Plus-Next (mupen64plus_next_libretro)]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/windows/x86_64/latest/ nightly]<br />
|{{✓}}<br />
|Mid/High<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Project64]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://github.com/project64/project64 {{Project64Ver}}]<br >[https://64dd.org/downloads.html 64DD.org Builds]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[RetroArch|ParaLLEl-N64 (parallel_n64_libretro)]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/windows/x86_64/latest/ nightly]<br />
|{{✓}}<br />
|Mid/High<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[CEN64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/tj90241/cen64 git]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[MAME]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[http://www.mamedev.org/release.html {{MAMEVer}}]<br />
|{{✗}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[simple64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/simple64/simple64/releases {{Simple64Ver}}]<br >[https://github.com/simple64/simple64/actions git]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|{{✗}} (WIP)<br />
|-<br />
|[[RMG]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/Rosalie241/RMG/releases {{RMGVer}}]<br >[https://github.com/Rosalie241/RMG/actions Dev]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|{{✗}} (WIP)<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://github.com/mupen64plus/mupen64plus-core/releases git]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|{{✗}} (WIP)<br />
|}<br />
</div><br />
<br />
* Project64's latest versions emulate the N64 mouse and can load Zoinkity's hacked 64DD cartridge conversions at playable speeds. You'll need to set every game to have 8MB of Memory by default manually. Games do not save, some need "32-bit engine" to be unchecked (like Talent Studio), and some (like Polygon Studio to fix models and Paint Studio to fix stamps) need the Angrylion GFX plugin rather than GlideN64, which does the job for the rest.<br />
**The 64DD hardware started to be emulated around 2.3's release with the help of [https://github.com/LuigiBlood LuigiBlood]. Saving works but in the form of NDR files. NDR files are copied versions of NDD images with save data included as to not write to the clean unaltered images. In order to play 64DD games in their original forms, 8MB of memory is still needed because the real hardware needed the Expansion Pak upgrade. The IPL is also needed.<br />
<br />
* MAME includes early basic 64DD emulation as well but is much slower. Disk images need to be in head/track format. See [https://github.com/Happy-yappH/ddconvert.git here] for more information. It does not currently support disk swapping or saving disk to files. Writes only update the copy in memory, and, once the MAME process ends, the changes are lost. Current usage: <code>mame n64dd -quickload disk -cart cart -nodrc</code> (both disk and cart are optional)<br />
<br />
* CEN64, like Project64, had 64DD emulation ported to it from MAME. However, it focuses on accuracy and plays much slower than other emulators, aside from the 64DD emulation itself is imperfect.<br />
<br />
==Hardware variants==<br />
===iQue Player emulation===<br />
Before the GBA, DS, and 3DS, Nintendo released a modified version of their Nintendo 64 system for the Chinese market, which was called the iQue Player, through their not-quite-subsidiary iQue. Fourteen games were translated into Simplified Chinese, including Sin and Punishment, Ocarina of Time (the Majora's Mask port was canceled), Super Mario 64, and others.<br />
<br />
Unlike the Chinese releases of their more recent systems and their games, iQue Player releases are regular N64 roms wrapped with several layers of encryption, as well as a ticket and signature system like that on Wii, DSi, 3DS, Wii U, and Switch. The Chinese ROM-hacking scene is very active though and has translated the Japanese regular N64 releases for many of these to their language already, which explains some of the Chinese ROMs floating for those. However, recently, almost all pieces of iQue Player software were decrypted to regular .z64 ROM format.<br />
<br />
Several of the Chinese game localizations already run on N64 emulators, but as some hardware features of the iQue Player are not yet supported, some games, as well as the system menu and features in games such as saving, do not work yet.<br />
<br />
===Aleck 64 arcade emulation===<br />
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). 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.<br />
<br />
The Aleck 64 ROMs were dumped, and Zoinkity is working on converting them to regular N64 ROMs (with controls remapped to N64 controller buttons). They generally require an 8MB Expansion Pak to run at all and 4K EEPROM to save settings and scores. The ones covered by these patches are:<br />
<br />
* Donchan Puzzle Hanabi de Doon!<br />
* Eleven Beat: World Tournament<br />
* Hi Pai Paradise<br />
* Hi Pai Paradise 2<br />
* Kuru Kuru Fever<br />
* Magical Tetris Challenge<br />
* Mayjinsen 3 / Meijin-Sen<br />
* Star Soldier: Vanishing Earth (also ported to N64)<br />
* Super Real Mahjong VS<br />
* Tower & Shaft<br />
* Vivid Dolls (official eroge game on a Nintendo console)<br />
<br />
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.<br />
<br />
The remaining ones from the system's library not yet covered are:<br />
* Rev Limit<br />
* Variant Schwanzer<br />
<br />
==Virtual Console games in Dolphin==<br />
A number of N64 games were released for the Wii's Virtual Console service throughout its lifespan. While the emulators at the heart of each Virtual Console title were of average accuracy (rather than using one generic emulator used for every game, each title had an emulator specifically tailored to that game), they were good enough to render the games in full playable capacity with few to no glaring errors. Many of these titles are emulated well through Dolphin, and for a good while, due to persistent long-standing inaccuracies in N64 emulators and plugins, this was the best way to emulate certain N64 games, particularly Pokemon Snap and Mario Tennis. The system requirements are much higher than running them on regular N64 emulators, but it's doable for many games. Today, regular N64 emulators and plugins have advanced to the degree that this has become unnecessary, relegating this method of N64 game emulation to little more than a curiosity, at least on PC.<br />
<br />
The following games are on the N64 Virtual Console for Wii:<br />
<br />
{|width="100%"<br />
|- valign="top"<br />
|<br />
* 1080 Snowboarding<br />
* Bomberman Hero<br />
* Cruis'n USA<br />
* Custom Robo V2 (Japan only)<br />
* F-Zero X<br />
* Kirby 64: The Crystal Stars<br />
* The Legend of Zelda: Majora's Mask<br />
* The Legend of Zelda: Ocarina of Time<br />
|<br />
* Mario Golf<br />
* Mario Kart 64<br />
* Mario Party 2<br />
* Mario Tennis<br />
* Ogre Battle 64: Person of Lordly Caliber<br />
* Paper Mario<br />
* Pokemon Puzzle League<br />
|<br />
* Pokemon Snap<br />
* Sin & Punishment (English)<br />
* Star Fox 64<br />
* Super Mario 64<br />
* Super Smash Bros.<br />
* Wave Race 64<br />
* Yoshi's Story<br />
|}<br />
<br />
==Notes==<br />
<references group=N /><br />
<br />
==References==<br />
<references/><br />
<br />
{{Nintendo}}<br />
<br />
[[Category:Consoles]]<br />
[[Category:Home consoles]]<br />
[[Category:Fifth-generation video game consoles]]<br />
[[Category:Nintendo consoles]]<br />
[[Category:Nintendo 64 emulators|*]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Nintendo_64_emulators&diff=50136Nintendo 64 emulators2022-09-23T02:28:35Z<p>GPDP1: Added information on how to get the Game Boy Tower in the Pokemon Stadium games working, as well as some expansions elsewhere</p>
<hr />
<div>{{Infobox console<br />
|title = Nintendo 64<br />
|logo = Nintendo64Console.png<br />
|developer = [[:Nintendo]]<br />
|type = [[:Category:Home consoles|Home video game console]]<br />
|generation = [[:Category:Fifth-generation video game consoles|Fifth generation]]<br />
|release = 1996<br />
|discontinued = 2002<br />
|predecessor = [[Super Nintendo emulators|SNES]]<br />
|successor = [[GameCube emulators|GameCube]]<br />
|emulated = {{✓}}<br />
}}<br />
<br />
{{for|other emulators that run on N64 hardware|Emulators on N64}} <br />
<br />
<br />
The '''Nintendo 64''' is a 64-bit fifth-generation console released by Nintendo on September 29, 1996 for {{inflation|USD|199.99|1996}}.<br />
<br />
Nintendo was the second company approached by Silicon Graphics Inc. (SGI), who wanted to roll out their previously enterprise-only technology in the consumer space. They originally pitched their idea to Sega, but it's assumed that Nintendo's offer was more appealing. With the NEC VR4300 CPU clocked at 93.75 MHz, 4MB of RAM,<ref group=N>Though a separate add-on was later released called the "Expansion Pak" that added an additional 4MB of RAM, totaling 8MB.</ref> and an SGI RCP GPU, Nintendo had finalized much of the hardware at least a year before launch, preventing video games from needing drastic rewrites as a result of architectural changes. The development workstations were often Unix-based, something that would later help reverse engineers in some projects.<br />
<br />
==Emulators==<br />
<div style="max-width:100%; overflow:auto;"><br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Platform(s)<br />
! scope="col"|Latest version<br />
! scope="col"|Plugins<br />
! scope="col"|Controller Pak<br />
! scope="col"|Rumble Pak<br />
! scope="col"|Transfer Pak<br />
! scope="col"|64DD<br />
! scope="col"|Depth<br/>output<br />
! scope="col"|Texture<br/>enhancement<br />
! scope="col"|Netplay<br />
! scope="col"|[[libretro]]<br />
! scope="col"|<abbr title="Free/Libre and Open-Source Software">FLOSS</abbr><br />
! scope="col"|Active<br />
! scope="col"|[[Recommended emulators|Recommended]]<br />
|-<br />
!colspan="15"|PC / x86<br />
|-<br />
|[[simple64]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/simple64/simple64/releases {{Simple64Ver}}]<br >[https://github.com/simple64/simple64/actions git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[RetroArch|Mupen64Plus-Next (mupen64plus_next_libretro)]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/windows/x86_64/latest/ nightly]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}¹<br />
|{{✓}}<br />
|{{✓}}*<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[RMG]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/Rosalie241/RMG/releases {{RMGVer}}]<br >[https://github.com/Rosalie241/RMG/actions Dev]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}⁴<br />
|{{✓}}⁴<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Project64]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://www.pj64-emu.com/public-releases {{Project64Ver}}]<br >[https://www.pj64-emu.com/nightly-builds Dev]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[ares]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/ares-emulator/ares/releases {{aresVer}}]<br >[https://github.com/ares-emulator/ares/actions git]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|{{~}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://github.com/mupen64plus/mupen64plus-core/releases git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}⁴<br />
|{{✓}}⁴<br />
|{{~}}²<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[RetroArch|ParaLLEl-N64 (parallel_n64_libretro)]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/windows/x86_64/latest/ nightly]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{✓}}*<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}⁵<br />
|-<br />
|[[1964]]<br />
|align=left|{{Icon|Windows}}<br />
|[http://www.emulation64.com/files/getfile/936/ 1.1] (Official)<br />[http://files.emulation64.fr/Emulateurs/EMU_1964_146.zip 1.2 r146] (Unofficial SVN)<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}³<br />
|-<br />
|simple64 (Final GLideN64)<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/thekovic/simple64/releases/tag/v2021.5.30 Final GLideN64]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}⁶<br />
|-<br />
|[[BizHawk]]<br />
|align=left|{{Icon|Windows}}<br />
|[http://tasvideos.org/BizHawk/ReleaseHistory.html {{BizHawkVer}}]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}[https://github.com/TASEmulators/BizHawk/issues/2454 *]<br />
|{{✓}}⁴<br />
|{{✓}}⁴<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[CEN64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/tj90241/cen64 git]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[Project64 Netplay]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://github.com/Project64Netplay/Project64-Netplay-2x git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[DaedalusX64]]<br />
|align=left|{{Icon|Linux|macOS}}<br />
|[https://github.com/DaedalusX64/daedalus/releases/latest git]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|{{✗}}<br />
|-<br />
|[[Sixtyforce]]<br />
|align=left|{{Icon|macOS}}<br />
|[http://sixtyforce.com/download/ {{SixtyforceVer}}]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Larper64<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://drive.google.com/file/d/1IWyw5UG9Uf24KG0zrcXSFoOmcQoHWmyc/view {{Larper64Ver}}]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|[[UltraHLE]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://web.archive.org/web/20070312015944/http://www.emuunlim.com/UltraHLE/ultrahle.zip 1.0]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|[[MAME]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[http://www.mamedev.org/release.html {{MAMEVer}}]<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[Ryu64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/Ryu64Emulator/Ryu64 git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|R64Emu<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/rasky/r64emu git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
!colspan="15"|Mobile / ARM<br />
|-<br />
|[[Mupen64Plus]] FZ<br />
|align=left|{{Icon|Android}}<br />
|[https://play.google.com/store/apps/details?id=org.mupen64plusae.v3.fzurita 3.0.322 (beta)]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}¹<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Pandora|Pyra}}<br />
|[http://repo.openpandora.org/?page=detail&app=mupen64plus Pandora]<br/>[https://pyra-handheld.com/repo/apps/39 Pyra]<br />
|?<br />
|{{✓}}<br />
|?<br />
|?<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
!colspan="15"|Consoles<br />
|-<br />
|[[Virtual Console]]<br />
|align=left|{{Icon|Wii|WiiU}}<br />
|N/A<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[DaedalusX64]]<br />
|align=left|{{Icon|PSP|3DS}}<br>{{Icon|Vita|PS2}}<br />
|[https://github.com/DaedalusX64/daedalus/releases/latest PSP]<br/>[https://github.com/masterfeizz/DaedalusX64-3DS/releases 3DS]<br/>[https://github.com/Rinnegatamante/DaedalusX64-vitaGL/releases VitaGL]<br/>[https://www.ps2-home.com/forum/viewtopic.php?f=99&p=39957#p39957 PS2]<br />
|?<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|{{✓}}<br/><small>(PSP)</small><br />
|-<br />
|Not64<br />
|align=left|{{Icon|GCN|Wii}}<br />
|[https://github.com/Extrems/Not64/releases/latest git]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|Surreal64 CE<br />
|align=left|{{Icon|Xbox}}<br />
|[https://digiex.net/threads/surreal64-ce-b6-0-download-n64-emulator-for-xbox.13677 Beta 6.0]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|mupen64-360<br />
|align=left|{{Icon|Xbox360}}<br />
|[https://digiex.net/threads/mupen64-360-xbox-360-nintendo-64-n64-emulator-download.9352 0.96 beta]<br />
|?<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|[https://code.google.com/p/mupen64gc/ Wii64]<br />
|align=left|{{Icon|GCN|Wii}}<br />
|[https://code.google.com/archive/p/mupen64gc/downloads 1.1 beta]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|}<br />
</div><br />
<br />
*<nowiki>* Available exclusively as a libretro core</nowiki><br />
*<nowiki>¹ Only supports texture packs, and not filtering or upscaling</nowiki><br />
*<nowiki>² Requires replacing the input plugin to one with netplay support</nowiki><br />
*<nowiki>³ Highly recommended to use 1964 GEPD for Goldeneye 007 or Perfect Dark</nowiki><br />
*<nowiki>⁴ Only with GLideN64</nowiki><br />
*<nowiki>⁵ Obsolete and replaced by Mupen64Plus-Next</nowiki><br />
*<nowiki>⁶ RMG with GLideN64 recommended.</nowiki><br />
<br />
===Comparisons===<br />
Although many Nintendo 64 emulators have been made and many games can be run between them, until recently complete compatibility and/or accuracy left a bit to be desired. For half a decade, Mupen64Plus and Project64 have vied for the most playable emulator, and which was more compatible often depended on when and in what configuration each emulator has been tested. As of August 2017, both emulators have roughly equal compatibility and accuracy when running with the same [[recommended N64 plugins]] setup, though both default to Glide64, a now relatively lackluster plugin.<br />
<br />
;[[Mupen64Plus]]<br />
:A multi-platform emulator based on Hacktarux's Mupen64. It's about as accurate as Project64,<ref>loganmc10. [https://github.com/mupen64plus/mupen64plus-core/pull/336 ''Ignore TLB write if TLB entry is unmapping itself'']. "By the way, once this, along with the other PR's I have waiting are merged, we are at "compatibility parity" with Project64 as far as I can tell. I don't know of any game that doesn't boot with mupen64plus that works in PJ64."</ref> when both emulators are run with GLideN64. However, Mupen64Plus lacks a native GUI, instead being launched either from the command line or by dragging and dropping ROMs onto the executable and editing the config with a text editor. It also only comes bundled with outdated video plugins, so to ensure the best possible compatibility, sourcing better third-party plugins such as GLideN64 is a must. [[BizHawk]] and [[OpenEmu]] use forks of Mupen64Plus and its plugins for their N64 emulation, but they seem to be shallow. As of 2022 Project64-style overclocking for faster frame rates has been added under the option 'CountPerOpDenomPot'.<br />
<br />
:;Mupen64Plus-Next and ParaLLEl-N64<br />
:Both are heavily-modified forks developed as [[libretro]] cores. They introduce many features and optimizations not present in mainline alongside [[RetroArch]]'s general features, including 3-point texture filtering for Glide64, superior A/V sync and latency, and even an initially exclusive LLE Vulkan renderer based on Angrylion's pixel-perfect RDP plugin now known as ParaLLEl-RDP, making it a better alternative to the standalone version in some cases. 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.<br />
<br />
::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), considerably cleans up the Core Options menu for easier configuration and 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.<br />
<br />
:;[[simple64]]<br />
:A fork of Mupen64Plus with a custom-made Qt GUI. This is probably the easiest "just works out of the box" solution for Nintendo 64 emulation, as it comes bundled with ParaLLEl-RDP and ParaLLEl-RSP, ensuring both excellent compatibility and good speed without needing to mess with plugins or settings, provided your hardware supports Vulkan. However, unlike other emulators, it does not allow you to use other plugins. While it began as a shallow fork, it has increasingly become something closer to a hard fork, as its developer has opted to make various accuracy-focused changes to the emulation core that will require additional work to port back to upstream or to other forks. It also currently features only an interpreter core, as the dynarecs used by Mupen64Plus are incompatible with the core timing changes made by the developer. While this makes simple64 more accurate than most other N64 emulators, it also results in slower performance. If more speed and enhancements are desired, there is an older build that is closer to upstream and uses GLideN64 as its graphics plugin - unfortunately lacking the texture enhancement suite required for use of texture packs and upscaling.<br />
<br />
:;[[RMG]]<br />
:Rosalie's Mupen GUI is a project aiming to close the gap between Project64 and Mupen64Plus in terms of user experience. Its interface is about on par with simple64's in terms of cleanliness and ease of use, but unlike simple64, it allows you to use other plugins. The latest version comes bundled with GLideN64 and ParaLLEl-RDP for video plugins, and mupen64plus-hle-rsp and ParaLLEl-RSP for RSP plugins, though it can still use the older plugins that come with regular Mupen64Plus in case your PC cannot handle the newer plugins. However, it currently does not allow you access to ParaLLEl-RDP's options within its GUI, so if you wish to make use of features such as upscaling or downsampling, you must do so by editing the mupen64plus.cfg file, whereas simple64 does expose these options in its GUI. However, if you prefer GLideN64, this is a superior alternative, as it does have access to its settings GUI, and the last version of simple64 that uses GLideN64 is becoming increasingly outdated.<br />
<br />
:;Wii64 and Not64<br />
:Both are based on Mupen64, with Not64 being a fork of Wii64. Not64 claims to be better optimized 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 releases whenever possible.<br />
<br />
;[[Project64]]<br />
: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 some of the Mupen64Plus attempts and supports features such as Transfer Pak emulation and 64DD emulation. It now comes with GLideN64 out-of-the-box, but the default audio plugin isn't even the best in the box. Annoyingly, it also nags you with a timed, unskippable message asking for donations to the project upon launch. It is thus recommended to download it through [https://github.com/Rosalie241/BetterMajorasMaskInstaller/releases/tag/4.0.2 Rosalie's BetterMajorasMaskInstaller], which downloads the latest nightly version of Project64 with the nagging message removed and installs several useful third-party plugins (it also downloads HD texture packs for OoT and MM, but you can opt out of that). For the most part, it works well in [[Wine]], but, if you're on a different platform, use Mupen64Plus instead.<br />
<br />
;[[Ares]]<br />
:An open-source multi-system emulator and successor to Near's [[higan]] project, with a mostly original N64 core. Unlike other N64 emulators, it aims for high accuracy and does not employ HLE RSP or RDP emulation of any kind, not does it use game-specific hacks. It uses Themaister's ParaLLEl-RDP Vulkan renderer (with the MAME renderer as a software-based fallback) for pixel-perfect LLE graphics. While it is currently less compatible than Mupen64Plus or Project64, it is quickly catching up to them [https://ares-emu.net/compatibility/15 (only a handful of games are currently listed as partially or not working)], and it currently passes several stringent [https://github.com/ares-emulator/ares/pull/613 accuracy tests] the other emulators do not. However, it remains to be seen how accurate its developers are willing to make it [https://github.com/ares-emulator/ares/commit/3142bd3aef3a0b7c9d97517c70f41e0eb27542ea without compromising speed] and playability on current machines.<br />
<br />
;[[CEN64]]<br />
:Aims for cycle accuracy while at the same time aiming to eventually be usable on modern PC hardware. It lacks many features and has spotty compatibility, but it can already emulate some well-known edge cases such as picture recognition in Pokemon Snap. Unfortunately, its creator appears to have abandoned the project [https://github.com/n64dev/cen64/releases/tag/v0.3 citing lack of satisfaction with the program's performance in its current interpreter-based incarnation], and while the baton has been collectively passed to the n64dev community for further development, progress has been slow.<br />
<br />
;[[1964]]<br />
:Along with its various versions and forks, it was once a decent, speedy open-source alternative to Project64 and Mupen64, though it usually lagged behind the two compatibility-wise. Nowadays it has completely fallen off the radar as development has halted, and there is no longer a central code repo to speak of. There is little reason to use it nowadays outside of historical purposes, very specific edge cases, or if your device is too slow to run Mupen64Plus or Project64.<br />
<br />
;Daedalus<br />
:Is a Nintendo 64 emulator for PC which was ported to the PSP under the name of DaedalusX64. The PSP version later became the main version and got ported to platforms such as the Dreamcast, the PS2, the PS Vita, and the 3DS. On PSP, several games are able to reach full speed and most of them work with few emulation issues.<br />
<br />
;[[Sixtyforce]]<br />
:Is macOS-only, closed-source, and asks you to pay for full access to its features. It was once one of the only choices for Mac users, particularly those with older Macs since it's the only emulator with a <abbr title="Power PC">PPC</abbr> [[Dynamic recompilation|dynarec]]), but, with the switch to x86 and Mupen64Plus being ported to macOS, it has now become less relevant. However, development is still ongoing and is currently in its [https://sixtyforce.com/rosetta/ third rewrite] to support the upcoming [https://en.wikipedia.org/wiki/Apple-designed_processors Apple Silicon].<br />
<br />
;[[UltraHLE]]<br />
: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.<br />
<br />
;[[Ryu64]]<br />
:Is a Nintendo 64 emulator made in C#. The 'Ryu' word is named after the "RyuJIT" used in both Visual Basic & C#. But it might have been inspired by the lead author's sole (so far) [https://github.com/Ryujinx/Ryujinx/commits?author=Dudejoe870 commit] at Switch emulator, [[Ryujinx]]'s Git repository, and his depreciated [https://github.com/Dudejoe870/RyujinxAutoUpdate Ryujinx Auto Updater] tool. "86RYU", an x86 JIT compiler, is being developed alongside this emulator too.<br />
<br />
;n64oid<br />
:An Android exclusive Nintendo 64 emulator. It is similar to Project 64 1.6 in terms of compatibility, although it is unknown who authored it, as the APK for n64oid circulates on many legally questionable APK sites. n64oid has the infamous problem in Mario Kart 64 of the screen in Wario Stadium not displaying properly, as it displays nothing but black. It upscales all games to widescreen, which works well most of time, but on many phones it will have performance issues. The emulator is relatively poor, but it is much easier to set up than other options. The emulator features a menu with many similarities to the mobile edition of Snes9x EX+, and the My Boy! family of Android emulators for Game Boy systems.<br />
<br />
==Emulation issues==<br />
{{Main|Recommended N64 plugins}}<br />
<br />
Nintendo 64 emulation is now decent. A lot of the major problems that N64 emulation had in the past, have been fixed for quite some time now. The only catch is that the accurate emulators have higher system requirements. The main remaining problem is the lack of accurate cycle counting.<br />
<br />
===[[High/Low level emulation|High-level vs. low-level]] graphics===<br />
<br />
One of the biggest hurdles to emulating the Nintendo 64 was the Reality Display Processor (RDP), which used a custom design that had to be fine-tuned to get more performance out of the system using microcode. To emulate the RDP accurately, one would have to execute said microcode the way the RDP did, which differed from PC graphics cards of the day. To complicate matters further, API standards that were available on PCs two decades ago were nowhere near as flexible as they are today. If you wanted to make an accurate GPU-accelerated RDP plugin in 2003, you simply couldn't with the APIs of the time (OpenGL 1.x and Direct3D 9). For the average user, hardware-accurate GPU acceleration would be out of reach for a long time.<br />
<br />
[[UltraHLE]] offered a compromise. In contrast to earlier consoles, whose video chips in hindsight had been easy to render to the host CPU's framebuffer, performant RDP emulation had to take shortcuts, including programming around specific games' microcode to cleanly translate their graphics commands into API calls using Direct3D, OpenGL, and even Glide. With this, the theoretical system requirements plummeted, 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 is an improvement is subjective and a common point of discussion. Unfortunately it proved to be hit and miss, owing to the nature of per-game microcode detection and having to tweak settings to prevent some games from running into graphical glitches.<br />
<br />
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).<br />
<br />
On the high-level side, gonetz and one or two assistants spent a large portion of development improving GlideN64's microcode handling 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 framebuffer is used as well as performance issues), VI emulation, and how combine/blending modes are emulated (such as noise issues and combiner accuracy).<br />
<br />
<gallery widths="300" mode="packed"><br />
Majora's mask accurate.png| Low-level emulation of Majora's Mask using SoftGraphic<br />
Project64 2013-07-26 14-20-17-55.png| High-level emulation of Majora's Mask using Jabo's Direct3D<br />
</gallery><br />
<br />
===[[Texture filtering]]===<br />
The Nintendo 64 was the first consumer device to be able to filter textures when rendering 3D objects. However, unlike every console and PC graphics card made after the N64, its implementation of bilinear was primitive in that, in order to reduce strain on the system, it only used three samples as opposed to four, resulting in slightly jagged, asymmetrically-filtered textures. Instead of faithfully applying this "imperfect" version of bilinear filtering, HLE plugins instead applied conventional bilinear filtering, interpolating straight from the source texture up to the output resolution the same way a PC game would. While that method is technically superior, it can result in textures that look even blurrier than on real hardware.<br />
<br />
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 pre-rendered backgrounds or menu screens, may look as though they are separated into squares (see images below; note how OoT's Quest Status screen appears to be divided into a grid). 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 oftentimes low resolutions.<br />
<br />
Modern emulators and plugins have taken some steps which help remedy these problems. For instance, GLideN64 now supports N64-style three-point texture filtering, which results in a more faithful look. It is also capable of rendering at 320x240, which sidesteps the issues with filtered text, UI elements, and menu screens, while still retaining texture filtering. Pixel-accurate plugins such as Angrylion and ParaLLEl-RDP do not have these problems at all.<br />
<gallery widths="300" mode="packed"><br />
Project64_2013-06-26_17-44-58-31.png|Conker's Bad Fur Day copyright screen, displaying issues with filtered text.<br />
Mupen64plus_2013-08-18_20-35-50-08.png|Ocarina of Time's menu subscreen, displaying issues with filtering.</gallery><br />
<br />
===Timing issues===<br />
One of the biggest remaining problems in N64 emulation is lack of accurate core timings, which in practice means games do not always run at the speed they would on real hardware. While this technically affects all games, the majority are only affected to a negligible degree, and in some instances (particularly in Rare games) this can actually result in less framerate drops and lag, which can be seen as beneficial. However, some game engines actually depend on accurate timings for proper game behavior, and not properly emulating them can result in considerable to major issues. Some notable examples include the following:<br />
* Intros and cutscenes playing too fast and not properly syncing up with musical cues. Seen in Goldeneye's intro and Body Harvest's beginning cutscene.<br />
* Gameplay demos running at hyper speed. Earthworm Jim 3D is most notorious for this, though the main game itself is largely unaffected.<br />
* Game physics not working properly due to being tied to framerate. A good example is Donkey Kong 64, which is programmed to boost the character's speed and momentum proportional to in-game lag (most likely to make up for the game's frequent framerate drops), which can be exploited for certain glitches and sequence breaks on real hardware. Emulators currently run the game too well and with too little lag, making most of these tricks impossible to pull off.<br />
* Possibly the most affected game is Knife's Edge, which runs like it's on permanent fast-forward, making it all but unplayable. Messing with timing-related settings such as CounterFactor can mitigate this somewhat, but nowhere near enough to fix the issue.<br />
Fortunately, tackling these problems has recently become a core focus of development in some N64 emulators, and attempts are underway to improve the situation. Ares currently has the most accurate timings overall, and already runs Earthworm Jim 3D's demos much better than other emulators. Meanwhile, simple64 has recently pushed various timing-related commits aimed at improving accuracy, and as a result it may now be the only emulator that runs Donkey Kong 64 properly. As these efforts progress, it should be noted that a side-effect of improved timings may be greater in-game lag. This should not be seen as the emulator becoming slower, but rather the emulator behaving exactly like real hardware does, as many N64 games were notorious for framerate drops.<br />
<br />
==Peripherals==<br />
===Voice Recognition Unit emulation===<br />
The Voice Recognition Unit (VRU) is an accessory used primarily by ''Hey You, Pikachu''. No emulator or input plugin supports this, although there is an on-going effort to get it working.<ref name="emutalk">{{cite web|url=http://www.emutalk.net/threads/55279|title=Hey You! Pikachu - Possible HLE Implementation|publisher=emutalk|accessdate=2018-06-17|date=2014-10-27, Last edit: 2016-04-04}}</ref><br />
===''Densha De Go!'' Controller===<br />
Also available for the [[PlayStation emulators|PlayStation]], ''Densha De Go! 64'' is a Japan-only train simulator released by [[Wikipedia:Taito|Taito]] that is compatible with an optional special controller that plugs into the player 3 port.<ref name="ArcadeUSA">{{cite web|url=https://www.youtube.com/watch?v=cCcPAGhcnck|title=Densha De Go! Nintendo 64 Controller!|publisher=YouTube|accessdate=2018-06-17|date=2017-01-20}}</ref> No emulator supports it.<br />
<br />
===Pokémon Snap Station===<br />
There was a special kiosk designed to promote ''Pokémon Snap'' called the ''Pokémon Snap Station'', which is also compatible with the North American ''Pokémon Stadium'' with its gallery mode. It is just a Nintendo 64 with special hardware designed for the station.<ref name="Sixty Formula">{{cite web|url=https://www.youtube.com/watch?v=AMbjvGvPkV4|title=The Pokemon Snap Station|publisher=YouTube|accessdate=2018-06-17|date=2016-05-21}}</ref><ref name="MetalJesusRocks">{{cite web|url=https://www.youtube.com/watch?v=5_UGpRN6AnM&t=3m35s|title=VIDEO GAME KIOSKS - Extreme Game Collecting!|publisher=YouTube|accessdate=2018-06-17|date=2016-05-25}}</ref> Although the special cartridge boots in emulators compatible with the regular version, the printing functions are inaccessible due to no emulation of the printer for the player 4 slot, credit system, or the special board to switch between the regular and special cartridges.<br />
<br />
===Transfer Pak emulation===<br />
A few games, such as ''Mario Golf'', ''Mario Tennis'', ''Mario Artist: Paint Studio'', and the ''Pokémon Stadium'' games, can use the Transfer Pak, an attachment that allows interfacing with specific [[Game Boy/Game Boy Color emulators|Game Boy/Color]] games for certain features. Most N64 emulators can emulate the Transfer Pak's functionality to one degree or another, with the most robust being Project64 with N-Rage's input plugin, but a couple of things are difficult to emulate or are not emulated at all:<br />
<br />
*Taking pictures with the Japanese ''Game Boy Camera'' (called ''Pocket Camera'') while in Transfer Pak mode playing ''Mario Artist: Paint Studio'' displays static.<br />
*Playing the Gen 1 and 2 Pokemon games through the Game Boy Tower in Pokemon Stadium 1 and 2 is notoriously finicky. At the moment, only Project64, using the N-Rage input plugin, can properly load either game's Game Boy Tower all, with other emulators either crashing or failing to establish the connection. Even here, extra steps must be taken: for Pokemon Stadium 2, simply set the CPU core to Interpreter and Counter factor set to 1 in the emulator's game settings. For the first Stadium game, in addition to the aforementioned settings, Delay SI Interrupt must also be turned on, and an LLE RSP plugin other than the default Projec64 RSP must be used, such as ParaLLEl-RSP.<br />
<br />
===64DD emulation===<br />
The 64DD (an abbreviation for "64 Disk Drive") was a peripheral which allowed a proprietary disk format to be used with the N64. These disks had more space at a cheaper manufacturing cost. The peripheral was a commercial failure and was never released outside of Japan. Internal evidence suggests that, much like the GBA e-Reader, it wasn't even intended for a European release.<br />
<br />
Expansion disks are region-coded to either Japan or the US (obviously unused) and won't work with N64 games from the wrong region. Only F-Zero X has full support for this feature, but dummied-out expansion data in Ocarina of Time and Mario Party 2 (JP/PAL) exist as well.<br />
<br />
The special AV-In cartridge (NUS-028) that ''Mario Artist: Talent Studio'' can use doesn't work because it requires an RCA cable signal.<br />
<br />
Recently, there has been an effort to emulate the 64DD, and now [[Project64]] and [[MAME]] can run several commercial 64DD games as part of its N64 emulator. This is being ported to [[CEN64]] with the help of [https://twitter.com/LuigiBlood LuigiBlood]. The latest newcomer is Mupen64Plus which is the base of other emulators such as [[simple64]] and [[RMG]].<br />
<br />
<div style="max-width:100%; overflow:auto;"><br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Platform(s)<br />
! scope="col"|Latest Version<br />
! scope="col"|N64 Mouse<br />
! scope="col"|64DD Emulation<br />
! scope="col"|Active<br />
! scope="col"|[[Recommended emulators|Recommended]]<br />
|-<br />
! colspan="7"|PC / x86<br />
|-<br />
|[[RetroArch|Mupen64Plus-Next (mupen64plus_next_libretro)]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/windows/x86_64/latest/ nightly]<br />
|{{✓}}<br />
|Mid/High<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Project64]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://github.com/project64/project64 {{Project64Ver}}]<br >[https://64dd.org/downloads.html 64DD.org Builds]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[RetroArch|ParaLLEl-N64 (parallel_n64_libretro)]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/windows/x86_64/latest/ nightly]<br />
|{{✓}}<br />
|Mid/High<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[CEN64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/tj90241/cen64 git]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[MAME]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[http://www.mamedev.org/release.html {{MAMEVer}}]<br />
|{{✗}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[simple64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/simple64/simple64/releases {{Simple64Ver}}]<br >[https://github.com/simple64/simple64/actions git]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|{{✗}} (WIP)<br />
|-<br />
|[[RMG]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/Rosalie241/RMG/releases {{RMGVer}}]<br >[https://github.com/Rosalie241/RMG/actions Dev]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|{{✗}} (WIP)<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://github.com/mupen64plus/mupen64plus-core/releases git]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|{{✗}} (WIP)<br />
|}<br />
</div><br />
<br />
* Project64's latest versions emulate the N64 mouse and can load Zoinkity's hacked 64DD cartridge conversions at playable speeds. You'll need to set every game to have 8MB of Memory by default manually. Games do not save, some need "32-bit engine" to be unchecked (like Talent Studio), and some (like Polygon Studio to fix models and Paint Studio to fix stamps) need the Angrylion GFX plugin rather than GlideN64, which does the job for the rest.<br />
**The 64DD hardware started to be emulated around 2.3's release with the help of [https://github.com/LuigiBlood LuigiBlood]. Saving works but in the form of NDR files. NDR files are copied versions of NDD images with save data included as to not write to the clean unaltered images. In order to play 64DD games in their original forms, 8MB of memory is still needed because the real hardware needed the Expansion Pak upgrade. The IPL is also needed.<br />
<br />
* MAME includes early basic 64DD emulation as well but is much slower. Disk images need to be in head/track format. See [https://github.com/Happy-yappH/ddconvert.git here] for more information. It does not currently support disk swapping or saving disk to files. Writes only update the copy in memory, and, once the MAME process ends, the changes are lost. Current usage: <code>mame n64dd -quickload disk -cart cart -nodrc</code> (both disk and cart are optional)<br />
<br />
* CEN64, like Project64, had 64DD emulation ported to it from MAME. However, it focuses on accuracy and plays much slower than other emulators, aside from the 64DD emulation itself is imperfect.<br />
<br />
==Hardware variants==<br />
===iQue Player emulation===<br />
Before the GBA, DS, and 3DS, Nintendo released a modified version of their Nintendo 64 system for the Chinese market, which was called the iQue Player, through their not-quite-subsidiary iQue. Fourteen games were translated into Simplified Chinese, including Sin and Punishment, Ocarina of Time (the Majora's Mask port was canceled), Super Mario 64, and others.<br />
<br />
Unlike the Chinese releases of their more recent systems and their games, iQue Player releases are regular N64 roms wrapped with several layers of encryption, as well as a ticket and signature system like that on Wii, DSi, 3DS, Wii U, and Switch. The Chinese ROM-hacking scene is very active though and has translated the Japanese regular N64 releases for many of these to their language already, which explains some of the Chinese ROMs floating for those. However, recently, almost all pieces of iQue Player software were decrypted to regular .z64 ROM format.<br />
<br />
Several of the Chinese game localizations already run on N64 emulators, but as some hardware features of the iQue Player are not yet supported, some games, as well as the system menu and features in games such as saving, do not work yet.<br />
<br />
===Aleck 64 arcade emulation===<br />
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). 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.<br />
<br />
The Aleck 64 ROMs were dumped, and Zoinkity is working on converting them to regular N64 ROMs (with controls remapped to N64 controller buttons). They generally require an 8MB Expansion Pak to run at all and 4K EEPROM to save settings and scores. The ones covered by these patches are:<br />
<br />
* Donchan Puzzle Hanabi de Doon!<br />
* Eleven Beat: World Tournament<br />
* Hi Pai Paradise<br />
* Hi Pai Paradise 2<br />
* Kuru Kuru Fever<br />
* Magical Tetris Challenge<br />
* Mayjinsen 3 / Meijin-Sen<br />
* Star Soldier: Vanishing Earth (also ported to N64)<br />
* Super Real Mahjong VS<br />
* Tower & Shaft<br />
* Vivid Dolls (official eroge game on a Nintendo console)<br />
<br />
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.<br />
<br />
The remaining ones from the system's library not yet covered are:<br />
* Rev Limit<br />
* Variant Schwanzer<br />
<br />
==Virtual Console games in Dolphin==<br />
A number of N64 games were released for the Wii's Virtual Console service throughout its lifespan. While the emulators at the heart of each Virtual Console title were of average accuracy (rather than using one generic emulator used for every game, each title had an emulator specifically tailored to that game), they were good enough to render the games in full playable capacity with few to no glaring errors. Many of these titles are emulated well through Dolphin, and for a good while, due to persistent long-standing inaccuracies in N64 emulators and plugins, this was the best way to emulate certain N64 games, particularly Pokemon Snap and Mario Tennis. The system requirements are much higher than running them on regular N64 emulators, but it's doable for many games. Today, regular N64 emulators and plugins have advanced to the degree that this has become unnecessary, relegating this method of N64 game emulation to little more than a curiosity, at least on PC.<br />
<br />
The following games are on the N64 Virtual Console for Wii:<br />
<br />
{|width="100%"<br />
|- valign="top"<br />
|<br />
* 1080 Snowboarding<br />
* Bomberman Hero<br />
* Cruis'n USA<br />
* Custom Robo V2 (Japan only)<br />
* F-Zero X<br />
* Kirby 64: The Crystal Stars<br />
* The Legend of Zelda: Majora's Mask<br />
* The Legend of Zelda: Ocarina of Time<br />
|<br />
* Mario Golf<br />
* Mario Kart 64<br />
* Mario Party 2<br />
* Mario Tennis<br />
* Ogre Battle 64: Person of Lordly Caliber<br />
* Paper Mario<br />
* Pokemon Puzzle League<br />
|<br />
* Pokemon Snap<br />
* Sin & Punishment (English)<br />
* Star Fox 64<br />
* Super Mario 64<br />
* Super Smash Bros.<br />
* Wave Race 64<br />
* Yoshi's Story<br />
|}<br />
<br />
==Notes==<br />
<references group=N /><br />
<br />
==References==<br />
<references/><br />
<br />
{{Nintendo}}<br />
<br />
[[Category:Consoles]]<br />
[[Category:Home consoles]]<br />
[[Category:Fifth-generation video game consoles]]<br />
[[Category:Nintendo consoles]]<br />
[[Category:Nintendo 64 emulators|*]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=M64p&diff=49431M64p2022-08-22T16:05:40Z<p>GPDP1: changed "compatibility list" to "known issues list"</p>
<hr />
<div>{{lowercase title}}<br />
{{Infobox emulator<br />
|title = m64p<br />
|logo = <br />
|logowidth = <br />
|screenshot = M64p-screenshot.png<br />
|screenshotcaption = The m64p frontend on Windows 7.<br />
|developer = [https://github.com/loganmc10 loganmc10]<br />
|version = {{Version|m64p}}<br />
|active = Yes<br />
|platform = [[Emulators on Windows|Windows]]<br/>[[Emulators on Linux|Linux]]<br />
|architecture = x64<br />
|target = [[Nintendo 64 emulators|Nintendo 64]]<br />
|compatibility = High<br />
|accuracy = <br />
|website = [https://m64p.github.io/ m64p.github.io]<br />
|prog-lang = C, C++<br />
|support = [https://www.patreon.com/m64p Patreon]<br />
|license = GNU GPLv3<br />
|source = [https://github.com/m64p/m64p GitHub]<br />
}}<br />
'''m64p''' is an open-source, plugin-based [[Nintendo 64 emulators|Nintendo 64 emulator]] maintained by loganmc10. The project bundles [[Mupen64Plus]] with Parallel RDP, as well as its own frontend, input plugin, and netplay support.<br />
<br />
==Download==<br />
{| cellpadding="4"<br />
|-<br />
|align=center|{{Icon|Win-big|Lin-big}}<br />
|[https://github.com/m64p/m64p/releases '''Official releases''']<br />
|-<br />
|align=center|{{Icon|Win|Lin|Mac}}<br />
|[https://github.com/thekovic/m64p/releases/tag/v2021.5.30 Final GLideN64 build (2021-05-30)]<br />
|-<br />
|colspan="3"|<hr/><br />
|-<br />
|align=center|{{Icon|Win|Lin|Mac}}<br />
|[https://github.com/m64p/mupen64plus-gui mupen64plus-gui]<br><small>The frontend that can also be used separately with Mupen64Plus.</small><br />
|}<br />
<br />
==Overview==<br />
In the project's own words:<br />
<blockquote>''"This is likely the most compatible N64 emulator you’re going to come across. It can play games like Resident Evil 2, Rogue Squadron, Pokemon Snap, and World Driver Championship “out-of-the-box” (without the need to fiddle with settings, plugins, or anything of the sort)."''</blockquote><br />
<br />
The user interface, mupen64plus-gui, was written specifically for m64p using Qt5 prior to version 2022.07, and using Qt6 from version 2022.07 onward. The supported features:<br />
<br />
* Netplay using a central server hosted in the cloud for players to find sessions<br />
* Discord Rich Presence and automatic voice channel connectivity<br />
* Standard frontend features like pausing, screenshots, save states etc.<br />
* An auto-updater<br />
<br />
Parallel RDP and RSP are based on the work of [https://github.com/Themaister/parallel-rsp Themaister] and are used in the [https://www.libretro.com/index.php/parallel-n64-with-parallel-rsp-dynarec-release-fast-and-accurate-n64-emulation/ Parallel N64 Libretro core]. This makes fast and accurate N64 emulation possible in m64p.<br />
<br />
As of April 12, 2021, m64p no longer runs properly on macOS systems. The application produces an "unable to load video plugin" error and random application crash at startup. As of June 6th, 2021 it appears that support for macOS is being completely dropped by loganmc10 with the replacement of both the GlideN64 and Angrylion Plus RDPs with ParaLLEl-RDP and the release of Windows and Linux builds only, as macOS lacks the necessary Vulkan support for ParaLLEl-RDP to work, requiring additional Mac-specific work to make it function.<br />
<br />
As of Jul 17, 2022, m64p has undergone a major overhaul of its core timing code independently of upstream [[Mupen64Plus]], getting rid of the CountPerOp setting and removing all game-specific hacks, thus bringing it more in line with [[Ares]] and [[CEN64]] in accuracy. However, this has resulted in some regressions and compatibility issues, including some games not booting that used to work before. Work is ongoing and regressions are being fixed as they appear, but until this task is completed, consult this [https://github.com/m64p/m64p/issues/288 "known issues" list] before using the latest release. If a game you'd like to play is currently listed as having problems or you run into an issue not on that list, try a build from before the major timing changes (such as [https://github.com/m64p/m64p/releases/tag/v2022.07.6 this one]) or try another emulator such as [[RMG]] or [[RetroArch]]'s Mupen64Plus-Next core, which are much closer to upstream Mupen64Plus at this point. New releases are also quite frequent, so be careful about updating if the games you're playing work fine.<br />
<br />
==Netplay==<br />
Follow [https://github.com/loganmc10/m64p/wiki/Netplay-Guide this guide on the GitHub wiki] to set up netplay.<br />
<br />
==External links==<br />
* [https://discord.gg/tsR3RtYynZ Discord netplay channel]<br />
<br />
[[Category:Emulators]]<br />
[[Category:Console emulators]]<br />
[[Category:Home console emulators]]<br />
[[Category:Nintendo 64 emulators]]<br />
[[Category:Windows emulation software]]<br />
[[Category:Linux emulation software]]<br />
[[Category:Netplay]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=M64p&diff=49430M64p2022-08-22T16:02:22Z<p>GPDP1: More info on m64p's major timing changes and some cautions regarding the highly volatile nature of the situation as it currently stands</p>
<hr />
<div>{{lowercase title}}<br />
{{Infobox emulator<br />
|title = m64p<br />
|logo = <br />
|logowidth = <br />
|screenshot = M64p-screenshot.png<br />
|screenshotcaption = The m64p frontend on Windows 7.<br />
|developer = [https://github.com/loganmc10 loganmc10]<br />
|version = {{Version|m64p}}<br />
|active = Yes<br />
|platform = [[Emulators on Windows|Windows]]<br/>[[Emulators on Linux|Linux]]<br />
|architecture = x64<br />
|target = [[Nintendo 64 emulators|Nintendo 64]]<br />
|compatibility = High<br />
|accuracy = <br />
|website = [https://m64p.github.io/ m64p.github.io]<br />
|prog-lang = C, C++<br />
|support = [https://www.patreon.com/m64p Patreon]<br />
|license = GNU GPLv3<br />
|source = [https://github.com/m64p/m64p GitHub]<br />
}}<br />
'''m64p''' is an open-source, plugin-based [[Nintendo 64 emulators|Nintendo 64 emulator]] maintained by loganmc10. The project bundles [[Mupen64Plus]] with Parallel RDP, as well as its own frontend, input plugin, and netplay support.<br />
<br />
==Download==<br />
{| cellpadding="4"<br />
|-<br />
|align=center|{{Icon|Win-big|Lin-big}}<br />
|[https://github.com/m64p/m64p/releases '''Official releases''']<br />
|-<br />
|align=center|{{Icon|Win|Lin|Mac}}<br />
|[https://github.com/thekovic/m64p/releases/tag/v2021.5.30 Final GLideN64 build (2021-05-30)]<br />
|-<br />
|colspan="3"|<hr/><br />
|-<br />
|align=center|{{Icon|Win|Lin|Mac}}<br />
|[https://github.com/m64p/mupen64plus-gui mupen64plus-gui]<br><small>The frontend that can also be used separately with Mupen64Plus.</small><br />
|}<br />
<br />
==Overview==<br />
In the project's own words:<br />
<blockquote>''"This is likely the most compatible N64 emulator you’re going to come across. It can play games like Resident Evil 2, Rogue Squadron, Pokemon Snap, and World Driver Championship “out-of-the-box” (without the need to fiddle with settings, plugins, or anything of the sort)."''</blockquote><br />
<br />
The user interface, mupen64plus-gui, was written specifically for m64p using Qt5 prior to version 2022.07, and using Qt6 from version 2022.07 onward. The supported features:<br />
<br />
* Netplay using a central server hosted in the cloud for players to find sessions<br />
* Discord Rich Presence and automatic voice channel connectivity<br />
* Standard frontend features like pausing, screenshots, save states etc.<br />
* An auto-updater<br />
<br />
Parallel RDP and RSP are based on the work of [https://github.com/Themaister/parallel-rsp Themaister] and are used in the [https://www.libretro.com/index.php/parallel-n64-with-parallel-rsp-dynarec-release-fast-and-accurate-n64-emulation/ Parallel N64 Libretro core]. This makes fast and accurate N64 emulation possible in m64p.<br />
<br />
As of April 12, 2021, m64p no longer runs properly on macOS systems. The application produces an "unable to load video plugin" error and random application crash at startup. As of June 6th, 2021 it appears that support for macOS is being completely dropped by loganmc10 with the replacement of both the GlideN64 and Angrylion Plus RDPs with ParaLLEl-RDP and the release of Windows and Linux builds only, as macOS lacks the necessary Vulkan support for ParaLLEl-RDP to work, requiring additional Mac-specific work to make it function.<br />
<br />
As of Jul 17, 2022, m64p has undergone a major overhaul of its core timing code independently of upstream [[Mupen64Plus]], getting rid of the CountPerOp setting and removing all game-specific hacks, thus bringing it more in line with [[Ares]] and [[CEN64]] in accuracy. However, this has resulted in some regressions and compatibility issues, including some games not booting that used to work before. Work is ongoing and regressions are being fixed as they appear, but until this task is completed, consult this [https://github.com/m64p/m64p/issues/288 compatibility list] before using the latest release. If a game you'd like to play is currently listed as having problems or you run into an issue not on that list, try a build from before the major timing changes (such as [https://github.com/m64p/m64p/releases/tag/v2022.07.6 this one]) or try another emulator such as [[RMG]] or [[RetroArch]]'s Mupen64Plus-Next core, which are much closer to upstream Mupen64Plus at this point. New releases are also quite frequent, so be careful about updating if the games you're playing work fine.<br />
<br />
==Netplay==<br />
Follow [https://github.com/loganmc10/m64p/wiki/Netplay-Guide this guide on the GitHub wiki] to set up netplay.<br />
<br />
==External links==<br />
* [https://discord.gg/tsR3RtYynZ Discord netplay channel]<br />
<br />
[[Category:Emulators]]<br />
[[Category:Console emulators]]<br />
[[Category:Home console emulators]]<br />
[[Category:Nintendo 64 emulators]]<br />
[[Category:Windows emulation software]]<br />
[[Category:Linux emulation software]]<br />
[[Category:Netplay]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Nintendo_64_emulators&diff=49021Nintendo 64 emulators2022-08-05T18:58:35Z<p>GPDP1: Added mention of Project64's donation nagging and Rosalie's installer that gets rid of it</p>
<hr />
<div>{{Infobox console<br />
|title = Nintendo 64<br />
|logo = Nintendo64Console.png<br />
|developer = [[:Nintendo]]<br />
|type = [[:Category:Home consoles|Home video game console]]<br />
|generation = [[:Category:Fifth-generation video game consoles|Fifth generation]]<br />
|release = 1996<br />
|discontinued = 2002<br />
|predecessor = [[Super Nintendo emulators|SNES]]<br />
|successor = [[GameCube emulators|GameCube]]<br />
|emulated = {{✓}}<br />
}}<br />
<br />
{{for|other emulators that run on N64 hardware|Emulators on N64}} <br />
<br />
<br />
The '''Nintendo 64''' is a 64-bit fifth-generation console released by Nintendo on September 29, 1996 for {{inflation|USD|199.99|1996}}.<br />
<br />
Nintendo was the second company approached by Silicon Graphics Inc. (SGI), who wanted to roll out their previously enterprise-only technology in the consumer space. They originally pitched their idea to Sega, but it's assumed that Nintendo's offer was more appealing. With the NEC VR4300 CPU clocked at 93.75 MHz, 4MB of RAM,<ref group=N>Though a separate add-on was later released called the "Expansion Pak" that added an additional 4MB of RAM, totaling 8MB.</ref> and an SGI RCP GPU, Nintendo had finalized much of the hardware at least a year before launch, preventing video games from needing drastic rewrites as a result of architectural changes. The development workstations were often Unix-based, something that would later help reverse engineers in some projects.<br />
<br />
==Emulators==<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Platform(s)<br />
! scope="col"|Latest version<br />
! scope="col"|Plugins<br />
! scope="col"|Controller Pak<br />
! scope="col"|Rumble Pak<br />
! scope="col"|Transfer Pak<br />
! scope="col"|64DD<br />
! scope="col"|Depth<br/>output<br />
! scope="col"|Texture<br/>enhancement<br />
! scope="col"|Netplay<br />
! scope="col"|[[libretro]]<br />
! scope="col"|<abbr title="Free/Libre and Open-Source Software">FLOSS</abbr><br />
! scope="col"|Active<br />
! scope="col"|[[Recommended emulators|Recommended]]<br />
|-<br />
!colspan="15"|PC / x86<br />
|-<br />
|[[m64p]] (ParaLLEl)<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/m64p/m64p/releases {{M64pVer}}]<br >[https://github.com/m64p/m64p/actions git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}³<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[https://emulation.gametechwiki.com/index.php/RetroArch Mupen64Plus-Next (mupen64plus_next_libretro)]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/windows/x86_64/latest/ nightly]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}¹<br />
|{{✓}}<br />
|{{✓}}*<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[RMG]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/Rosalie241/RMG/releases {{RMGVer}}]<br >[https://github.com/Rosalie241/RMG/actions Dev]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}⁵<br />
|{{✓}}⁵<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Project64]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://www.pj64-emu.com/public-releases {{Project64Ver}}]<br >[https://www.pj64-emu.com/nightly-builds Dev]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[ares]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/ares-emulator/ares/releases {{aresVer}}]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|{{~}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://github.com/mupen64plus/mupen64plus-core/releases git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}⁵<br />
|{{✓}}⁵<br />
|{{~}}²<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[https://emulation.gametechwiki.com/index.php/RetroArch ParaLLEl-N64 (parallel_n64_libretro)]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/windows/x86_64/latest/ nightly]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{✓}}*<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}⁶<br />
|-<br />
|[[1964]]<br />
|align=left|{{Icon|Windows}}<br />
|[http://www.emulation64.com/files/getfile/936/ 1.1] (Official)<br />[http://files.emulation64.fr/Emulateurs/EMU_1964_146.zip 1.2 r146] (Unofficial SVN)<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}⁴<br />
|-<br />
|m64p (Final GLideN64)<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/thekovic/m64p/releases/tag/v2021.5.30 Final GLideN64]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}⁷<br />
|-<br />
|[[BizHawk]]<br />
|align=left|{{Icon|Windows}}<br />
|[http://tasvideos.org/BizHawk/ReleaseHistory.html {{BizHawkVer}}]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[CEN64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/tj90241/cen64 git]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[Project64 Netplay]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://github.com/Project64Netplay/Project64-Netplay-2x git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[DaedalusX64]]<br />
|align=left|{{Icon|Linux}}<br />
|[https://github.com/DaedalusX64/daedalus/releases/latest git]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[Sixtyforce]]<br />
|align=left|{{Icon|macOS}}<br />
|[http://sixtyforce.com/download/ {{SixtyforceVer}}]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Larper64<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://drive.google.com/file/d/1IWyw5UG9Uf24KG0zrcXSFoOmcQoHWmyc/view {{Larper64Ver}}]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|[[UltraHLE]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://web.archive.org/web/20070312015944/http://www.emuunlim.com/UltraHLE/ultrahle.zip 1.0]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|[[MAME]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[http://www.mamedev.org/release.html {{MAMEVer}}]<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[Ryu64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/Ryu64Emulator/Ryu64 git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|R64Emu<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/rasky/r64emu git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
!colspan="15"|Mobile / ARM<br />
|-<br />
|[[Mupen64Plus]] FZ<br />
|align=left|{{Icon|Android}}<br />
|[https://play.google.com/store/apps/details?id=org.mupen64plusae.v3.fzurita 3.0.322 (beta)]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}¹<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Pandora|Pyra}}<br />
|[http://repo.openpandora.org/?page=detail&app=mupen64plus Pandora]<br/>[https://pyra-handheld.com/repo/apps/39 Pyra]<br />
|?<br />
|{{✓}}<br />
|?<br />
|?<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
!colspan="15"|Consoles<br />
|-<br />
|[[Virtual Console]]<br />
|align=left|{{Icon|Wii|WiiU}}<br />
|N/A<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Not64<br />
|align=left|{{Icon|GCN|Wii}}<br />
|[https://github.com/Extrems/Not64/releases/latest git]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|[[DaedalusX64]]<br />
|align=left|{{Icon|PSP|3DS}}<br>{{Icon|Vita|PS2}}<br />
|[https://github.com/DaedalusX64/daedalus/releases/latest PSP]<br/>[https://github.com/masterfeizz/DaedalusX64-3DS/releases 3DS]<br/>[https://github.com/Rinnegatamante/DaedalusX64-vitaGL/releases VitaGL]<br/>[https://www.ps2-home.com/forum/viewtopic.php?f=99&p=39957#p39957 PS2]<br />
|?<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}} <small>(PSP)</small><br />
|{{~}}<br />
|-<br />
|Surreal64 CE<br />
|align=left|{{Icon|Xbox}}<br />
|[https://digiex.net/threads/surreal64-ce-b6-0-download-n64-emulator-for-xbox.13677 Beta 6.0]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|mupen64-360<br />
|align=left|{{Icon|Xbox360}}<br />
|[https://digiex.net/threads/mupen64-360-xbox-360-nintendo-64-n64-emulator-download.9352 0.96 beta]<br />
|?<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|[https://code.google.com/p/mupen64gc/ Wii64]<br />
|align=left|{{Icon|GCN|Wii}}<br />
|[https://code.google.com/archive/p/mupen64gc/downloads 1.1 beta]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|}<br />
<br />
*<nowiki>* Available exclusively as a libretro core</nowiki><br />
*<nowiki>¹ Only supports texture packs, and not filtering or upscaling</nowiki><br />
*<nowiki>² Requires replacing the input plugin to one with netplay support</nowiki><br />
*<nowiki>³ If not using Netplay, use RMG</nowiki><br />
*<nowiki>⁴ Highly recommended to use 1964 GEPD for Goldeneye 007 or Perfect Dark</nowiki><br />
*<nowiki>⁵ Only with GLideN64</nowiki><br />
*<nowiki>⁶ Obsolete and replaced by Mupen64Plus-Next</nowiki><br />
*<nowiki>⁷ RMG with GLideN64 recommended.</nowiki><br />
<br />
===Comparisons===<br />
Although many Nintendo 64 emulators have been made and many games can be run between them, until recently complete compatibility and/or accuracy left a bit to be desired. For half a decade, Mupen64Plus and Project64 have vied for the most playable emulator, and which was more compatible often depended on when and in what configuration each emulator has been tested. As of August 2017, both emulators have roughly equal compatibility and accuracy when running with the same [[recommended N64 plugins]] setup, though both default to Glide64, a now relatively lackluster plugin.<br />
<br />
;[[Mupen64Plus]]<br />
:A multi-platform emulator based on Hacktarux's Mupen64. It's about as accurate as Project64,<ref>loganmc10. [https://github.com/mupen64plus/mupen64plus-core/pull/336 ''Ignore TLB write if TLB entry is unmapping itself'']. "By the way, once this, along with the other PR's I have waiting are merged, we are at "compatibility parity" with Project64 as far as I can tell. I don't know of any game that doesn't boot with mupen64plus that works in PJ64."</ref> when both emulators are run with GLideN64. However, Mupen64Plus lacks a native GUI, instead being launched either from the command line or by dragging and dropping ROMs onto the executable and editing the config with a text editor. It also only comes bundled with outdated video plugins, so to ensure the best possible compatibility, sourcing better third-party plugins such as GLideN64 is a must. [[BizHawk]] and [[OpenEmu]] use forks of Mupen64Plus and its plugins for their N64 emulation, but they seem to be shallow. As of 2022 Project64-style overclocking for faster frame rates has been added under the option 'CountPerOpDenomPot'.<br />
<br />
:;Mupen64Plus-Next and ParaLLEl-N64<br />
:Both are heavily-modified forks developed as [[libretro]] cores. They introduce many features and optimizations not present in mainline alongside [[RetroArch]]'s general features, including 3-point texture filtering for Glide64, superior A/V sync and latency, and even an initially exclusive LLE Vulkan renderer based on Angrylion's pixel-perfect RDP plugin now known as ParaLLEl-RDP, making it a better alternative to the standalone version in some cases. 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.<br />
<br />
::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), considerably cleans up the Core Options menu for easier configuration and 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.<br />
<br />
:;[[m64p]]<br />
:A fork of Mupen64Plus with a custom-made Qt GUI. This is probably the easiest "just works out of the box" solution for Nintendo 64 emulation, as it comes bundled with ParaLLEl-RDP and ParaLLEl-RSP, ensuring both excellent compatibility and good speed without needing to mess with plugins or settings, provided your hardware supports Vulkan. However, unlike other emulators, it does not allow you to use other plugins. While it began as a shallow fork, it has increasingly become something closer to a hard fork, as its developer has opted to make various accuracy-focused changes to the emulation core that will require additional work to port back to upstream or to other forks. It also currently features only an interpreter core, as the dynarecs used by Mupen64Plus are incompatible with the core timing changes made by the developer. While this makes m64p more accurate than most other N64 emulators, it also results in slower performance. If more speed and enhancements are desired, there is an older build that is closer to upstream and uses GLideN64 as its graphics plugin - unfortunately lacking the texture enhancement suite required for use of texture packs and upscaling.<br />
<br />
:;[[RMG]]<br />
:Rosalie's Mupen GUI is a project aiming to close the gap between Project64 and Mupen64Plus in terms of user experience. Its interface is about on par with m64p's in terms of cleanliness and ease of use, but unlike m64p, it allows you to use other plugins. The latest version comes bundled with GLideN64 and ParaLLEl-RDP for video plugins, and mupen64plus-hle-rsp and ParaLLEl-RSP for RSP plugins, though it can still use the older plugins that come with regular Mupen64Plus in case your PC cannot handle the newer plugins. However, it currently does not allow you access to ParaLLEl-RDP's options within its GUI, so if you wish to make use of features such as upscaling or downsampling, you must do so by editing the mupen64plus.cfg file, whereas m64p does expose these options in its GUI. However, if you prefer GLideN64, this is a superior alternative, as it does have access to its settings GUI, and the last version of m64p that uses GLideN64 is becoming increasingly outdated.<br />
<br />
:;Wii64 and Not64<br />
:Both are based on Mupen64, with Not64 being a fork of Wii64. Not64 claims to be better optimized 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 releases whenever possible.<br />
<br />
;[[Project64]]<br />
: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 some of the Mupen64Plus attempts and supports features such as Transfer Pak emulation and 64DD emulation. It now comes with GLideN64 out-of-the-box, but the default audio plugin isn't even the best in the box. Annoyingly, it also nags you with a timed, unskippable message asking for donations to the project upon launch. It is thus recommended to download it through [https://github.com/Rosalie241/BetterMajorasMaskInstaller/releases/tag/4.0.2 Rosalie's BetterMajorasMaskInstaller], which downloads the latest nightly version of Project64 with the nagging message removed and installs several useful third-party plugins (it also downloads HD texture packs for OoT and MM, but you can opt out of that). For the most part, it works well in [[Wine]], but, if you're on a different platform, use Mupen64Plus instead.<br />
<br />
;[[Ares]]<br />
:An open-source multi-system emulator and successor to Near's [[higan]] project, with a mostly original N64 core. Unlike other N64 emulators, it aims for high accuracy and does not employ HLE RSP or RDP emulation of any kind, not does it use game-specific hacks. It uses Themaister's ParaLLEl-RDP Vulkan renderer (with the MAME renderer as a software-based fallback) for pixel-perfect LLE graphics. While it is currently less compatible than Mupen64Plus or Project64, it is quickly catching up to them [https://ares-emu.net/compatibility/15 (only a handful of games are currently listed as partially or not working)], and it currently passes several stringent [https://github.com/ares-emulator/ares/pull/613 accuracy tests] the other emulators do not. However, it remains to be seen how accurate its developers are willing to make it without compromising speed and playability on current machines.<br />
<br />
;[[CEN64]]<br />
:Aims for cycle accuracy while at the same time aiming to eventually be usable on modern PC hardware. It lacks many features and has spotty compatibility, but it can already emulate some well-known edge cases such as picture recognition in Pokemon Snap. Unfortunately, its creator appears to have abandoned the project [https://github.com/n64dev/cen64/releases/tag/v0.3 citing lack of satisfaction with the program's performance in its current interpreter-based incarnation], and while the baton has been collectively passed to the n64dev community for further development, progress has been slow.<br />
<br />
;[[1964]]<br />
:Along with its various versions and forks, it was once a decent, speedy open-source alternative to Project64 and Mupen64, though it usually lagged behind the two compatibility-wise. Nowadays it has completely fallen off the radar as development has halted, and there is no longer a central code repo to speak of. There is little reason to use it nowadays outside of historical purposes, very specific edge cases, or if your device is too slow to run Mupen64Plus or Project64.<br />
<br />
;Daedalus<br />
:Is a Nintendo 64 emulator for PC which was ported to the PSP under the name of DaedalusX64. The PSP version later became the main version and got ported to platforms such as the Dreamcast, the PS2, the PS Vita, and the 3DS. On PSP, several games are able to reach full speed and most of them work with few emulation issues.<br />
<br />
;[[Sixtyforce]]<br />
:Is macOS-only, closed-source, and asks you to pay for full access to its features. It was once one of the only choices for Mac users, particularly those with older Macs since it's the only emulator with a <abbr title="Power PC">PPC</abbr> [[Dynamic recompilation|dynarec]]), but, with the switch to x86 and Mupen64Plus being ported to macOS, it has now become less relevant. However, development is still ongoing and is currently in its [https://sixtyforce.com/rosetta/ third rewrite] to support the upcoming [https://en.wikipedia.org/wiki/Apple-designed_processors Apple Silicon].<br />
<br />
;[[UltraHLE]]<br />
: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.<br />
<br />
;[[Ryu64]]<br />
:Is a Nintendo 64 emulator made in C#. The 'Ryu' word is named after the "RyuJIT" used in both Visual Basic & C#. But it might have been inspired by the lead author's sole (so far) [https://github.com/Ryujinx/Ryujinx/commits?author=Dudejoe870 commit] at Switch emulator, [[Ryujinx]]'s Git repository, and his depreciated [https://github.com/Dudejoe870/RyujinxAutoUpdate Ryujinx Auto Updater] tool. "86RYU", an x86 JIT compiler, is being developed alongside this emulator too.<br />
<br />
;n64oid<br />
:An Android exclusive Nintendo 64 emulator. It is similar to Project 64 1.6 in terms of compatibility, although it is unknown who authored it, as the APK for n64oid circulates on many legally questionable APK sites. n64oid has the infamous problem in Mario Kart 64 of the screen in Wario Stadium not displaying properly, as it displays nothing but black. It upscales all games to widescreen, which works well most of time, but on many phones it will have performance issues. The emulator is relatively poor, but it is much easier to set up than other options. The emulator features a menu with many similarities to the mobile edition of Snes9x EX+, and the My Boy! family of Android emulators for Game Boy systems.<br />
<br />
==Emulation issues==<br />
{{Main|Recommended N64 plugins}}<br />
<br />
Nintendo 64 emulation is now decent. A lot of the major problems that N64 emulation had in the past, have been fixed for quite some time now. The only catch is that the accurate emulators have higher system requirements. The main remaining problem is the lack of accurate cycle counting.<br />
<br />
===[[High/Low level emulation|High-level vs. low-level]] graphics===<br />
<br />
One of the biggest hurdles to emulating the Nintendo 64 was the Reality Display Processor (RDP), which used a custom design that had to be fine-tuned to get more performance out of the system using microcode. To emulate the RDP accurately, one would have to execute said microcode the way the RDP did, which differed from PC graphics cards of the day. To complicate matters further, API standards that were available on PCs two decades ago were nowhere near as flexible as they are today. If you wanted to make an accurate GPU-accelerated RDP plugin in 2003, you simply couldn't with the APIs of the time (OpenGL 1.x and Direct3D 9). For the average user, hardware-accurate GPU acceleration would be out of reach for a long time.<br />
<br />
[[UltraHLE]] offered a compromise. In contrast to earlier consoles, whose video chips in hindsight had been easy to render to the host CPU's framebuffer, performant RDP emulation had to take shortcuts, including programming around specific games' microcode to cleanly translate their graphics commands into API calls using Direct3D, OpenGL, and even Glide. With this, the theoretical system requirements plummeted, 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 is an improvement is subjective and a common point of discussion. Unfortunately it proved to be hit and miss, owing to the nature of per-game microcode detection and having to tweak settings to prevent some games from running into graphical glitches.<br />
<br />
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).<br />
<br />
On the high-level side, gonetz and one or two assistants spent a large portion of development improving GlideN64's microcode handling 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 framebuffer is used as well as performance issues), VI emulation, and how combine/blending modes are emulated (such as noise issues and combiner accuracy).<br />
<br />
<gallery widths="300" mode="packed"><br />
Majora's mask accurate.png| Low-level emulation of Majora's Mask using SoftGraphic<br />
Project64 2013-07-26 14-20-17-55.png| High-level emulation of Majora's Mask using Jabo's Direct3D<br />
</gallery><br />
<br />
===[[Texture filtering]]===<br />
The Nintendo 64 was the first consumer device to be able to filter textures when rendering 3D objects. However, unlike every console and PC graphics card made after the N64, its implementation of bilinear was primitive in that, in order to reduce strain on the system, it only used three samples as opposed to four, resulting in slightly jagged, asymmetrically-filtered textures. Instead of faithfully applying this "imperfect" version of bilinear filtering, HLE plugins instead applied conventional bilinear filtering, interpolating straight from the source texture up to the output resolution the same way a PC game would. While that method is technically superior, it can result in textures that look even blurrier than on real hardware.<br />
<br />
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 pre-rendered backgrounds or menu screens, may look as though they are separated into squares (see images below; note how OoT's Quest Status screen appears to be divided into a grid). 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 oftentimes low resolutions.<br />
<br />
Modern emulators and plugins have taken some steps which help remedy these problems. For instance, GLideN64 now supports N64-style three-point texture filtering, which results in a more faithful look. It is also capable of rendering at 320x240, which sidesteps the issues with filtered text, UI elements, and menu screens, while still retaining texture filtering. Pixel-accurate plugins such as Angrylion and ParaLLEl-RDP do not have these problems at all.<br />
<gallery widths="300" mode="packed"><br />
Project64_2013-06-26_17-44-58-31.png|Conker's Bad Fur Day copyright screen, displaying issues with filtered text.<br />
Mupen64plus_2013-08-18_20-35-50-08.png|Ocarina of Time's menu subscreen, displaying issues with filtering.</gallery><br />
<br />
===Timing issues===<br />
One of the biggest remaining problems in N64 emulation is lack of accurate core timings, which in practice means games do not always run at the speed they would on real hardware. While this technically affects all games, the majority are only affected to a negligible degree, and in some instances (particularly in Rare games) this can actually result in less framerate drops and lag, which can be seen as beneficial. However, some game engines actually depend on accurate timings for proper game behavior, and not properly emulating them can result in considerable to major issues. Some notable examples include the following:<br />
* Intros and cutscenes playing too fast and not properly syncing up with musical cues. Seen in Goldeneye's intro and Body Harvest's beginning cutscene.<br />
* Gameplay demos running at hyper speed. Earthworm Jim 3D is most notorious for this, though the main game itself is largely unaffected.<br />
* Game physics not working properly due to being tied to framerate. A good example is Donkey Kong 64, which is programmed to boost the character's speed and momentum proportional to in-game lag (most likely to make up for the game's frequent framerate drops), which can be exploited for certain glitches and sequence breaks on real hardware. Emulators currently run the game too well and with too little lag, making most of these tricks impossible to pull off.<br />
* Possibly the most affected game is Knife's Edge, which runs like it's on permanent fast-forward, making it all but unplayable. Messing with timing-related settings such as CounterFactor can mitigate this somewhat, but nowhere near enough to fix the issue.<br />
Fortunately, tackling these problems has recently become a core focus of development in some N64 emulators, and attempts are underway to improve the situation. Ares currently has the most accurate timings overall, and already runs Earthworm Jim 3D's demos much better than other emulators. Meanwhile, m64p has recently pushed various timing-related commits aimed at improving accuracy, and as a result it may now be the only emulator that runs Donkey Kong 64 properly. As these efforts progress, it should be noted that a side-effect of improved timings may be greater in-game lag. This should not be seen as the emulator becoming slower, but rather the emulator behaving exactly like real hardware does, as many N64 games were notorious for framerate drops.<br />
<br />
==Peripherals==<br />
===Voice Recognition Unit emulation===<br />
The Voice Recognition Unit (VRU) is an accessory used primarily by ''Hey You, Pikachu''. No emulator or input plugin supports this, although there is an on-going effort to get it working.<ref name="emutalk">{{cite web|url=http://www.emutalk.net/threads/55279|title=Hey You! Pikachu - Possible HLE Implementation|publisher=emutalk|accessdate=2018-06-17|date=2014-10-27, Last edit: 2016-04-04}}</ref><br />
===''Densha De Go!'' Controller===<br />
Also available for the [[PlayStation emulators|PlayStation]], ''Densha De Go! 64'' is a Japan-only train simulator released by [[Wikipedia:Taito|Taito]] that is compatible with an optional special controller that plugs into the player 3 port.<ref name="ArcadeUSA">{{cite web|url=https://www.youtube.com/watch?v=cCcPAGhcnck|title=Densha De Go! Nintendo 64 Controller!|publisher=YouTube|accessdate=2018-06-17|date=2017-01-20}}</ref> No emulator supports it.<br />
<br />
===Pokémon Snap Station===<br />
There was a special kiosk designed to promote ''Pokémon Snap'' called the ''Pokémon Snap Station'', which is also compatible with the North American ''Pokémon Stadium'' with its gallery mode. It is just a Nintendo 64 with special hardware designed for the station.<ref name="Sixty Formula">{{cite web|url=https://www.youtube.com/watch?v=AMbjvGvPkV4|title=The Pokemon Snap Station|publisher=YouTube|accessdate=2018-06-17|date=2016-05-21}}</ref><ref name="MetalJesusRocks">{{cite web|url=https://www.youtube.com/watch?v=5_UGpRN6AnM&t=3m35s|title=VIDEO GAME KIOSKS - Extreme Game Collecting!|publisher=YouTube|accessdate=2018-06-17|date=2016-05-25}}</ref> Although the special cartridge boots in emulators compatible with the regular version, the printing functions are inaccessible due to no emulation of the printer for the player 4 slot, credit system, or the special board to switch between the regular and special cartridges.<br />
<br />
===Transfer Pak emulation===<br />
A few games use the Transfer Pak such as ''Mario Golf'', ''Mario Tennis'', ''Mario Artist: Paint Studio'', and the ''Pokémon Stadium'' games. Mostly, this can be done with NRage's input plugin, but a couple of things aren't emulated:<br />
<br />
*Taking pictures with the Japanese ''Game Boy Camera'' (called ''Pocket Camera'') while in Transfer Pak mode playing ''Mario Artist: Paint Studio'' displays static.<br />
<br />
===64DD emulation===<br />
The 64DD (an abbreviation for "64 Disk Drive") was a peripheral which allowed a proprietary disk format to be used with the N64. These disks had more space at a cheaper manufacturing cost. The peripheral was a commercial failure and was never released outside of Japan. Internal evidence suggests that, much like the GBA e-Reader, it wasn't even intended for a European release.<br />
<br />
Expansion disks are region-coded to either Japan or the US (obviously unused) and won't work with N64 games from the wrong region. Only F-Zero X has full support for this feature, but dummied-out expansion data in Ocarina of Time and Mario Party 2 (JP/PAL) exist as well.<br />
<br />
The special AV-In cartridge (NUS-028) that ''Mario Artist: Talent Studio'' can use doesn't work because it requires an RCA cable signal.<br />
<br />
Recently, there has been an effort to emulate the 64DD, and now [[Project64]] and [[MAME]] can run several commercial 64DD games as part of its N64 emulator. This is being ported to [[CEN64]] with the help of [https://twitter.com/LuigiBlood LuigiBlood]. The latest newcomer is Mupen64Plus which is the base of other emulators such as [[m64p]] and [[RMG]].<br />
<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Platform(s)<br />
! scope="col"|Latest Version<br />
! scope="col"|N64 Mouse<br />
! scope="col"|64DD Emulation<br />
! scope="col"|Active<br />
! scope="col"|[[Recommended emulators|Recommended]]<br />
|-<br />
! colspan="7"|PC / x86<br />
|-<br />
|[https://emulation.gametechwiki.com/index.php/RetroArch Mupen64Plus-Next (mupen64plus_next_libretro)]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/windows/x86_64/latest/ nightly]<br />
|{{✓}}<br />
|Mid/High<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Project64]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://github.com/project64/project64 {{Project64Ver}}]<br >[https://64dd.org/downloads.html 64DD.org Builds]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[https://emulation.gametechwiki.com/index.php/RetroArch ParaLLEl-N64 (parallel_n64_libretro)]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/windows/x86_64/latest/ nightly]<br />
|{{✓}}<br />
|Mid/High<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[CEN64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/tj90241/cen64 git]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[MAME]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[http://www.mamedev.org/release.html {{MAMEVer}}]<br />
|{{✗}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[m64p]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/m64p/m64p/releases {{M64pVer}}]<br >[https://github.com/m64p/m64p/actions git]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|{{✗}} (WIP)<br />
|-<br />
|[[RMG]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/Rosalie241/RMG/releases {{RMGVer}}]<br >[https://github.com/Rosalie241/RMG/actions Dev]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|{{✗}} (WIP)<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://github.com/mupen64plus/mupen64plus-core/releases git]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|{{✗}} (WIP)<br />
|}<br />
<br />
* Project64's latest versions emulate the N64 mouse and can load Zoinkity's hacked 64DD cartridge conversions at playable speeds. You'll need to set every game to have 8MB of Memory by default manually. Games do not save, some need "32-bit engine" to be unchecked (like Talent Studio), and some (like Polygon Studio to fix models and Paint Studio to fix stamps) need the Angrylion GFX plugin rather than GlideN64, which does the job for the rest.<br />
**The 64DD hardware started to be emulated around 2.3's release with the help of [https://github.com/LuigiBlood LuigiBlood]. Saving works but in the form of NDR files. NDR files are copied versions of NDD images with save data included as to not write to the clean unaltered images. In order to play 64DD games in their original forms, 8MB of memory is still needed because the real hardware needed the Expansion Pak upgrade. The IPL is also needed.<br />
<br />
* MAME includes early basic 64DD emulation as well but is much slower. Disk images need to be in head/track format. See [https://github.com/Happy-yappH/ddconvert.git here] for more information. It does not currently support disk swapping or saving disk to files. Writes only update the copy in memory, and, once the MAME process ends, the changes are lost. Current usage: <code>mame n64dd -quickload disk -cart cart -nodrc</code> (both disk and cart are optional)<br />
<br />
* CEN64, like Project64, had 64DD emulation ported to it from MAME. However, it focuses on accuracy and plays much slower than other emulators, aside from the 64DD emulation itself is imperfect.<br />
<br />
==Hardware variants==<br />
===iQue Player emulation===<br />
Before the GBA, DS, and 3DS, Nintendo released a modified version of their Nintendo 64 system for the Chinese market, which was called the iQue Player, through their not-quite-subsidiary iQue. Fourteen games were translated into Simplified Chinese, including Sin and Punishment, Ocarina of Time (the Majora's Mask port was canceled), Super Mario 64, and others.<br />
<br />
Unlike the Chinese releases of their more recent systems and their games, iQue Player releases are regular N64 roms wrapped with several layers of encryption, as well as a ticket and signature system like that on Wii, DSi, 3DS, Wii U, and Switch. The Chinese ROM-hacking scene is very active though and has translated the Japanese regular N64 releases for many of these to their language already, which explains some of the Chinese ROMs floating for those. However, recently, almost all pieces of iQue Player software were decrypted to regular .z64 ROM format.<br />
<br />
Several of the Chinese game localizations already run on N64 emulators, but as some hardware features of the iQue Player are not yet supported, some games, as well as the system menu and features in games such as saving, do not work yet.<br />
<br />
===Aleck 64 arcade emulation===<br />
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). 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.<br />
<br />
The Aleck 64 ROMs were dumped, and Zoinkity is working on converting them to regular N64 ROMs (with controls remapped to N64 controller buttons). They generally require an 8MB Expansion Pak to run at all and 4K EEPROM to save settings and scores. The ones covered by these patches are:<br />
<br />
* Donchan Puzzle Hanabi de Doon!<br />
* Eleven Beat: World Tournament<br />
* Hi Pai Paradise<br />
* Hi Pai Paradise 2<br />
* Kuru Kuru Fever<br />
* Magical Tetris Challenge<br />
* Mayjinsen 3 / Meijin-Sen<br />
* Star Soldier: Vanishing Earth (also ported to N64)<br />
* Super Real Mahjong VS<br />
* Tower & Shaft<br />
* Vivid Dolls (official eroge game on a Nintendo console)<br />
<br />
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.<br />
<br />
The remaining ones from the system's library not yet covered are:<br />
* Rev Limit<br />
* Variant Schwanzer<br />
<br />
==Virtual Console games in Dolphin==<br />
A number of N64 games were released for the Wii's Virtual Console service throughout its lifespan. While the emulators at the heart of each Virtual Console title were of average accuracy (rather than using one generic emulator used for every game, each title had an emulator specifically tailored to that game), they were good enough to render the games in full playable capacity with few to no glaring errors. Many of these titles are emulated well through Dolphin, and for a good while, due to persistent long-standing inaccuracies in N64 emulators and plugins, this was the best way to emulate certain N64 games, particularly Pokemon Snap and Mario Tennis. The system requirements are much higher than running them on regular N64 emulators, but it's doable for many games. Today, regular N64 emulators and plugins have advanced to the degree that this has become unnecessary, relegating this method of N64 game emulation to little more than a curiosity, at least on PC.<br />
<br />
The following games are on the N64 Virtual Console for Wii:<br />
<br />
{|width="100%"<br />
|- valign="top"<br />
|<br />
* 1080 Snowboarding<br />
* Bomberman Hero<br />
* Cruis'n USA<br />
* Custom Robo V2 (Japan only)<br />
* F-Zero X<br />
* Kirby 64: The Crystal Stars<br />
* The Legend of Zelda: Majora's Mask<br />
* The Legend of Zelda: Ocarina of Time<br />
|<br />
* Mario Golf<br />
* Mario Kart 64<br />
* Mario Party 2<br />
* Mario Tennis<br />
* Ogre Battle 64: Person of Lordly Caliber<br />
* Paper Mario<br />
* Pokemon Puzzle League<br />
|<br />
* Pokemon Snap<br />
* Sin & Punishment (English)<br />
* Star Fox 64<br />
* Super Mario 64<br />
* Super Smash Bros.<br />
* Wave Race 64<br />
* Yoshi's Story<br />
|}<br />
<br />
==Notes==<br />
<references group=N /><br />
<br />
==References==<br />
<references/><br />
<br />
{{Nintendo}}<br />
<br />
[[Category:Consoles]]<br />
[[Category:Home consoles]]<br />
[[Category:Fifth-generation video game consoles]]<br />
[[Category:Nintendo consoles]]<br />
[[Category:Nintendo 64 emulators|*]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Nintendo_64_emulators&diff=49020Nintendo 64 emulators2022-08-05T17:47:04Z<p>GPDP1: A bit more info on Mupen64Plus plugins and RMG's compatibility with them</p>
<hr />
<div>{{Infobox console<br />
|title = Nintendo 64<br />
|logo = Nintendo64Console.png<br />
|developer = [[:Nintendo]]<br />
|type = [[:Category:Home consoles|Home video game console]]<br />
|generation = [[:Category:Fifth-generation video game consoles|Fifth generation]]<br />
|release = 1996<br />
|discontinued = 2002<br />
|predecessor = [[Super Nintendo emulators|SNES]]<br />
|successor = [[GameCube emulators|GameCube]]<br />
|emulated = {{✓}}<br />
}}<br />
<br />
{{for|other emulators that run on N64 hardware|Emulators on N64}} <br />
<br />
<br />
The '''Nintendo 64''' is a 64-bit fifth-generation console released by Nintendo on September 29, 1996 for {{inflation|USD|199.99|1996}}.<br />
<br />
Nintendo was the second company approached by Silicon Graphics Inc. (SGI), who wanted to roll out their previously enterprise-only technology in the consumer space. They originally pitched their idea to Sega, but it's assumed that Nintendo's offer was more appealing. With the NEC VR4300 CPU clocked at 93.75 MHz, 4MB of RAM,<ref group=N>Though a separate add-on was later released called the "Expansion Pak" that added an additional 4MB of RAM, totaling 8MB.</ref> and an SGI RCP GPU, Nintendo had finalized much of the hardware at least a year before launch, preventing video games from needing drastic rewrites as a result of architectural changes. The development workstations were often Unix-based, something that would later help reverse engineers in some projects.<br />
<br />
==Emulators==<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Platform(s)<br />
! scope="col"|Latest version<br />
! scope="col"|Plugins<br />
! scope="col"|Controller Pak<br />
! scope="col"|Rumble Pak<br />
! scope="col"|Transfer Pak<br />
! scope="col"|64DD<br />
! scope="col"|Depth<br/>output<br />
! scope="col"|Texture<br/>enhancement<br />
! scope="col"|Netplay<br />
! scope="col"|[[libretro]]<br />
! scope="col"|<abbr title="Free/Libre and Open-Source Software">FLOSS</abbr><br />
! scope="col"|Active<br />
! scope="col"|[[Recommended emulators|Recommended]]<br />
|-<br />
!colspan="15"|PC / x86<br />
|-<br />
|[[m64p]] (ParaLLEl)<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/m64p/m64p/releases {{M64pVer}}]<br >[https://github.com/m64p/m64p/actions git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}³<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[https://emulation.gametechwiki.com/index.php/RetroArch Mupen64Plus-Next (mupen64plus_next_libretro)]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/windows/x86_64/latest/ nightly]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}¹<br />
|{{✓}}<br />
|{{✓}}*<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[RMG]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/Rosalie241/RMG/releases {{RMGVer}}]<br >[https://github.com/Rosalie241/RMG/actions Dev]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}⁵<br />
|{{✓}}⁵<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Project64]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://www.pj64-emu.com/public-releases {{Project64Ver}}]<br >[https://www.pj64-emu.com/nightly-builds Dev]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[ares]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/ares-emulator/ares/releases {{aresVer}}]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|{{~}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://github.com/mupen64plus/mupen64plus-core/releases git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}⁵<br />
|{{✓}}⁵<br />
|{{~}}²<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[https://emulation.gametechwiki.com/index.php/RetroArch ParaLLEl-N64 (parallel_n64_libretro)]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/windows/x86_64/latest/ nightly]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{✓}}*<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}⁶<br />
|-<br />
|[[1964]]<br />
|align=left|{{Icon|Windows}}<br />
|[http://www.emulation64.com/files/getfile/936/ 1.1] (Official)<br />[http://files.emulation64.fr/Emulateurs/EMU_1964_146.zip 1.2 r146] (Unofficial SVN)<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}⁴<br />
|-<br />
|m64p (Final GLideN64)<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/thekovic/m64p/releases/tag/v2021.5.30 Final GLideN64]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}⁷<br />
|-<br />
|[[BizHawk]]<br />
|align=left|{{Icon|Windows}}<br />
|[http://tasvideos.org/BizHawk/ReleaseHistory.html {{BizHawkVer}}]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[CEN64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/tj90241/cen64 git]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[Project64 Netplay]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://github.com/Project64Netplay/Project64-Netplay-2x git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[DaedalusX64]]<br />
|align=left|{{Icon|Linux}}<br />
|[https://github.com/DaedalusX64/daedalus/releases/latest git]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[Sixtyforce]]<br />
|align=left|{{Icon|macOS}}<br />
|[http://sixtyforce.com/download/ {{SixtyforceVer}}]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Larper64<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://drive.google.com/file/d/1IWyw5UG9Uf24KG0zrcXSFoOmcQoHWmyc/view {{Larper64Ver}}]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|[[UltraHLE]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://web.archive.org/web/20070312015944/http://www.emuunlim.com/UltraHLE/ultrahle.zip 1.0]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|[[MAME]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[http://www.mamedev.org/release.html {{MAMEVer}}]<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[Ryu64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/Ryu64Emulator/Ryu64 git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|R64Emu<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/rasky/r64emu git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
!colspan="15"|Mobile / ARM<br />
|-<br />
|[[Mupen64Plus]] FZ<br />
|align=left|{{Icon|Android}}<br />
|[https://play.google.com/store/apps/details?id=org.mupen64plusae.v3.fzurita 3.0.322 (beta)]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}¹<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Pandora|Pyra}}<br />
|[http://repo.openpandora.org/?page=detail&app=mupen64plus Pandora]<br/>[https://pyra-handheld.com/repo/apps/39 Pyra]<br />
|?<br />
|{{✓}}<br />
|?<br />
|?<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
!colspan="15"|Consoles<br />
|-<br />
|[[Virtual Console]]<br />
|align=left|{{Icon|Wii|WiiU}}<br />
|N/A<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Not64<br />
|align=left|{{Icon|GCN|Wii}}<br />
|[https://github.com/Extrems/Not64/releases/latest git]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|[[DaedalusX64]]<br />
|align=left|{{Icon|PSP|3DS}}<br>{{Icon|Vita|PS2}}<br />
|[https://github.com/DaedalusX64/daedalus/releases/latest PSP]<br/>[https://github.com/masterfeizz/DaedalusX64-3DS/releases 3DS]<br/>[https://github.com/Rinnegatamante/DaedalusX64-vitaGL/releases VitaGL]<br/>[https://www.ps2-home.com/forum/viewtopic.php?f=99&p=39957#p39957 PS2]<br />
|?<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}} <small>(PSP)</small><br />
|{{~}}<br />
|-<br />
|Surreal64 CE<br />
|align=left|{{Icon|Xbox}}<br />
|[https://digiex.net/threads/surreal64-ce-b6-0-download-n64-emulator-for-xbox.13677 Beta 6.0]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|mupen64-360<br />
|align=left|{{Icon|Xbox360}}<br />
|[https://digiex.net/threads/mupen64-360-xbox-360-nintendo-64-n64-emulator-download.9352 0.96 beta]<br />
|?<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|[https://code.google.com/p/mupen64gc/ Wii64]<br />
|align=left|{{Icon|GCN|Wii}}<br />
|[https://code.google.com/archive/p/mupen64gc/downloads 1.1 beta]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|}<br />
<br />
*<nowiki>* Available exclusively as a libretro core</nowiki><br />
*<nowiki>¹ Only supports texture packs, and not filtering or upscaling</nowiki><br />
*<nowiki>² Requires replacing the input plugin to one with netplay support</nowiki><br />
*<nowiki>³ If not using Netplay, use RMG</nowiki><br />
*<nowiki>⁴ Highly recommended to use 1964 GEPD for Goldeneye 007 or Perfect Dark</nowiki><br />
*<nowiki>⁵ Only with GLideN64</nowiki><br />
*<nowiki>⁶ Obsolete and replaced by Mupen64Plus-Next</nowiki><br />
*<nowiki>⁷ RMG with GLideN64 recommended.</nowiki><br />
<br />
===Comparisons===<br />
Although many Nintendo 64 emulators have been made and many games can be run between them, until recently complete compatibility and/or accuracy left a bit to be desired. For half a decade, Mupen64Plus and Project64 have vied for the most playable emulator, and which was more compatible often depended on when and in what configuration each emulator has been tested. As of August 2017, both emulators have roughly equal compatibility and accuracy when running with the same [[recommended N64 plugins]] setup, though both default to Glide64, a now relatively lackluster plugin.<br />
<br />
;[[Mupen64Plus]]<br />
:A multi-platform emulator based on Hacktarux's Mupen64. It's about as accurate as Project64,<ref>loganmc10. [https://github.com/mupen64plus/mupen64plus-core/pull/336 ''Ignore TLB write if TLB entry is unmapping itself'']. "By the way, once this, along with the other PR's I have waiting are merged, we are at "compatibility parity" with Project64 as far as I can tell. I don't know of any game that doesn't boot with mupen64plus that works in PJ64."</ref> when both emulators are run with GLideN64. However, Mupen64Plus lacks a native GUI, instead being launched either from the command line or by dragging and dropping ROMs onto the executable and editing the config with a text editor. It also only comes bundled with outdated video plugins, so to ensure the best possible compatibility, sourcing better third-party plugins such as GLideN64 is a must. [[BizHawk]] and [[OpenEmu]] use forks of Mupen64Plus and its plugins for their N64 emulation, but they seem to be shallow. As of 2022 Project64-style overclocking for faster frame rates has been added under the option 'CountPerOpDenomPot'.<br />
<br />
:;Mupen64Plus-Next and ParaLLEl-N64<br />
:Both are heavily-modified forks developed as [[libretro]] cores. They introduce many features and optimizations not present in mainline alongside [[RetroArch]]'s general features, including 3-point texture filtering for Glide64, superior A/V sync and latency, and even an initially exclusive LLE Vulkan renderer based on Angrylion's pixel-perfect RDP plugin now known as ParaLLEl-RDP, making it a better alternative to the standalone version in some cases. 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.<br />
<br />
::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), considerably cleans up the Core Options menu for easier configuration and 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.<br />
<br />
:;[[m64p]]<br />
:A fork of Mupen64Plus with a custom-made Qt GUI. This is probably the easiest "just works out of the box" solution for Nintendo 64 emulation, as it comes bundled with ParaLLEl-RDP and ParaLLEl-RSP, ensuring both excellent compatibility and good speed without needing to mess with plugins or settings, provided your hardware supports Vulkan. However, unlike other emulators, it does not allow you to use other plugins. While it began as a shallow fork, it has increasingly become something closer to a hard fork, as its developer has opted to make various accuracy-focused changes to the emulation core that will require additional work to port back to upstream or to other forks. It also currently features only an interpreter core, as the dynarecs used by Mupen64Plus are incompatible with the core timing changes made by the developer. While this makes m64p more accurate than most other N64 emulators, it also results in slower performance. If more speed and enhancements are desired, there is an older build that is closer to upstream and uses GLideN64 as its graphics plugin - unfortunately lacking the texture enhancement suite required for use of texture packs and upscaling.<br />
<br />
:;[[RMG]]<br />
:Rosalie's Mupen GUI is a project aiming to close the gap between Project64 and Mupen64Plus in terms of user experience. Its interface is about on par with m64p's in terms of cleanliness and ease of use, but unlike m64p, it allows you to use other plugins. The latest version comes bundled with GLideN64 and ParaLLEl-RDP for video plugins, and mupen64plus-hle-rsp and ParaLLEl-RSP for RSP plugins, though it can still use the older plugins that come with regular Mupen64Plus in case your PC cannot handle the newer plugins. However, it currently does not allow you access to ParaLLEl-RDP's options within its GUI, so if you wish to make use of features such as upscaling or downsampling, you must do so by editing the mupen64plus.cfg file, whereas m64p does expose these options in its GUI. However, if you prefer GLideN64, this is a superior alternative, as it does have access to its settings GUI, and the last version of m64p that uses GLideN64 is becoming increasingly outdated.<br />
<br />
:;Wii64 and Not64<br />
:Both are based on Mupen64, with Not64 being a fork of Wii64. Not64 claims to be better optimized 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 releases whenever possible.<br />
<br />
;[[Project64]]<br />
: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 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.<br />
<br />
;[[Ares]]<br />
:An open-source multi-system emulator and successor to Near's [[higan]] project, with a mostly original N64 core. Unlike other N64 emulators, it aims for high accuracy and does not employ HLE RSP or RDP emulation of any kind, not does it use game-specific hacks. It uses Themaister's ParaLLEl-RDP Vulkan renderer (with the MAME renderer as a software-based fallback) for pixel-perfect LLE graphics. While it is currently less compatible than Mupen64Plus or Project64, it is quickly catching up to them [https://ares-emu.net/compatibility/15 (only a handful of games are currently listed as partially or not working)], and it currently passes several stringent [https://github.com/ares-emulator/ares/pull/613 accuracy tests] the other emulators do not. However, it remains to be seen how accurate its developers are willing to make it without compromising speed and playability on current machines.<br />
<br />
;[[CEN64]]<br />
:Aims for cycle accuracy while at the same time aiming to eventually be usable on modern PC hardware. It lacks many features and has spotty compatibility, but it can already emulate some well-known edge cases such as picture recognition in Pokemon Snap. Unfortunately, its creator appears to have abandoned the project [https://github.com/n64dev/cen64/releases/tag/v0.3 citing lack of satisfaction with the program's performance in its current interpreter-based incarnation], and while the baton has been collectively passed to the n64dev community for further development, progress has been slow.<br />
<br />
;[[1964]]<br />
:Along with its various versions and forks, it was once a decent, speedy open-source alternative to Project64 and Mupen64, though it usually lagged behind the two compatibility-wise. Nowadays it has completely fallen off the radar as development has halted, and there is no longer a central code repo to speak of. There is little reason to use it nowadays outside of historical purposes, very specific edge cases, or if your device is too slow to run Mupen64Plus or Project64.<br />
<br />
;Daedalus<br />
:Is a Nintendo 64 emulator for PC which was ported to the PSP under the name of DaedalusX64. The PSP version later became the main version and got ported to platforms such as the Dreamcast, the PS2, the PS Vita, and the 3DS. On PSP, several games are able to reach full speed and most of them work with few emulation issues.<br />
<br />
;[[Sixtyforce]]<br />
:Is macOS-only, closed-source, and asks you to pay for full access to its features. It was once one of the only choices for Mac users, particularly those with older Macs since it's the only emulator with a <abbr title="Power PC">PPC</abbr> [[Dynamic recompilation|dynarec]]), but, with the switch to x86 and Mupen64Plus being ported to macOS, it has now become less relevant. However, development is still ongoing and is currently in its [https://sixtyforce.com/rosetta/ third rewrite] to support the upcoming [https://en.wikipedia.org/wiki/Apple-designed_processors Apple Silicon].<br />
<br />
;[[UltraHLE]]<br />
: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.<br />
<br />
;[[Ryu64]]<br />
:Is a Nintendo 64 emulator made in C#. The 'Ryu' word is named after the "RyuJIT" used in both Visual Basic & C#. But it might have been inspired by the lead author's sole (so far) [https://github.com/Ryujinx/Ryujinx/commits?author=Dudejoe870 commit] at Switch emulator, [[Ryujinx]]'s Git repository, and his depreciated [https://github.com/Dudejoe870/RyujinxAutoUpdate Ryujinx Auto Updater] tool. "86RYU", an x86 JIT compiler, is being developed alongside this emulator too.<br />
<br />
;n64oid<br />
:An Android exclusive Nintendo 64 emulator. It is similar to Project 64 1.6 in terms of compatibility, although it is unknown who authored it, as the APK for n64oid circulates on many legally questionable APK sites. n64oid has the infamous problem in Mario Kart 64 of the screen in Wario Stadium not displaying properly, as it displays nothing but black. It upscales all games to widescreen, which works well most of time, but on many phones it will have performance issues. The emulator is relatively poor, but it is much easier to set up than other options. The emulator features a menu with many similarities to the mobile edition of Snes9x EX+, and the My Boy! family of Android emulators for Game Boy systems.<br />
<br />
==Emulation issues==<br />
{{Main|Recommended N64 plugins}}<br />
<br />
Nintendo 64 emulation is now decent. A lot of the major problems that N64 emulation had in the past, have been fixed for quite some time now. The only catch is that the accurate emulators have higher system requirements. The main remaining problem is the lack of accurate cycle counting.<br />
<br />
===[[High/Low level emulation|High-level vs. low-level]] graphics===<br />
<br />
One of the biggest hurdles to emulating the Nintendo 64 was the Reality Display Processor (RDP), which used a custom design that had to be fine-tuned to get more performance out of the system using microcode. To emulate the RDP accurately, one would have to execute said microcode the way the RDP did, which differed from PC graphics cards of the day. To complicate matters further, API standards that were available on PCs two decades ago were nowhere near as flexible as they are today. If you wanted to make an accurate GPU-accelerated RDP plugin in 2003, you simply couldn't with the APIs of the time (OpenGL 1.x and Direct3D 9). For the average user, hardware-accurate GPU acceleration would be out of reach for a long time.<br />
<br />
[[UltraHLE]] offered a compromise. In contrast to earlier consoles, whose video chips in hindsight had been easy to render to the host CPU's framebuffer, performant RDP emulation had to take shortcuts, including programming around specific games' microcode to cleanly translate their graphics commands into API calls using Direct3D, OpenGL, and even Glide. With this, the theoretical system requirements plummeted, 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 is an improvement is subjective and a common point of discussion. Unfortunately it proved to be hit and miss, owing to the nature of per-game microcode detection and having to tweak settings to prevent some games from running into graphical glitches.<br />
<br />
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).<br />
<br />
On the high-level side, gonetz and one or two assistants spent a large portion of development improving GlideN64's microcode handling 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 framebuffer is used as well as performance issues), VI emulation, and how combine/blending modes are emulated (such as noise issues and combiner accuracy).<br />
<br />
<gallery widths="300" mode="packed"><br />
Majora's mask accurate.png| Low-level emulation of Majora's Mask using SoftGraphic<br />
Project64 2013-07-26 14-20-17-55.png| High-level emulation of Majora's Mask using Jabo's Direct3D<br />
</gallery><br />
<br />
===[[Texture filtering]]===<br />
The Nintendo 64 was the first consumer device to be able to filter textures when rendering 3D objects. However, unlike every console and PC graphics card made after the N64, its implementation of bilinear was primitive in that, in order to reduce strain on the system, it only used three samples as opposed to four, resulting in slightly jagged, asymmetrically-filtered textures. Instead of faithfully applying this "imperfect" version of bilinear filtering, HLE plugins instead applied conventional bilinear filtering, interpolating straight from the source texture up to the output resolution the same way a PC game would. While that method is technically superior, it can result in textures that look even blurrier than on real hardware.<br />
<br />
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 pre-rendered backgrounds or menu screens, may look as though they are separated into squares (see images below; note how OoT's Quest Status screen appears to be divided into a grid). 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 oftentimes low resolutions.<br />
<br />
Modern emulators and plugins have taken some steps which help remedy these problems. For instance, GLideN64 now supports N64-style three-point texture filtering, which results in a more faithful look. It is also capable of rendering at 320x240, which sidesteps the issues with filtered text, UI elements, and menu screens, while still retaining texture filtering. Pixel-accurate plugins such as Angrylion and ParaLLEl-RDP do not have these problems at all.<br />
<gallery widths="300" mode="packed"><br />
Project64_2013-06-26_17-44-58-31.png|Conker's Bad Fur Day copyright screen, displaying issues with filtered text.<br />
Mupen64plus_2013-08-18_20-35-50-08.png|Ocarina of Time's menu subscreen, displaying issues with filtering.</gallery><br />
<br />
===Timing issues===<br />
One of the biggest remaining problems in N64 emulation is lack of accurate core timings, which in practice means games do not always run at the speed they would on real hardware. While this technically affects all games, the majority are only affected to a negligible degree, and in some instances (particularly in Rare games) this can actually result in less framerate drops and lag, which can be seen as beneficial. However, some game engines actually depend on accurate timings for proper game behavior, and not properly emulating them can result in considerable to major issues. Some notable examples include the following:<br />
* Intros and cutscenes playing too fast and not properly syncing up with musical cues. Seen in Goldeneye's intro and Body Harvest's beginning cutscene.<br />
* Gameplay demos running at hyper speed. Earthworm Jim 3D is most notorious for this, though the main game itself is largely unaffected.<br />
* Game physics not working properly due to being tied to framerate. A good example is Donkey Kong 64, which is programmed to boost the character's speed and momentum proportional to in-game lag (most likely to make up for the game's frequent framerate drops), which can be exploited for certain glitches and sequence breaks on real hardware. Emulators currently run the game too well and with too little lag, making most of these tricks impossible to pull off.<br />
* Possibly the most affected game is Knife's Edge, which runs like it's on permanent fast-forward, making it all but unplayable. Messing with timing-related settings such as CounterFactor can mitigate this somewhat, but nowhere near enough to fix the issue.<br />
Fortunately, tackling these problems has recently become a core focus of development in some N64 emulators, and attempts are underway to improve the situation. Ares currently has the most accurate timings overall, and already runs Earthworm Jim 3D's demos much better than other emulators. Meanwhile, m64p has recently pushed various timing-related commits aimed at improving accuracy, and as a result it may now be the only emulator that runs Donkey Kong 64 properly. As these efforts progress, it should be noted that a side-effect of improved timings may be greater in-game lag. This should not be seen as the emulator becoming slower, but rather the emulator behaving exactly like real hardware does, as many N64 games were notorious for framerate drops.<br />
<br />
==Peripherals==<br />
===Voice Recognition Unit emulation===<br />
The Voice Recognition Unit (VRU) is an accessory used primarily by ''Hey You, Pikachu''. No emulator or input plugin supports this, although there is an on-going effort to get it working.<ref name="emutalk">{{cite web|url=http://www.emutalk.net/threads/55279|title=Hey You! Pikachu - Possible HLE Implementation|publisher=emutalk|accessdate=2018-06-17|date=2014-10-27, Last edit: 2016-04-04}}</ref><br />
===''Densha De Go!'' Controller===<br />
Also available for the [[PlayStation emulators|PlayStation]], ''Densha De Go! 64'' is a Japan-only train simulator released by [[Wikipedia:Taito|Taito]] that is compatible with an optional special controller that plugs into the player 3 port.<ref name="ArcadeUSA">{{cite web|url=https://www.youtube.com/watch?v=cCcPAGhcnck|title=Densha De Go! Nintendo 64 Controller!|publisher=YouTube|accessdate=2018-06-17|date=2017-01-20}}</ref> No emulator supports it.<br />
<br />
===Pokémon Snap Station===<br />
There was a special kiosk designed to promote ''Pokémon Snap'' called the ''Pokémon Snap Station'', which is also compatible with the North American ''Pokémon Stadium'' with its gallery mode. It is just a Nintendo 64 with special hardware designed for the station.<ref name="Sixty Formula">{{cite web|url=https://www.youtube.com/watch?v=AMbjvGvPkV4|title=The Pokemon Snap Station|publisher=YouTube|accessdate=2018-06-17|date=2016-05-21}}</ref><ref name="MetalJesusRocks">{{cite web|url=https://www.youtube.com/watch?v=5_UGpRN6AnM&t=3m35s|title=VIDEO GAME KIOSKS - Extreme Game Collecting!|publisher=YouTube|accessdate=2018-06-17|date=2016-05-25}}</ref> Although the special cartridge boots in emulators compatible with the regular version, the printing functions are inaccessible due to no emulation of the printer for the player 4 slot, credit system, or the special board to switch between the regular and special cartridges.<br />
<br />
===Transfer Pak emulation===<br />
A few games use the Transfer Pak such as ''Mario Golf'', ''Mario Tennis'', ''Mario Artist: Paint Studio'', and the ''Pokémon Stadium'' games. Mostly, this can be done with NRage's input plugin, but a couple of things aren't emulated:<br />
<br />
*Taking pictures with the Japanese ''Game Boy Camera'' (called ''Pocket Camera'') while in Transfer Pak mode playing ''Mario Artist: Paint Studio'' displays static.<br />
<br />
===64DD emulation===<br />
The 64DD (an abbreviation for "64 Disk Drive") was a peripheral which allowed a proprietary disk format to be used with the N64. These disks had more space at a cheaper manufacturing cost. The peripheral was a commercial failure and was never released outside of Japan. Internal evidence suggests that, much like the GBA e-Reader, it wasn't even intended for a European release.<br />
<br />
Expansion disks are region-coded to either Japan or the US (obviously unused) and won't work with N64 games from the wrong region. Only F-Zero X has full support for this feature, but dummied-out expansion data in Ocarina of Time and Mario Party 2 (JP/PAL) exist as well.<br />
<br />
The special AV-In cartridge (NUS-028) that ''Mario Artist: Talent Studio'' can use doesn't work because it requires an RCA cable signal.<br />
<br />
Recently, there has been an effort to emulate the 64DD, and now [[Project64]] and [[MAME]] can run several commercial 64DD games as part of its N64 emulator. This is being ported to [[CEN64]] with the help of [https://twitter.com/LuigiBlood LuigiBlood]. The latest newcomer is Mupen64Plus which is the base of other emulators such as [[m64p]] and [[RMG]].<br />
<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Platform(s)<br />
! scope="col"|Latest Version<br />
! scope="col"|N64 Mouse<br />
! scope="col"|64DD Emulation<br />
! scope="col"|Active<br />
! scope="col"|[[Recommended emulators|Recommended]]<br />
|-<br />
! colspan="7"|PC / x86<br />
|-<br />
|[https://emulation.gametechwiki.com/index.php/RetroArch Mupen64Plus-Next (mupen64plus_next_libretro)]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/windows/x86_64/latest/ nightly]<br />
|{{✓}}<br />
|Mid/High<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Project64]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://github.com/project64/project64 {{Project64Ver}}]<br >[https://64dd.org/downloads.html 64DD.org Builds]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[https://emulation.gametechwiki.com/index.php/RetroArch ParaLLEl-N64 (parallel_n64_libretro)]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/windows/x86_64/latest/ nightly]<br />
|{{✓}}<br />
|Mid/High<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[CEN64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/tj90241/cen64 git]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[MAME]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[http://www.mamedev.org/release.html {{MAMEVer}}]<br />
|{{✗}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[m64p]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/m64p/m64p/releases {{M64pVer}}]<br >[https://github.com/m64p/m64p/actions git]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|{{✗}} (WIP)<br />
|-<br />
|[[RMG]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/Rosalie241/RMG/releases {{RMGVer}}]<br >[https://github.com/Rosalie241/RMG/actions Dev]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|{{✗}} (WIP)<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://github.com/mupen64plus/mupen64plus-core/releases git]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|{{✗}} (WIP)<br />
|}<br />
<br />
* Project64's latest versions emulate the N64 mouse and can load Zoinkity's hacked 64DD cartridge conversions at playable speeds. You'll need to set every game to have 8MB of Memory by default manually. Games do not save, some need "32-bit engine" to be unchecked (like Talent Studio), and some (like Polygon Studio to fix models and Paint Studio to fix stamps) need the Angrylion GFX plugin rather than GlideN64, which does the job for the rest.<br />
**The 64DD hardware started to be emulated around 2.3's release with the help of [https://github.com/LuigiBlood LuigiBlood]. Saving works but in the form of NDR files. NDR files are copied versions of NDD images with save data included as to not write to the clean unaltered images. In order to play 64DD games in their original forms, 8MB of memory is still needed because the real hardware needed the Expansion Pak upgrade. The IPL is also needed.<br />
<br />
* MAME includes early basic 64DD emulation as well but is much slower. Disk images need to be in head/track format. See [https://github.com/Happy-yappH/ddconvert.git here] for more information. It does not currently support disk swapping or saving disk to files. Writes only update the copy in memory, and, once the MAME process ends, the changes are lost. Current usage: <code>mame n64dd -quickload disk -cart cart -nodrc</code> (both disk and cart are optional)<br />
<br />
* CEN64, like Project64, had 64DD emulation ported to it from MAME. However, it focuses on accuracy and plays much slower than other emulators, aside from the 64DD emulation itself is imperfect.<br />
<br />
==Hardware variants==<br />
===iQue Player emulation===<br />
Before the GBA, DS, and 3DS, Nintendo released a modified version of their Nintendo 64 system for the Chinese market, which was called the iQue Player, through their not-quite-subsidiary iQue. Fourteen games were translated into Simplified Chinese, including Sin and Punishment, Ocarina of Time (the Majora's Mask port was canceled), Super Mario 64, and others.<br />
<br />
Unlike the Chinese releases of their more recent systems and their games, iQue Player releases are regular N64 roms wrapped with several layers of encryption, as well as a ticket and signature system like that on Wii, DSi, 3DS, Wii U, and Switch. The Chinese ROM-hacking scene is very active though and has translated the Japanese regular N64 releases for many of these to their language already, which explains some of the Chinese ROMs floating for those. However, recently, almost all pieces of iQue Player software were decrypted to regular .z64 ROM format.<br />
<br />
Several of the Chinese game localizations already run on N64 emulators, but as some hardware features of the iQue Player are not yet supported, some games, as well as the system menu and features in games such as saving, do not work yet.<br />
<br />
===Aleck 64 arcade emulation===<br />
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). 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.<br />
<br />
The Aleck 64 ROMs were dumped, and Zoinkity is working on converting them to regular N64 ROMs (with controls remapped to N64 controller buttons). They generally require an 8MB Expansion Pak to run at all and 4K EEPROM to save settings and scores. The ones covered by these patches are:<br />
<br />
* Donchan Puzzle Hanabi de Doon!<br />
* Eleven Beat: World Tournament<br />
* Hi Pai Paradise<br />
* Hi Pai Paradise 2<br />
* Kuru Kuru Fever<br />
* Magical Tetris Challenge<br />
* Mayjinsen 3 / Meijin-Sen<br />
* Star Soldier: Vanishing Earth (also ported to N64)<br />
* Super Real Mahjong VS<br />
* Tower & Shaft<br />
* Vivid Dolls (official eroge game on a Nintendo console)<br />
<br />
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.<br />
<br />
The remaining ones from the system's library not yet covered are:<br />
* Rev Limit<br />
* Variant Schwanzer<br />
<br />
==Virtual Console games in Dolphin==<br />
A number of N64 games were released for the Wii's Virtual Console service throughout its lifespan. While the emulators at the heart of each Virtual Console title were of average accuracy (rather than using one generic emulator used for every game, each title had an emulator specifically tailored to that game), they were good enough to render the games in full playable capacity with few to no glaring errors. Many of these titles are emulated well through Dolphin, and for a good while, due to persistent long-standing inaccuracies in N64 emulators and plugins, this was the best way to emulate certain N64 games, particularly Pokemon Snap and Mario Tennis. The system requirements are much higher than running them on regular N64 emulators, but it's doable for many games. Today, regular N64 emulators and plugins have advanced to the degree that this has become unnecessary, relegating this method of N64 game emulation to little more than a curiosity, at least on PC.<br />
<br />
The following games are on the N64 Virtual Console for Wii:<br />
<br />
{|width="100%"<br />
|- valign="top"<br />
|<br />
* 1080 Snowboarding<br />
* Bomberman Hero<br />
* Cruis'n USA<br />
* Custom Robo V2 (Japan only)<br />
* F-Zero X<br />
* Kirby 64: The Crystal Stars<br />
* The Legend of Zelda: Majora's Mask<br />
* The Legend of Zelda: Ocarina of Time<br />
|<br />
* Mario Golf<br />
* Mario Kart 64<br />
* Mario Party 2<br />
* Mario Tennis<br />
* Ogre Battle 64: Person of Lordly Caliber<br />
* Paper Mario<br />
* Pokemon Puzzle League<br />
|<br />
* Pokemon Snap<br />
* Sin & Punishment (English)<br />
* Star Fox 64<br />
* Super Mario 64<br />
* Super Smash Bros.<br />
* Wave Race 64<br />
* Yoshi's Story<br />
|}<br />
<br />
==Notes==<br />
<references group=N /><br />
<br />
==References==<br />
<references/><br />
<br />
{{Nintendo}}<br />
<br />
[[Category:Consoles]]<br />
[[Category:Home consoles]]<br />
[[Category:Fifth-generation video game consoles]]<br />
[[Category:Nintendo consoles]]<br />
[[Category:Nintendo 64 emulators|*]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Nintendo_64_emulators&diff=49019Nintendo 64 emulators2022-08-05T17:23:47Z<p>GPDP1: More info on m64p's lack of a dynarec</p>
<hr />
<div>{{Infobox console<br />
|title = Nintendo 64<br />
|logo = Nintendo64Console.png<br />
|developer = [[:Nintendo]]<br />
|type = [[:Category:Home consoles|Home video game console]]<br />
|generation = [[:Category:Fifth-generation video game consoles|Fifth generation]]<br />
|release = 1996<br />
|discontinued = 2002<br />
|predecessor = [[Super Nintendo emulators|SNES]]<br />
|successor = [[GameCube emulators|GameCube]]<br />
|emulated = {{✓}}<br />
}}<br />
<br />
{{for|other emulators that run on N64 hardware|Emulators on N64}} <br />
<br />
<br />
The '''Nintendo 64''' is a 64-bit fifth-generation console released by Nintendo on September 29, 1996 for {{inflation|USD|199.99|1996}}.<br />
<br />
Nintendo was the second company approached by Silicon Graphics Inc. (SGI), who wanted to roll out their previously enterprise-only technology in the consumer space. They originally pitched their idea to Sega, but it's assumed that Nintendo's offer was more appealing. With the NEC VR4300 CPU clocked at 93.75 MHz, 4MB of RAM,<ref group=N>Though a separate add-on was later released called the "Expansion Pak" that added an additional 4MB of RAM, totaling 8MB.</ref> and an SGI RCP GPU, Nintendo had finalized much of the hardware at least a year before launch, preventing video games from needing drastic rewrites as a result of architectural changes. The development workstations were often Unix-based, something that would later help reverse engineers in some projects.<br />
<br />
==Emulators==<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Platform(s)<br />
! scope="col"|Latest version<br />
! scope="col"|Plugins<br />
! scope="col"|Controller Pak<br />
! scope="col"|Rumble Pak<br />
! scope="col"|Transfer Pak<br />
! scope="col"|64DD<br />
! scope="col"|Depth<br/>output<br />
! scope="col"|Texture<br/>enhancement<br />
! scope="col"|Netplay<br />
! scope="col"|[[libretro]]<br />
! scope="col"|<abbr title="Free/Libre and Open-Source Software">FLOSS</abbr><br />
! scope="col"|Active<br />
! scope="col"|[[Recommended emulators|Recommended]]<br />
|-<br />
!colspan="15"|PC / x86<br />
|-<br />
|[[m64p]] (ParaLLEl)<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/m64p/m64p/releases {{M64pVer}}]<br >[https://github.com/m64p/m64p/actions git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}³<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[https://emulation.gametechwiki.com/index.php/RetroArch Mupen64Plus-Next (mupen64plus_next_libretro)]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/windows/x86_64/latest/ nightly]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}¹<br />
|{{✓}}<br />
|{{✓}}*<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[RMG]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/Rosalie241/RMG/releases {{RMGVer}}]<br >[https://github.com/Rosalie241/RMG/actions Dev]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}⁵<br />
|{{✓}}⁵<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Project64]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://www.pj64-emu.com/public-releases {{Project64Ver}}]<br >[https://www.pj64-emu.com/nightly-builds Dev]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[ares]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/ares-emulator/ares/releases {{aresVer}}]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|{{~}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://github.com/mupen64plus/mupen64plus-core/releases git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}⁵<br />
|{{✓}}⁵<br />
|{{~}}²<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[https://emulation.gametechwiki.com/index.php/RetroArch ParaLLEl-N64 (parallel_n64_libretro)]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/windows/x86_64/latest/ nightly]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{✓}}*<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}⁶<br />
|-<br />
|[[1964]]<br />
|align=left|{{Icon|Windows}}<br />
|[http://www.emulation64.com/files/getfile/936/ 1.1] (Official)<br />[http://files.emulation64.fr/Emulateurs/EMU_1964_146.zip 1.2 r146] (Unofficial SVN)<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}⁴<br />
|-<br />
|m64p (Final GLideN64)<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/thekovic/m64p/releases/tag/v2021.5.30 Final GLideN64]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}⁷<br />
|-<br />
|[[BizHawk]]<br />
|align=left|{{Icon|Windows}}<br />
|[http://tasvideos.org/BizHawk/ReleaseHistory.html {{BizHawkVer}}]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[CEN64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/tj90241/cen64 git]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[Project64 Netplay]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://github.com/Project64Netplay/Project64-Netplay-2x git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[DaedalusX64]]<br />
|align=left|{{Icon|Linux}}<br />
|[https://github.com/DaedalusX64/daedalus/releases/latest git]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[Sixtyforce]]<br />
|align=left|{{Icon|macOS}}<br />
|[http://sixtyforce.com/download/ {{SixtyforceVer}}]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Larper64<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://drive.google.com/file/d/1IWyw5UG9Uf24KG0zrcXSFoOmcQoHWmyc/view {{Larper64Ver}}]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|[[UltraHLE]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://web.archive.org/web/20070312015944/http://www.emuunlim.com/UltraHLE/ultrahle.zip 1.0]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|[[MAME]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[http://www.mamedev.org/release.html {{MAMEVer}}]<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[Ryu64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/Ryu64Emulator/Ryu64 git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|R64Emu<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/rasky/r64emu git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
!colspan="15"|Mobile / ARM<br />
|-<br />
|[[Mupen64Plus]] FZ<br />
|align=left|{{Icon|Android}}<br />
|[https://play.google.com/store/apps/details?id=org.mupen64plusae.v3.fzurita 3.0.322 (beta)]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}¹<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Pandora|Pyra}}<br />
|[http://repo.openpandora.org/?page=detail&app=mupen64plus Pandora]<br/>[https://pyra-handheld.com/repo/apps/39 Pyra]<br />
|?<br />
|{{✓}}<br />
|?<br />
|?<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
!colspan="15"|Consoles<br />
|-<br />
|[[Virtual Console]]<br />
|align=left|{{Icon|Wii|WiiU}}<br />
|N/A<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Not64<br />
|align=left|{{Icon|GCN|Wii}}<br />
|[https://github.com/Extrems/Not64/releases/latest git]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|[[DaedalusX64]]<br />
|align=left|{{Icon|PSP|3DS}}<br>{{Icon|Vita|PS2}}<br />
|[https://github.com/DaedalusX64/daedalus/releases/latest PSP]<br/>[https://github.com/masterfeizz/DaedalusX64-3DS/releases 3DS]<br/>[https://github.com/Rinnegatamante/DaedalusX64-vitaGL/releases VitaGL]<br/>[https://www.ps2-home.com/forum/viewtopic.php?f=99&p=39957#p39957 PS2]<br />
|?<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}} <small>(PSP)</small><br />
|{{~}}<br />
|-<br />
|Surreal64 CE<br />
|align=left|{{Icon|Xbox}}<br />
|[https://digiex.net/threads/surreal64-ce-b6-0-download-n64-emulator-for-xbox.13677 Beta 6.0]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|mupen64-360<br />
|align=left|{{Icon|Xbox360}}<br />
|[https://digiex.net/threads/mupen64-360-xbox-360-nintendo-64-n64-emulator-download.9352 0.96 beta]<br />
|?<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|[https://code.google.com/p/mupen64gc/ Wii64]<br />
|align=left|{{Icon|GCN|Wii}}<br />
|[https://code.google.com/archive/p/mupen64gc/downloads 1.1 beta]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|}<br />
<br />
*<nowiki>* Available exclusively as a libretro core</nowiki><br />
*<nowiki>¹ Only supports texture packs, and not filtering or upscaling</nowiki><br />
*<nowiki>² Requires replacing the input plugin to one with netplay support</nowiki><br />
*<nowiki>³ If not using Netplay, use RMG</nowiki><br />
*<nowiki>⁴ Highly recommended to use 1964 GEPD for Goldeneye 007 or Perfect Dark</nowiki><br />
*<nowiki>⁵ Only with GLideN64</nowiki><br />
*<nowiki>⁶ Obsolete and replaced by Mupen64Plus-Next</nowiki><br />
*<nowiki>⁷ RMG with GLideN64 recommended.</nowiki><br />
<br />
===Comparisons===<br />
Although many Nintendo 64 emulators have been made and many games can be run between them, until recently complete compatibility and/or accuracy left a bit to be desired. For half a decade, Mupen64Plus and Project64 have vied for the most playable emulator, and which was more compatible often depended on when and in what configuration each emulator has been tested. As of August 2017, both emulators have roughly equal compatibility and accuracy when running with the same [[recommended N64 plugins]] setup, though both default to Glide64, a now relatively lackluster plugin.<br />
<br />
;[[Mupen64Plus]]<br />
:A multi-platform emulator based on Hacktarux's Mupen64. It's about as accurate as Project64,<ref>loganmc10. [https://github.com/mupen64plus/mupen64plus-core/pull/336 ''Ignore TLB write if TLB entry is unmapping itself'']. "By the way, once this, along with the other PR's I have waiting are merged, we are at "compatibility parity" with Project64 as far as I can tell. I don't know of any game that doesn't boot with mupen64plus that works in PJ64."</ref> when both emulators are run with GLideN64. However, Mupen64Plus lacks a native GUI, instead being launched either from the command line or by dragging and dropping ROMs onto the executable and editing the config with a text editor. [[BizHawk]] and [[OpenEmu]] use forks of Mupen64Plus and its plugins for their N64 emulation, but they seem to be shallow. As of 2022 Project64-style overclocking for faster frame rates has been added under the option 'CountPerOpDenomPot'.<br />
<br />
:;Mupen64Plus-Next and ParaLLEl-N64<br />
:Both are heavily-modified forks developed as [[libretro]] cores. They introduce many features and optimizations not present in mainline alongside [[RetroArch]]'s general features, including 3-point texture filtering for Glide64, superior A/V sync and latency, and even an initially exclusive LLE Vulkan renderer based on Angrylion's pixel-perfect RDP plugin now known as ParaLLEl-RDP, making it a better alternative to the standalone version in some cases. 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.<br />
<br />
::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.<br />
<br />
:;[[m64p]]<br />
:A fork of Mupen64Plus with a custom-made Qt GUI. This is probably the easiest "just works out of the box" solution for Nintendo 64 emulation, as it comes bundled with ParaLLEl-RDP and ParaLLEl-RSP, ensuring both excellent compatibility and good speed without needing to mess with plugins or settings, provided your hardware supports Vulkan. However, unlike other emulators, it does not allow you to use other plugins. While it began as a shallow fork, it has increasingly become something closer to a hard fork, as its developer has opted to make various accuracy-focused changes to the emulation core that will require additional work to port back to upstream or to other forks. It also currently features only an interpreter core, as the dynarecs used by Mupen64Plus are incompatible with the core timing changes made by the developer. While this makes m64p more accurate than most other N64 emulators, it also results in slower performance. If more speed and enhancements are desired, there is an older build that is closer to upstream and uses GLideN64 as its graphics plugin - unfortunately lacking the texture enhancement suite required for use of texture packs and upscaling.<br />
<br />
:;[[RMG]]<br />
:Rosalie's Mupen GUI is a project aiming to close the gap between Project64 and Mupen64Plus in terms of user experience. Its interface is about on par with m64p's in terms of cleanliness and ease of use, but unlike m64p, it allows you to use other plugins. The latest version comes bundled with GLideN64 and ParaLLEl-RDP for video plugins, and mupen64plus-hle-rsp and ParaLLEl-RSP for RSP plugins. However, for some reason it currently does not allow you access to ParaLLEl-RDP's options within its GUI, so if you wish to make use of features such as upscaling or downsampling, you must do so by editing the mupen64plus.cfg file, whereas m64p does expose these options in its GUI. However, if you prefer GLideN64, this is a superior alternative, as it does have access to its settings GUI, and the last version of m64p that uses GLideN64 is becoming increasingly outdated.<br />
<br />
:;Wii64 and Not64<br />
:Both are based on Mupen64, with Not64 being a fork of Wii64. Not64 claims to be better optimized 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 releases whenever possible.<br />
<br />
;[[Project64]]<br />
: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 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.<br />
<br />
;[[Ares]]<br />
:An open-source multi-system emulator and successor to Near's [[higan]] project, with a mostly original N64 core. Unlike other N64 emulators, it aims for high accuracy and does not employ HLE RSP or RDP emulation of any kind, not does it use game-specific hacks. It uses Themaister's ParaLLEl-RDP Vulkan renderer (with the MAME renderer as a software-based fallback) for pixel-perfect LLE graphics. While it is currently less compatible than Mupen64Plus or Project64, it is quickly catching up to them [https://ares-emu.net/compatibility/15 (only a handful of games are currently listed as partially or not working)], and it currently passes several stringent [https://github.com/ares-emulator/ares/pull/613 accuracy tests] the other emulators do not. However, it remains to be seen how accurate its developers are willing to make it without compromising speed and playability on current machines.<br />
<br />
;[[CEN64]]<br />
:Aims for cycle accuracy while at the same time aiming to eventually be usable on modern PC hardware. It lacks many features and has spotty compatibility, but it can already emulate some well-known edge cases such as picture recognition in Pokemon Snap. Unfortunately, its creator appears to have abandoned the project [https://github.com/n64dev/cen64/releases/tag/v0.3 citing lack of satisfaction with the program's performance in its current interpreter-based incarnation], and while the baton has been collectively passed to the n64dev community for further development, progress has been slow.<br />
<br />
;[[1964]]<br />
:Along with its various versions and forks, it was once a decent, speedy open-source alternative to Project64 and Mupen64, though it usually lagged behind the two compatibility-wise. Nowadays it has completely fallen off the radar as development has halted, and there is no longer a central code repo to speak of. There is little reason to use it nowadays outside of historical purposes, very specific edge cases, or if your device is too slow to run Mupen64Plus or Project64.<br />
<br />
;Daedalus<br />
:Is a Nintendo 64 emulator for PC which was ported to the PSP under the name of DaedalusX64. The PSP version later became the main version and got ported to platforms such as the Dreamcast, the PS2, the PS Vita, and the 3DS. On PSP, several games are able to reach full speed and most of them work with few emulation issues.<br />
<br />
;[[Sixtyforce]]<br />
:Is macOS-only, closed-source, and asks you to pay for full access to its features. It was once one of the only choices for Mac users, particularly those with older Macs since it's the only emulator with a <abbr title="Power PC">PPC</abbr> [[Dynamic recompilation|dynarec]]), but, with the switch to x86 and Mupen64Plus being ported to macOS, it has now become less relevant. However, development is still ongoing and is currently in its [https://sixtyforce.com/rosetta/ third rewrite] to support the upcoming [https://en.wikipedia.org/wiki/Apple-designed_processors Apple Silicon].<br />
<br />
;[[UltraHLE]]<br />
: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.<br />
<br />
;[[Ryu64]]<br />
:Is a Nintendo 64 emulator made in C#. The 'Ryu' word is named after the "RyuJIT" used in both Visual Basic & C#. But it might have been inspired by the lead author's sole (so far) [https://github.com/Ryujinx/Ryujinx/commits?author=Dudejoe870 commit] at Switch emulator, [[Ryujinx]]'s Git repository, and his depreciated [https://github.com/Dudejoe870/RyujinxAutoUpdate Ryujinx Auto Updater] tool. "86RYU", an x86 JIT compiler, is being developed alongside this emulator too.<br />
<br />
;n64oid<br />
:An Android exclusive Nintendo 64 emulator. It is similar to Project 64 1.6 in terms of compatibility, although it is unknown who authored it, as the APK for n64oid circulates on many legally questionable APK sites. n64oid has the infamous problem in Mario Kart 64 of the screen in Wario Stadium not displaying properly, as it displays nothing but black. It upscales all games to widescreen, which works well most of time, but on many phones it will have performance issues. The emulator is relatively poor, but it is much easier to set up than other options. The emulator features a menu with many similarities to the mobile edition of Snes9x EX+, and the My Boy! family of Android emulators for Game Boy systems.<br />
<br />
==Emulation issues==<br />
{{Main|Recommended N64 plugins}}<br />
<br />
Nintendo 64 emulation is now decent. A lot of the major problems that N64 emulation had in the past, have been fixed for quite some time now. The only catch is that the accurate emulators have higher system requirements. The main remaining problem is the lack of accurate cycle counting.<br />
<br />
===[[High/Low level emulation|High-level vs. low-level]] graphics===<br />
<br />
One of the biggest hurdles to emulating the Nintendo 64 was the Reality Display Processor (RDP), which used a custom design that had to be fine-tuned to get more performance out of the system using microcode. To emulate the RDP accurately, one would have to execute said microcode the way the RDP did, which differed from PC graphics cards of the day. To complicate matters further, API standards that were available on PCs two decades ago were nowhere near as flexible as they are today. If you wanted to make an accurate GPU-accelerated RDP plugin in 2003, you simply couldn't with the APIs of the time (OpenGL 1.x and Direct3D 9). For the average user, hardware-accurate GPU acceleration would be out of reach for a long time.<br />
<br />
[[UltraHLE]] offered a compromise. In contrast to earlier consoles, whose video chips in hindsight had been easy to render to the host CPU's framebuffer, performant RDP emulation had to take shortcuts, including programming around specific games' microcode to cleanly translate their graphics commands into API calls using Direct3D, OpenGL, and even Glide. With this, the theoretical system requirements plummeted, 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 is an improvement is subjective and a common point of discussion. Unfortunately it proved to be hit and miss, owing to the nature of per-game microcode detection and having to tweak settings to prevent some games from running into graphical glitches.<br />
<br />
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).<br />
<br />
On the high-level side, gonetz and one or two assistants spent a large portion of development improving GlideN64's microcode handling 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 framebuffer is used as well as performance issues), VI emulation, and how combine/blending modes are emulated (such as noise issues and combiner accuracy).<br />
<br />
<gallery widths="300" mode="packed"><br />
Majora's mask accurate.png| Low-level emulation of Majora's Mask using SoftGraphic<br />
Project64 2013-07-26 14-20-17-55.png| High-level emulation of Majora's Mask using Jabo's Direct3D<br />
</gallery><br />
<br />
===[[Texture filtering]]===<br />
The Nintendo 64 was the first consumer device to be able to filter textures when rendering 3D objects. However, unlike every console and PC graphics card made after the N64, its implementation of bilinear was primitive in that, in order to reduce strain on the system, it only used three samples as opposed to four, resulting in slightly jagged, asymmetrically-filtered textures. Instead of faithfully applying this "imperfect" version of bilinear filtering, HLE plugins instead applied conventional bilinear filtering, interpolating straight from the source texture up to the output resolution the same way a PC game would. While that method is technically superior, it can result in textures that look even blurrier than on real hardware.<br />
<br />
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 pre-rendered backgrounds or menu screens, may look as though they are separated into squares (see images below; note how OoT's Quest Status screen appears to be divided into a grid). 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 oftentimes low resolutions.<br />
<br />
Modern emulators and plugins have taken some steps which help remedy these problems. For instance, GLideN64 now supports N64-style three-point texture filtering, which results in a more faithful look. It is also capable of rendering at 320x240, which sidesteps the issues with filtered text, UI elements, and menu screens, while still retaining texture filtering. Pixel-accurate plugins such as Angrylion and ParaLLEl-RDP do not have these problems at all.<br />
<gallery widths="300" mode="packed"><br />
Project64_2013-06-26_17-44-58-31.png|Conker's Bad Fur Day copyright screen, displaying issues with filtered text.<br />
Mupen64plus_2013-08-18_20-35-50-08.png|Ocarina of Time's menu subscreen, displaying issues with filtering.</gallery><br />
<br />
===Timing issues===<br />
One of the biggest remaining problems in N64 emulation is lack of accurate core timings, which in practice means games do not always run at the speed they would on real hardware. While this technically affects all games, the majority are only affected to a negligible degree, and in some instances (particularly in Rare games) this can actually result in less framerate drops and lag, which can be seen as beneficial. However, some game engines actually depend on accurate timings for proper game behavior, and not properly emulating them can result in considerable to major issues. Some notable examples include the following:<br />
* Intros and cutscenes playing too fast and not properly syncing up with musical cues. Seen in Goldeneye's intro and Body Harvest's beginning cutscene.<br />
* Gameplay demos running at hyper speed. Earthworm Jim 3D is most notorious for this, though the main game itself is largely unaffected.<br />
* Game physics not working properly due to being tied to framerate. A good example is Donkey Kong 64, which is programmed to boost the character's speed and momentum proportional to in-game lag (most likely to make up for the game's frequent framerate drops), which can be exploited for certain glitches and sequence breaks on real hardware. Emulators currently run the game too well and with too little lag, making most of these tricks impossible to pull off.<br />
* Possibly the most affected game is Knife's Edge, which runs like it's on permanent fast-forward, making it all but unplayable. Messing with timing-related settings such as CounterFactor can mitigate this somewhat, but nowhere near enough to fix the issue.<br />
Fortunately, tackling these problems has recently become a core focus of development in some N64 emulators, and attempts are underway to improve the situation. Ares currently has the most accurate timings overall, and already runs Earthworm Jim 3D's demos much better than other emulators. Meanwhile, m64p has recently pushed various timing-related commits aimed at improving accuracy, and as a result it may now be the only emulator that runs Donkey Kong 64 properly. As these efforts progress, it should be noted that a side-effect of improved timings may be greater in-game lag. This should not be seen as the emulator becoming slower, but rather the emulator behaving exactly like real hardware does, as many N64 games were notorious for framerate drops.<br />
<br />
==Peripherals==<br />
===Voice Recognition Unit emulation===<br />
The Voice Recognition Unit (VRU) is an accessory used primarily by ''Hey You, Pikachu''. No emulator or input plugin supports this, although there is an on-going effort to get it working.<ref name="emutalk">{{cite web|url=http://www.emutalk.net/threads/55279|title=Hey You! Pikachu - Possible HLE Implementation|publisher=emutalk|accessdate=2018-06-17|date=2014-10-27, Last edit: 2016-04-04}}</ref><br />
===''Densha De Go!'' Controller===<br />
Also available for the [[PlayStation emulators|PlayStation]], ''Densha De Go! 64'' is a Japan-only train simulator released by [[Wikipedia:Taito|Taito]] that is compatible with an optional special controller that plugs into the player 3 port.<ref name="ArcadeUSA">{{cite web|url=https://www.youtube.com/watch?v=cCcPAGhcnck|title=Densha De Go! Nintendo 64 Controller!|publisher=YouTube|accessdate=2018-06-17|date=2017-01-20}}</ref> No emulator supports it.<br />
<br />
===Pokémon Snap Station===<br />
There was a special kiosk designed to promote ''Pokémon Snap'' called the ''Pokémon Snap Station'', which is also compatible with the North American ''Pokémon Stadium'' with its gallery mode. It is just a Nintendo 64 with special hardware designed for the station.<ref name="Sixty Formula">{{cite web|url=https://www.youtube.com/watch?v=AMbjvGvPkV4|title=The Pokemon Snap Station|publisher=YouTube|accessdate=2018-06-17|date=2016-05-21}}</ref><ref name="MetalJesusRocks">{{cite web|url=https://www.youtube.com/watch?v=5_UGpRN6AnM&t=3m35s|title=VIDEO GAME KIOSKS - Extreme Game Collecting!|publisher=YouTube|accessdate=2018-06-17|date=2016-05-25}}</ref> Although the special cartridge boots in emulators compatible with the regular version, the printing functions are inaccessible due to no emulation of the printer for the player 4 slot, credit system, or the special board to switch between the regular and special cartridges.<br />
<br />
===Transfer Pak emulation===<br />
A few games use the Transfer Pak such as ''Mario Golf'', ''Mario Tennis'', ''Mario Artist: Paint Studio'', and the ''Pokémon Stadium'' games. Mostly, this can be done with NRage's input plugin, but a couple of things aren't emulated:<br />
<br />
*Taking pictures with the Japanese ''Game Boy Camera'' (called ''Pocket Camera'') while in Transfer Pak mode playing ''Mario Artist: Paint Studio'' displays static.<br />
<br />
===64DD emulation===<br />
The 64DD (an abbreviation for "64 Disk Drive") was a peripheral which allowed a proprietary disk format to be used with the N64. These disks had more space at a cheaper manufacturing cost. The peripheral was a commercial failure and was never released outside of Japan. Internal evidence suggests that, much like the GBA e-Reader, it wasn't even intended for a European release.<br />
<br />
Expansion disks are region-coded to either Japan or the US (obviously unused) and won't work with N64 games from the wrong region. Only F-Zero X has full support for this feature, but dummied-out expansion data in Ocarina of Time and Mario Party 2 (JP/PAL) exist as well.<br />
<br />
The special AV-In cartridge (NUS-028) that ''Mario Artist: Talent Studio'' can use doesn't work because it requires an RCA cable signal.<br />
<br />
Recently, there has been an effort to emulate the 64DD, and now [[Project64]] and [[MAME]] can run several commercial 64DD games as part of its N64 emulator. This is being ported to [[CEN64]] with the help of [https://twitter.com/LuigiBlood LuigiBlood]. The latest newcomer is Mupen64Plus which is the base of other emulators such as [[m64p]] and [[RMG]].<br />
<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Platform(s)<br />
! scope="col"|Latest Version<br />
! scope="col"|N64 Mouse<br />
! scope="col"|64DD Emulation<br />
! scope="col"|Active<br />
! scope="col"|[[Recommended emulators|Recommended]]<br />
|-<br />
! colspan="7"|PC / x86<br />
|-<br />
|[https://emulation.gametechwiki.com/index.php/RetroArch Mupen64Plus-Next (mupen64plus_next_libretro)]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/windows/x86_64/latest/ nightly]<br />
|{{✓}}<br />
|Mid/High<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Project64]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://github.com/project64/project64 {{Project64Ver}}]<br >[https://64dd.org/downloads.html 64DD.org Builds]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[https://emulation.gametechwiki.com/index.php/RetroArch ParaLLEl-N64 (parallel_n64_libretro)]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://buildbot.libretro.com/nightly/windows/x86_64/latest/ nightly]<br />
|{{✓}}<br />
|Mid/High<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[CEN64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/tj90241/cen64 git]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[MAME]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[http://www.mamedev.org/release.html {{MAMEVer}}]<br />
|{{✗}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[m64p]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/m64p/m64p/releases {{M64pVer}}]<br >[https://github.com/m64p/m64p/actions git]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|{{✗}} (WIP)<br />
|-<br />
|[[RMG]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/Rosalie241/RMG/releases {{RMGVer}}]<br >[https://github.com/Rosalie241/RMG/actions Dev]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|{{✗}} (WIP)<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://github.com/mupen64plus/mupen64plus-core/releases git]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|{{✗}} (WIP)<br />
|}<br />
<br />
* Project64's latest versions emulate the N64 mouse and can load Zoinkity's hacked 64DD cartridge conversions at playable speeds. You'll need to set every game to have 8MB of Memory by default manually. Games do not save, some need "32-bit engine" to be unchecked (like Talent Studio), and some (like Polygon Studio to fix models and Paint Studio to fix stamps) need the Angrylion GFX plugin rather than GlideN64, which does the job for the rest.<br />
**The 64DD hardware started to be emulated around 2.3's release with the help of [https://github.com/LuigiBlood LuigiBlood]. Saving works but in the form of NDR files. NDR files are copied versions of NDD images with save data included as to not write to the clean unaltered images. In order to play 64DD games in their original forms, 8MB of memory is still needed because the real hardware needed the Expansion Pak upgrade. The IPL is also needed.<br />
<br />
* MAME includes early basic 64DD emulation as well but is much slower. Disk images need to be in head/track format. See [https://github.com/Happy-yappH/ddconvert.git here] for more information. It does not currently support disk swapping or saving disk to files. Writes only update the copy in memory, and, once the MAME process ends, the changes are lost. Current usage: <code>mame n64dd -quickload disk -cart cart -nodrc</code> (both disk and cart are optional)<br />
<br />
* CEN64, like Project64, had 64DD emulation ported to it from MAME. However, it focuses on accuracy and plays much slower than other emulators, aside from the 64DD emulation itself is imperfect.<br />
<br />
==Hardware variants==<br />
===iQue Player emulation===<br />
Before the GBA, DS, and 3DS, Nintendo released a modified version of their Nintendo 64 system for the Chinese market, which was called the iQue Player, through their not-quite-subsidiary iQue. Fourteen games were translated into Simplified Chinese, including Sin and Punishment, Ocarina of Time (the Majora's Mask port was canceled), Super Mario 64, and others.<br />
<br />
Unlike the Chinese releases of their more recent systems and their games, iQue Player releases are regular N64 roms wrapped with several layers of encryption, as well as a ticket and signature system like that on Wii, DSi, 3DS, Wii U, and Switch. The Chinese ROM-hacking scene is very active though and has translated the Japanese regular N64 releases for many of these to their language already, which explains some of the Chinese ROMs floating for those. However, recently, almost all pieces of iQue Player software were decrypted to regular .z64 ROM format.<br />
<br />
Several of the Chinese game localizations already run on N64 emulators, but as some hardware features of the iQue Player are not yet supported, some games, as well as the system menu and features in games such as saving, do not work yet.<br />
<br />
===Aleck 64 arcade emulation===<br />
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). 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.<br />
<br />
The Aleck 64 ROMs were dumped, and Zoinkity is working on converting them to regular N64 ROMs (with controls remapped to N64 controller buttons). They generally require an 8MB Expansion Pak to run at all and 4K EEPROM to save settings and scores. The ones covered by these patches are:<br />
<br />
* Donchan Puzzle Hanabi de Doon!<br />
* Eleven Beat: World Tournament<br />
* Hi Pai Paradise<br />
* Hi Pai Paradise 2<br />
* Kuru Kuru Fever<br />
* Magical Tetris Challenge<br />
* Mayjinsen 3 / Meijin-Sen<br />
* Star Soldier: Vanishing Earth (also ported to N64)<br />
* Super Real Mahjong VS<br />
* Tower & Shaft<br />
* Vivid Dolls (official eroge game on a Nintendo console)<br />
<br />
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.<br />
<br />
The remaining ones from the system's library not yet covered are:<br />
* Rev Limit<br />
* Variant Schwanzer<br />
<br />
==Virtual Console games in Dolphin==<br />
A number of N64 games were released for the Wii's Virtual Console service throughout its lifespan. While the emulators at the heart of each Virtual Console title were of average accuracy (rather than using one generic emulator used for every game, each title had an emulator specifically tailored to that game), they were good enough to render the games in full playable capacity with few to no glaring errors. Many of these titles are emulated well through Dolphin, and for a good while, due to persistent long-standing inaccuracies in N64 emulators and plugins, this was the best way to emulate certain N64 games, particularly Pokemon Snap and Mario Tennis. The system requirements are much higher than running them on regular N64 emulators, but it's doable for many games. Today, regular N64 emulators and plugins have advanced to the degree that this has become unnecessary, relegating this method of N64 game emulation to little more than a curiosity, at least on PC.<br />
<br />
The following games are on the N64 Virtual Console for Wii:<br />
<br />
{|width="100%"<br />
|- valign="top"<br />
|<br />
* 1080 Snowboarding<br />
* Bomberman Hero<br />
* Cruis'n USA<br />
* Custom Robo V2 (Japan only)<br />
* F-Zero X<br />
* Kirby 64: The Crystal Stars<br />
* The Legend of Zelda: Majora's Mask<br />
* The Legend of Zelda: Ocarina of Time<br />
|<br />
* Mario Golf<br />
* Mario Kart 64<br />
* Mario Party 2<br />
* Mario Tennis<br />
* Ogre Battle 64: Person of Lordly Caliber<br />
* Paper Mario<br />
* Pokemon Puzzle League<br />
|<br />
* Pokemon Snap<br />
* Sin & Punishment (English)<br />
* Star Fox 64<br />
* Super Mario 64<br />
* Super Smash Bros.<br />
* Wave Race 64<br />
* Yoshi's Story<br />
|}<br />
<br />
==Notes==<br />
<references group=N /><br />
<br />
==References==<br />
<references/><br />
<br />
{{Nintendo}}<br />
<br />
[[Category:Consoles]]<br />
[[Category:Home consoles]]<br />
[[Category:Fifth-generation video game consoles]]<br />
[[Category:Nintendo consoles]]<br />
[[Category:Nintendo 64 emulators|*]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Nintendo_64_emulators&diff=48923Nintendo 64 emulators2022-08-01T05:35:52Z<p>GPDP1: Moved m64p (Final GLideN64) down to "somewhat recommended" and Cen64 down to "not recommended" - RMG is more up-to-date and overall better for GLideN64, and Cen64 is currently extremely barebones and unfit for general use</p>
<hr />
<div>{{Infobox console<br />
|title = Nintendo 64<br />
|logo = Nintendo64Console.png<br />
|developer = [[:Nintendo]]<br />
|type = [[:Category:Home consoles|Home video game console]]<br />
|generation = [[:Category:Fifth-generation video game consoles|Fifth generation]]<br />
|release = 1996<br />
|discontinued = 2002<br />
|predecessor = [[Super Nintendo emulators|SNES]]<br />
|successor = [[GameCube emulators|GameCube]]<br />
|emulated = {{✓}}<br />
}}<br />
<br />
{{for|other emulators that run on N64 hardware|Emulators on N64}} <br />
<br />
<br />
The '''Nintendo 64''' is a 64-bit fifth-generation console released by Nintendo on September 29, 1996 for {{inflation|USD|199.99|1996}}.<br />
<br />
Nintendo was the second company approached by Silicon Graphics Inc. (SGI), who wanted to roll out their previously enterprise-only technology in the consumer space. They originally pitched their idea to Sega, but it's assumed that Nintendo's offer was more appealing. With the NEC VR4300 CPU clocked at 93.75 MHz, 4MB of RAM,<ref group=N>Though a separate add-on was later released called the "Expansion Pak" that added an additional 4MB of RAM, totaling 8MB.</ref> and an SGI RCP GPU, Nintendo had finalized much of the hardware at least a year before launch, preventing video games from needing drastic rewrites as a result of architectural changes. The development workstations were often Unix-based, something that would later help reverse engineers in some projects.<br />
<br />
==Emulators==<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Platform(s)<br />
! scope="col"|Latest version<br />
! scope="col"|Plugins<br />
! scope="col"|Controller Pak<br />
! scope="col"|Rumble Pak<br />
! scope="col"|Transfer Pak<br />
! scope="col"|64DD<br />
! scope="col"|Depth<br/>output<br />
! scope="col"|Texture<br/>enhancement<br />
! scope="col"|Netplay<br />
! scope="col"|[[libretro]]<br />
! scope="col"|<abbr title="Free/Libre and Open-Source Software">FLOSS</abbr><br />
! scope="col"|Active<br />
! scope="col"|[[Recommended emulators|Recommended]]<br />
|-<br />
!colspan="15"|PC / x86<br />
|-<br />
|[[m64p]] (ParaLLEl)<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/loganmc10/m64p/releases/latest git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}³<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Mupen64Plus-Next<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://www.retroarch.com/ git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}¹<br />
|{{✓}}<br />
|{{✓}}*<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[RMG]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/Rosalie241/RMG/releases {{RMGVer}}]<br >[https://github.com/Rosalie241/RMG/actions Dev]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Project64]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://www.pj64-emu.com/public-releases {{Project64Ver}}]<br >[https://www.pj64-emu.com/nightly-builds Dev]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[BizHawk]]<br />
|align=left|{{Icon|Windows}}<br />
|[http://tasvideos.org/BizHawk/ReleaseHistory.html {{BizHawkVer}}]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|m64p (Final GLideN64)<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/loganmc10/m64p/releases/tag/v2021.5.30 Final GLideN64]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|[[ares]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/ares-emulator/ares/releases {{aresVer}}]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|{{~}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://github.com/mupen64plus/mupen64plus-core/releases git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|ParaLLEl-N64<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://www.retroarch.com/ 2.0-rc2]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{✓}}*<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[1964]]<br />
|align=left|{{Icon|Windows}}<br />
|[http://www.emulation64.com/files/getfile/936/ 1.1] (Official)<br />[http://files.emulation64.fr/Emulateurs/EMU_1964_146.zip 1.2 r146] (Unofficial SVN)<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}⁴<br />
|-<br />
|[[CEN64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/tj90241/cen64 git]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[Project64 Netplay]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://github.com/Project64Netplay/Project64-Netplay-2x git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[DaedalusX64]]<br />
|align=left|{{Icon|Linux}}<br />
|[https://github.com/DaedalusX64/daedalus/releases/latest git]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[Sixtyforce]]<br />
|align=left|{{Icon|macOS}}<br />
|[http://sixtyforce.com/download/ {{SixtyforceVer}}]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Larper64<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://drive.google.com/file/d/1IWyw5UG9Uf24KG0zrcXSFoOmcQoHWmyc/view {{Larper64Ver}}]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|[[UltraHLE]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://web.archive.org/web/20070312015944/http://www.emuunlim.com/UltraHLE/ultrahle.zip 1.0]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|[[MAME]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[http://www.mamedev.org/release.html {{MAMEVer}}]<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[Ryu64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/Ryu64Emulator/Ryu64 git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|R64Emu<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/rasky/r64emu git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
!colspan="15"|Mobile / ARM<br />
|-<br />
|[[Mupen64Plus]] FZ<br />
|align=left|{{Icon|Android}}<br />
|[https://play.google.com/store/apps/details?id=org.mupen64plusae.v3.fzurita 3.0.322 (beta)]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}¹<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Pandora|Pyra}}<br />
|[http://repo.openpandora.org/?page=detail&app=mupen64plus Pandora]<br/>[https://pyra-handheld.com/repo/apps/39 Pyra]<br />
|?<br />
|{{✓}}<br />
|?<br />
|?<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
!colspan="15"|Consoles<br />
|-<br />
|[[Virtual Console]]<br />
|align=left|{{Icon|Wii|WiiU}}<br />
|N/A<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Not64<br />
|align=left|{{Icon|GCN|Wii}}<br />
|[https://github.com/Extrems/Not64/releases/latest git]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|[[DaedalusX64]]<br />
|align=left|{{Icon|PSP|3DS}}<br>{{Icon|Vita|PS2}}<br />
|[https://github.com/DaedalusX64/daedalus/releases/latest PSP]<br/>[https://github.com/masterfeizz/DaedalusX64-3DS/releases 3DS]<br/>[https://github.com/Rinnegatamante/DaedalusX64-vitaGL/releases VitaGL]<br/>[https://www.ps2-home.com/forum/viewtopic.php?f=99&p=39957#p39957 PS2]<br />
|?<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}} <small>(PSP)</small><br />
|{{~}}<br />
|-<br />
|Surreal64 CE<br />
|align=left|{{Icon|Xbox}}<br />
|[https://digiex.net/threads/surreal64-ce-b6-0-download-n64-emulator-for-xbox.13677 Beta 6.0]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|mupen64-360<br />
|align=left|{{Icon|Xbox360}}<br />
|[https://digiex.net/threads/mupen64-360-xbox-360-nintendo-64-n64-emulator-download.9352 0.96 beta]<br />
|?<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|[https://code.google.com/p/mupen64gc/ Wii64]<br />
|align=left|{{Icon|GCN|Wii}}<br />
|[https://code.google.com/archive/p/mupen64gc/downloads 1.1 beta]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|}<br />
<br />
*<nowiki>* Available exclusively as a libretro core</nowiki><br />
*<nowiki>¹ Only supports texture packs, and not filtering or upscaling</nowiki><br />
*<nowiki>² Requires replacing the input plugin to one with netplay support</nowiki><br />
*<nowiki>³ If not using Netplay, use RMG</nowiki><br />
*<nowiki>⁴ Highly recommended to use 1964 GEPD for Goldeneye 007 or Perfect Dark</nowiki><br />
<br />
===Comparisons===<br />
Although many Nintendo 64 emulators have been made and many games can be run between them, until recently complete compatibility and/or accuracy left a bit to be desired. For half a decade, Mupen64Plus and Project64 have vied for the most playable emulator, and which was more compatible often depended on when and in what configuration each emulator has been tested. As of August 2017, both emulators have roughly equal compatibility and accuracy when running with the same [[recommended N64 plugins]] setup, though both default to Glide64, a now relatively lackluster plugin.<br />
<br />
;[[Mupen64Plus]]<br />
:A multi-platform emulator based on Hacktarux's Mupen64. It's about as accurate as Project64,<ref>loganmc10. [https://github.com/mupen64plus/mupen64plus-core/pull/336 ''Ignore TLB write if TLB entry is unmapping itself'']. "By the way, once this, along with the other PR's I have waiting are merged, we are at "compatibility parity" with Project64 as far as I can tell. I don't know of any game that doesn't boot with mupen64plus that works in PJ64."</ref> when both emulators are run with GLideN64. However, Mupen64Plus lacks a native GUI, instead being launched either from the command line or by dragging and dropping ROMs onto the executable and editing the config with a text editor. [[BizHawk]] and [[OpenEmu]] use forks of Mupen64Plus and its plugins for their N64 emulation, but they seem to be shallow. As of 2022 Project64-style overclocking for faster frame rates has been added under the option 'CountPerOpDenomPot'.<br />
<br />
:;Mupen64Plus-Next and ParaLLEl-N64<br />
:Both are heavily-modified forks developed as [[libretro]] cores. They introduce many features and optimizations not present in mainline alongside [[RetroArch]]'s general features, including 3-point texture filtering for Glide64, superior A/V sync and latency, and even an initially exclusive LLE Vulkan renderer based on Angrylion's pixel-perfect RDP plugin now known as ParaLLEl-RDP, making it a better alternative to the standalone version in some cases. 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.<br />
<br />
::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.<br />
<br />
:;[[m64p]]<br />
:A fork of Mupen64Plus with a custom-made Qt GUI. This is probably the easiest "out of the box" solution for Nintendo 64 emulation, as it comes bundled with ParaLLEl-RDP and ParaLLEl-RSP, ensuring both excellent compatibility and good speed without needing to mess with plugins or settings, provided your hardware supports Vulkan. However, unlike other emulators, it does not allow you to use other plugins. If GLideN64 is desired instead, there is an older build that retains it - unfortunately lacking the texture enhancement suite required for use of texture packs and upscaling. While it began as a shallow fork, it has increasingly become something closer to a hard fork, making various accuracy-focused changes to the emulation core that will require additional work to port back to upstream or to other forks.<br />
<br />
:;[[RMG]]<br />
:Rosalie's Mupen GUI is a project aiming to close the gap between Project64 and Mupen64Plus in terms of user experience. Its interface is about on par with m64p's in terms of cleanliness and ease of use, but unlike m64p, it allows you to use other plugins. The latest version comes bundled with GLideN64 and ParaLLEl-RDP for video plugins, and mupen64plus-hle-rsp and ParaLLEl-RSP for RSP plugins. However, for some reason it currently does not allow you access to ParaLLEl-RDP's options within its GUI, so if you wish to make use of features such as upscaling or downsampling, you must do so by editing the mupen64plus.cfg file, whereas m64p does expose these options in its GUI. However, if you prefer GLideN64, this is a superior alternative, as it does have access to its settings GUI, and the last version of m64p that uses GLideN64 is becoming increasingly outdated.<br />
<br />
:;Wii64 and Not64<br />
:Both are based on Mupen64, with Not64 being a fork of Wii64. Not64 claims to be better optimized 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 releases whenever possible.<br />
<br />
;[[Project64]]<br />
: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 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.<br />
<br />
;[[Ares]]<br />
:An open-source multi-system emulator and successor to Near's [[higan]] project, with a mostly original N64 core. Unlike other N64 emulators, it aims for high accuracy and does not employ HLE RSP or RDP emulation of any kind, not does it use game-specific hacks. It uses Themaister's ParaLLEl-RDP Vulkan renderer (with the MAME renderer as a software-based fallback) for pixel-perfect LLE graphics. While it is currently less compatible than Mupen64Plus or Project64, it is quickly catching up to them [https://ares-emu.net/compatibility/15 (only a handful of games are currently listed as partially or not working)], and it currently passes several stringent [https://github.com/ares-emulator/ares/pull/613 accuracy tests] the other emulators do not. However, it remains to be seen how accurate its developers are willing to make it without compromising speed and playability on current machines.<br />
<br />
;[[CEN64]]<br />
:Aims for cycle accuracy while at the same time aiming to eventually be usable on modern PC hardware. It lacks many features and has spotty compatibility, but it can already emulate some well-known edge cases such as picture recognition in Pokemon Snap. Unfortunately, its creator appears to have abandoned the project [https://github.com/n64dev/cen64/releases/tag/v0.3 citing lack of satisfaction with the program's performance in its current interpreter-based incarnation], and while the baton has been collectively passed to the n64dev community for further development, progress has been slow.<br />
<br />
;[[1964]]<br />
:Along with its various versions and forks, it was once a decent, speedy open-source alternative to Project64 and Mupen64, though it usually lagged behind the two compatibility-wise. Nowadays it has completely fallen off the radar as development has halted, and there is no longer a central code repo to speak of. There is little reason to use it nowadays outside of historical purposes, very specific edge cases, or if your device is too slow to run Mupen64Plus or Project64.<br />
<br />
;Daedalus<br />
:Is a Nintendo 64 emulator for PC which was ported to the PSP under the name of DaedalusX64. The PSP version later became the main version and got ported to platforms such as the Dreamcast, the PS2, the PS Vita, and the 3DS. On PSP, several games are able to reach full speed and most of them work with few emulation issues.<br />
<br />
;[[Sixtyforce]]<br />
:Is macOS-only, closed-source, and asks you to pay for full access to its features. It was once one of the only choices for Mac users, particularly those with older Macs since it's the only emulator with a <abbr title="Power PC">PPC</abbr> [[Dynamic recompilation|dynarec]]), but, with the switch to x86 and Mupen64Plus being ported to macOS, it has now become less relevant. However, development is still ongoing and is currently in its [https://sixtyforce.com/rosetta/ third rewrite] to support the upcoming [https://en.wikipedia.org/wiki/Apple-designed_processors Apple Silicon].<br />
<br />
;[[UltraHLE]]<br />
: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.<br />
<br />
;[[Ryu64]]<br />
:Is a Nintendo 64 emulator made in C#. The 'Ryu' word is named after the "RyuJIT" used in both Visual Basic & C#. But it might have been inspired by the lead author's sole (so far) [https://github.com/Ryujinx/Ryujinx/commits?author=Dudejoe870 commit] at Switch emulator, [[Ryujinx]]'s Git repository, and his depreciated [https://github.com/Dudejoe870/RyujinxAutoUpdate Ryujinx Auto Updater] tool. "86RYU", an x86 JIT compiler, is being developed alongside this emulator too.<br />
<br />
;n64oid<br />
:An Android exclusive Nintendo 64 emulator. It is similar to Project 64 1.6 in terms of compatibility, although it is unknown who authored it, as the APK for n64oid circulates on many legally questionable APK sites. n64oid has the infamous problem in Mario Kart 64 of the screen in Wario Stadium not displaying properly, as it displays nothing but black. It upscales all games to widescreen, which works well most of time, but on many phones it will have performance issues. The emulator is relatively poor, but it is much easier to set up than other options. The emulator features a menu with many similarities to the mobile edition of Snes9x EX+, and the My Boy! family of Android emulators for Game Boy systems.<br />
<br />
==Emulation issues==<br />
{{Main|Recommended N64 plugins}}<br />
<br />
Nintendo 64 emulation is now decent. A lot of the major problems that N64 emulation had in the past, have been fixed for quite some time now. The only catch is that the accurate emulators have higher system requirements. The main remaining problem is the lack of accurate cycle counting.<br />
<br />
===[[High/Low level emulation|High-level vs. low-level]] graphics===<br />
<br />
One of the biggest hurdles to emulating the Nintendo 64 was the Reality Display Processor (RDP), which used a custom design that had to be fine-tuned to get more performance out of the system using microcode. To emulate the RDP accurately, one would have to execute said microcode the way the RDP did, which differed from PC graphics cards of the day. To complicate matters further, API standards that were available on PCs two decades ago were nowhere near as flexible as they are today. If you wanted to make an accurate GPU-accelerated RDP plugin in 2003, you simply couldn't with the APIs of the time (OpenGL 1.x and Direct3D 9). For the average user, hardware-accurate GPU acceleration would be out of reach for a long time.<br />
<br />
[[UltraHLE]] offered a compromise. In contrast to earlier consoles, whose video chips in hindsight had been easy to render to the host CPU's framebuffer, performant RDP emulation had to take shortcuts, including programming around specific games' microcode to cleanly translate their graphics commands into API calls using Direct3D, OpenGL, and even Glide. With this, the theoretical system requirements plummeted, 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 is an improvement is subjective and a common point of discussion. Unfortunately it proved to be hit and miss, owing to the nature of per-game microcode detection and having to tweak settings to prevent some games from running into graphical glitches.<br />
<br />
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).<br />
<br />
On the high-level side, gonetz and one or two assistants spent a large portion of development improving GlideN64's microcode handling 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 framebuffer is used as well as performance issues), VI emulation, and how combine/blending modes are emulated (such as noise issues and combiner accuracy).<br />
<br />
<gallery widths="300" mode="packed"><br />
Majora's mask accurate.png| Low-level emulation of Majora's Mask using SoftGraphic<br />
Project64 2013-07-26 14-20-17-55.png| High-level emulation of Majora's Mask using Jabo's Direct3D<br />
</gallery><br />
<br />
===[[Texture filtering]]===<br />
The Nintendo 64 was the first consumer device to be able to filter textures when rendering 3D objects. However, unlike every console and PC graphics card made after the N64, its implementation of bilinear was primitive in that, in order to reduce strain on the system, it only used three samples as opposed to four, resulting in slightly jagged, asymmetrically-filtered textures. Instead of faithfully applying this "imperfect" version of bilinear filtering, HLE plugins instead applied conventional bilinear filtering, interpolating straight from the source texture up to the output resolution the same way a PC game would. While that method is technically superior, it can result in textures that look even blurrier than on real hardware.<br />
<br />
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 pre-rendered backgrounds or menu screens, may look as though they are separated into squares (see images below; note how OoT's Quest Status screen appears to be divided into a grid). 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 oftentimes low resolutions.<br />
<br />
Modern emulators and plugins have taken some steps which help remedy these problems. For instance, GLideN64 now supports N64-style three-point texture filtering, which results in a more faithful look. It is also capable of rendering at 320x240, which sidesteps the issues with filtered text, UI elements, and menu screens, while still retaining texture filtering. Pixel-accurate plugins such as Angrylion and ParaLLEl-RDP do not have these problems at all.<br />
<gallery widths="300" mode="packed"><br />
Project64_2013-06-26_17-44-58-31.png|Conker's Bad Fur Day copyright screen, displaying issues with filtered text.<br />
Mupen64plus_2013-08-18_20-35-50-08.png|Ocarina of Time's menu subscreen, displaying issues with filtering.</gallery><br />
<br />
===Timing issues===<br />
One of the biggest remaining problems in N64 emulation is lack of accurate core timings, which in practice means games do not always run at the speed they would on real hardware. While this technically affects all games, the majority are only affected to a negligible degree, and in some instances (particularly in Rare games) this can actually result in less framerate drops and lag, which can be seen as beneficial. However, some game engines actually depend on accurate timings for proper game behavior, and not properly emulating them can result in considerable to major issues. Some notable examples include the following:<br />
* Intros and cutscenes playing too fast and not properly syncing up with musical cues. Seen in Goldeneye's intro and Body Harvest's beginning cutscene.<br />
* Gameplay demos running at hyper speed. Earthworm Jim 3D is most notorious for this, though the main game itself is largely unaffected.<br />
* Game physics not working properly due to being tied to framerate. A good example is Donkey Kong 64, which is programmed to boost the character's speed and momentum proportional to in-game lag (most likely to make up for the game's frequent framerate drops), which can be exploited for certain glitches and sequence breaks on real hardware. Emulators currently run the game too well and with too little lag, making most of these tricks impossible to pull off.<br />
* Possibly the most affected game is Knife's Edge, which runs like it's on permanent fast-forward, making it all but unplayable. Messing with timing-related settings such as CounterFactor can mitigate this somewhat, but nowhere near enough to fix the issue.<br />
Fortunately, tackling these problems has recently become a core focus of development in some N64 emulators, and attempts are underway to improve the situation. Ares currently has the most accurate timings overall, and already runs Earthworm Jim 3D's demos much better than other emulators. Meanwhile, m64p has recently pushed various timing-related commits aimed at improving accuracy, and as a result it may now be the only emulator that runs Donkey Kong 64 properly. As these efforts progress, it should be noted that a side-effect of improved timings may be greater in-game lag. This should not be seen as the emulator becoming slower, but rather the emulator behaving exactly like real hardware does, as many N64 games were notorious for framerate drops.<br />
<br />
==Peripherals==<br />
===Voice Recognition Unit emulation===<br />
The Voice Recognition Unit (VRU) is an accessory used primarily by ''Hey You, Pikachu''. No emulator or input plugin supports this, although there is an on-going effort to get it working.<ref name="emutalk">{{cite web|url=http://www.emutalk.net/threads/55279|title=Hey You! Pikachu - Possible HLE Implementation|publisher=emutalk|accessdate=2018-06-17|date=2014-10-27, Last edit: 2016-04-04}}</ref><br />
===''Densha De Go!'' Controller===<br />
Also available for the [[PlayStation emulators|PlayStation]], ''Densha De Go! 64'' is a Japan-only train simulator released by [[Wikipedia:Taito|Taito]] that is compatible with an optional special controller that plugs into the player 3 port.<ref name="ArcadeUSA">{{cite web|url=https://www.youtube.com/watch?v=cCcPAGhcnck|title=Densha De Go! Nintendo 64 Controller!|publisher=YouTube|accessdate=2018-06-17|date=2017-01-20}}</ref> No emulator supports it.<br />
<br />
===Pokémon Snap Station===<br />
There was a special kiosk designed to promote ''Pokémon Snap'' called the ''Pokémon Snap Station'', which is also compatible with the North American ''Pokémon Stadium'' with its gallery mode. It is just a Nintendo 64 with special hardware designed for the station.<ref name="Sixty Formula">{{cite web|url=https://www.youtube.com/watch?v=AMbjvGvPkV4|title=The Pokemon Snap Station|publisher=YouTube|accessdate=2018-06-17|date=2016-05-21}}</ref><ref name="MetalJesusRocks">{{cite web|url=https://www.youtube.com/watch?v=5_UGpRN6AnM&t=3m35s|title=VIDEO GAME KIOSKS - Extreme Game Collecting!|publisher=YouTube|accessdate=2018-06-17|date=2016-05-25}}</ref> Although the special cartridge boots in emulators compatible with the regular version, the printing functions are inaccessible due to no emulation of the printer for the player 4 slot, credit system, or the special board to switch between the regular and special cartridges.<br />
<br />
===Transfer Pak emulation===<br />
A few games use the Transfer Pak such as ''Mario Golf'', ''Mario Tennis'', ''Mario Artist: Paint Studio'', and the ''Pokémon Stadium'' games. Mostly, this can be done with NRage's input plugin, but a couple of things aren't emulated:<br />
<br />
*Taking pictures with the Japanese ''Game Boy Camera'' (called ''Pocket Camera'') while in Transfer Pak mode playing ''Mario Artist: Paint Studio'' displays static.<br />
<br />
===64DD emulation===<br />
The 64DD (an abbreviation for "64 Disk Drive") was a peripheral which allowed a proprietary disk format to be used with the N64. These disks had more space at a cheaper manufacturing cost. The peripheral was a commercial failure and was never released outside of Japan. Internal evidence suggests that, much like the GBA e-Reader, it wasn't even intended for a European release.<br />
<br />
Expansion disks are region-coded to either Japan or the US (obviously unused) and won't work with N64 games from the wrong region. Only F-Zero X has full support for this feature, but dummied-out expansion data in Ocarina of Time and Mario Party 2 (JP/PAL) exist as well.<br />
<br />
The special AV-In cartridge (NUS-028) that ''Mario Artist: Talent Studio'' can use doesn't work because it requires an RCA cable signal.<br />
<br />
Recently, there has been an effort to emulate the 64DD, and now [[Project64]] and [[MAME]] can run several commercial 64DD games as part of its N64 emulator. This is being ported to [[CEN64]] with the help of [https://twitter.com/LuigiBlood LuigiBlood]. The latest newcomer is Mupen64Plus which is the base of other emulators such as [[m64p]] and [[RMG]].<br />
<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Platform(s)<br />
! scope="col"|Latest Version<br />
! scope="col"|N64 Mouse<br />
! scope="col"|64DD Emulation<br />
! scope="col"|Active<br />
! scope="col"|[[Recommended emulators|Recommended]]<br />
|-<br />
! colspan="7"|PC / x86<br />
|-<br />
|ParaLLEl<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://www.retroarch.com/ 2.0-rc2]<br />
|{{✓}}<br />
|Mid/High<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Project64]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://github.com/project64/project64 {{Project64Ver}}]<br >[https://64dd.org/downloads.html 64DD.org Builds]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[CEN64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/tj90241/cen64 git]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[m64p]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
||[https://github.com/loganmc10/m64p/releases git]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|{{✗}} (WIP)<br />
|-<br />
|[[MAME]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[http://www.mamedev.org/release.html {{MAMEVer}}]<br />
|{{✗}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|}<br />
<br />
* Project64's latest versions emulate the N64 mouse and can load Zoinkity's hacked 64DD cartridge conversions at playable speeds. You'll need to set every game to have 8MB of Memory by default manually. Games do not save, some need "32-bit engine" to be unchecked (like Talent Studio), and some (like Polygon Studio to fix models and Paint Studio to fix stamps) need the Angrylion GFX plugin rather than GlideN64, which does the job for the rest.<br />
**The 64DD hardware started to be emulated around 2.3's release with the help of [https://github.com/LuigiBlood LuigiBlood]. Saving works but in the form of NDR files. NDR files are copied versions of NDD images with save data included as to not write to the clean unaltered images. In order to play 64DD games in their original forms, 8MB of memory is still needed because the real hardware needed the Expansion Pak upgrade. The IPL is also needed.<br />
<br />
* MAME includes early basic 64DD emulation as well but is much slower. Disk images need to be in head/track format. See [https://github.com/Happy-yappH/ddconvert.git here] for more information. It does not currently support disk swapping or saving disk to files. Writes only update the copy in memory, and, once the MAME process ends, the changes are lost. Current usage: <code>mame n64dd -quickload disk -cart cart -nodrc</code> (both disk and cart are optional)<br />
<br />
* CEN64, like Project64, had 64DD emulation ported to it from MAME. However, it focuses on accuracy and plays much slower than other emulators, aside from the 64DD emulation itself is imperfect.<br />
<br />
==Hardware variants==<br />
===iQue Player emulation===<br />
Before the GBA, DS, and 3DS, Nintendo released a modified version of their Nintendo 64 system for the Chinese market, which was called the iQue Player, through their not-quite-subsidiary iQue. Fourteen games were translated into Simplified Chinese, including Sin and Punishment, Ocarina of Time (the Majora's Mask port was canceled), Super Mario 64, and others.<br />
<br />
Unlike the Chinese releases of their more recent systems and their games, iQue Player releases are regular N64 roms wrapped with several layers of encryption, as well as a ticket and signature system like that on Wii, DSi, 3DS, Wii U, and Switch. The Chinese ROM-hacking scene is very active though and has translated the Japanese regular N64 releases for many of these to their language already, which explains some of the Chinese ROMs floating for those. However, recently, almost all pieces of iQue Player software were decrypted to regular .z64 ROM format.<br />
<br />
Several of the Chinese game localizations already run on N64 emulators, but as some hardware features of the iQue Player are not yet supported, some games, as well as the system menu and features in games such as saving, do not work yet.<br />
<br />
===Aleck 64 arcade emulation===<br />
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). 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.<br />
<br />
The Aleck 64 ROMs were dumped, and Zoinkity is working on converting them to regular N64 ROMs (with controls remapped to N64 controller buttons). They generally require an 8MB Expansion Pak to run at all and 4K EEPROM to save settings and scores. The ones covered by these patches are:<br />
<br />
* Donchan Puzzle Hanabi de Doon!<br />
* Eleven Beat: World Tournament<br />
* Hi Pai Paradise<br />
* Hi Pai Paradise 2<br />
* Kuru Kuru Fever<br />
* Magical Tetris Challenge<br />
* Mayjinsen 3 / Meijin-Sen<br />
* Star Soldier: Vanishing Earth (also ported to N64)<br />
* Super Real Mahjong VS<br />
* Tower & Shaft<br />
* Vivid Dolls (official eroge game on a Nintendo console)<br />
<br />
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.<br />
<br />
The remaining ones from the system's library not yet covered are:<br />
* Rev Limit<br />
* Variant Schwanzer<br />
<br />
==Virtual Console games in Dolphin==<br />
A number of N64 games were released for the Wii's Virtual Console service throughout its lifespan. While the emulators at the heart of each Virtual Console title were of average accuracy (rather than using one generic emulator used for every game, each title had an emulator specifically tailored to that game), they were good enough to render the games in full playable capacity with few to no glaring errors. Many of these titles are emulated well through Dolphin, and for a good while, due to persistent long-standing inaccuracies in N64 emulators and plugins, this was the best way to emulate certain N64 games, particularly Pokemon Snap and Mario Tennis. The system requirements are much higher than running them on regular N64 emulators, but it's doable for many games. Today, regular N64 emulators and plugins have advanced to the degree that this has become unnecessary, relegating this method of N64 game emulation to little more than a curiosity, at least on PC.<br />
<br />
The following games are on the N64 Virtual Console for Wii:<br />
<br />
{|width="100%"<br />
|- valign="top"<br />
|<br />
* 1080 Snowboarding<br />
* Bomberman Hero<br />
* Cruis'n USA<br />
* Custom Robo V2 (Japan only)<br />
* F-Zero X<br />
* Kirby 64: The Crystal Stars<br />
* The Legend of Zelda: Majora's Mask<br />
* The Legend of Zelda: Ocarina of Time<br />
|<br />
* Mario Golf<br />
* Mario Kart 64<br />
* Mario Party 2<br />
* Mario Tennis<br />
* Ogre Battle 64: Person of Lordly Caliber<br />
* Paper Mario<br />
* Pokemon Puzzle League<br />
|<br />
* Pokemon Snap<br />
* Sin & Punishment (English)<br />
* Star Fox 64<br />
* Super Mario 64<br />
* Super Smash Bros.<br />
* Wave Race 64<br />
* Yoshi's Story<br />
|}<br />
<br />
==Notes==<br />
<references group=N /><br />
<br />
==References==<br />
<references/><br />
<br />
{{Nintendo}}<br />
<br />
[[Category:Consoles]]<br />
[[Category:Home consoles]]<br />
[[Category:Fifth-generation video game consoles]]<br />
[[Category:Nintendo consoles]]<br />
[[Category:Nintendo 64 emulators|*]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Nintendo_64_emulators&diff=48922Nintendo 64 emulators2022-08-01T05:20:47Z<p>GPDP1: More accurate information on the current status of Cen64</p>
<hr />
<div>{{Infobox console<br />
|title = Nintendo 64<br />
|logo = Nintendo64Console.png<br />
|developer = [[:Nintendo]]<br />
|type = [[:Category:Home consoles|Home video game console]]<br />
|generation = [[:Category:Fifth-generation video game consoles|Fifth generation]]<br />
|release = 1996<br />
|discontinued = 2002<br />
|predecessor = [[Super Nintendo emulators|SNES]]<br />
|successor = [[GameCube emulators|GameCube]]<br />
|emulated = {{✓}}<br />
}}<br />
<br />
{{for|other emulators that run on N64 hardware|Emulators on N64}} <br />
<br />
<br />
The '''Nintendo 64''' is a 64-bit fifth-generation console released by Nintendo on September 29, 1996 for {{inflation|USD|199.99|1996}}.<br />
<br />
Nintendo was the second company approached by Silicon Graphics Inc. (SGI), who wanted to roll out their previously enterprise-only technology in the consumer space. They originally pitched their idea to Sega, but it's assumed that Nintendo's offer was more appealing. With the NEC VR4300 CPU clocked at 93.75 MHz, 4MB of RAM,<ref group=N>Though a separate add-on was later released called the "Expansion Pak" that added an additional 4MB of RAM, totaling 8MB.</ref> and an SGI RCP GPU, Nintendo had finalized much of the hardware at least a year before launch, preventing video games from needing drastic rewrites as a result of architectural changes. The development workstations were often Unix-based, something that would later help reverse engineers in some projects.<br />
<br />
==Emulators==<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Platform(s)<br />
! scope="col"|Latest version<br />
! scope="col"|Plugins<br />
! scope="col"|Controller Pak<br />
! scope="col"|Rumble Pak<br />
! scope="col"|Transfer Pak<br />
! scope="col"|64DD<br />
! scope="col"|Depth<br/>output<br />
! scope="col"|Texture<br/>enhancement<br />
! scope="col"|Netplay<br />
! scope="col"|[[libretro]]<br />
! scope="col"|<abbr title="Free/Libre and Open-Source Software">FLOSS</abbr><br />
! scope="col"|Active<br />
! scope="col"|[[Recommended emulators|Recommended]]<br />
|-<br />
!colspan="15"|PC / x86<br />
|-<br />
|[[m64p]] (ParaLLEl)<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/loganmc10/m64p/releases/latest git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}³<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|m64p (Final GLideN64)<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/loganmc10/m64p/releases/tag/v2021.5.30 Final GLideN64]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|Mupen64Plus-Next<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://www.retroarch.com/ git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}¹<br />
|{{✓}}<br />
|{{✓}}*<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[RMG]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/Rosalie241/RMG/releases {{RMGVer}}]<br >[https://github.com/Rosalie241/RMG/actions Dev]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Project64]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://www.pj64-emu.com/public-releases {{Project64Ver}}]<br >[https://www.pj64-emu.com/nightly-builds Dev]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[BizHawk]]<br />
|align=left|{{Icon|Windows}}<br />
|[http://tasvideos.org/BizHawk/ReleaseHistory.html {{BizHawkVer}}]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[ares]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/ares-emulator/ares/releases {{aresVer}}]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|{{~}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[CEN64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/tj90241/cen64 git]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://github.com/mupen64plus/mupen64plus-core/releases git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|ParaLLEl-N64<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://www.retroarch.com/ 2.0-rc2]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{✓}}*<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[1964]]<br />
|align=left|{{Icon|Windows}}<br />
|[http://www.emulation64.com/files/getfile/936/ 1.1] (Official)<br />[http://files.emulation64.fr/Emulateurs/EMU_1964_146.zip 1.2 r146] (Unofficial SVN)<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}⁴<br />
|-<br />
|[[Project64 Netplay]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://github.com/Project64Netplay/Project64-Netplay-2x git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[DaedalusX64]]<br />
|align=left|{{Icon|Linux}}<br />
|[https://github.com/DaedalusX64/daedalus/releases/latest git]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[Sixtyforce]]<br />
|align=left|{{Icon|macOS}}<br />
|[http://sixtyforce.com/download/ {{SixtyforceVer}}]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Larper64<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://drive.google.com/file/d/1IWyw5UG9Uf24KG0zrcXSFoOmcQoHWmyc/view {{Larper64Ver}}]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|[[UltraHLE]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://web.archive.org/web/20070312015944/http://www.emuunlim.com/UltraHLE/ultrahle.zip 1.0]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|[[MAME]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[http://www.mamedev.org/release.html {{MAMEVer}}]<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[Ryu64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/Ryu64Emulator/Ryu64 git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|R64Emu<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/rasky/r64emu git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
!colspan="15"|Mobile / ARM<br />
|-<br />
|[[Mupen64Plus]] FZ<br />
|align=left|{{Icon|Android}}<br />
|[https://play.google.com/store/apps/details?id=org.mupen64plusae.v3.fzurita 3.0.322 (beta)]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}¹<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Pandora|Pyra}}<br />
|[http://repo.openpandora.org/?page=detail&app=mupen64plus Pandora]<br/>[https://pyra-handheld.com/repo/apps/39 Pyra]<br />
|?<br />
|{{✓}}<br />
|?<br />
|?<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
!colspan="15"|Consoles<br />
|-<br />
|[[Virtual Console]]<br />
|align=left|{{Icon|Wii|WiiU}}<br />
|N/A<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Not64<br />
|align=left|{{Icon|GCN|Wii}}<br />
|[https://github.com/Extrems/Not64/releases/latest git]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|[[DaedalusX64]]<br />
|align=left|{{Icon|PSP|3DS}}<br>{{Icon|Vita|PS2}}<br />
|[https://github.com/DaedalusX64/daedalus/releases/latest PSP]<br/>[https://github.com/masterfeizz/DaedalusX64-3DS/releases 3DS]<br/>[https://github.com/Rinnegatamante/DaedalusX64-vitaGL/releases VitaGL]<br/>[https://www.ps2-home.com/forum/viewtopic.php?f=99&p=39957#p39957 PS2]<br />
|?<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}} <small>(PSP)</small><br />
|{{~}}<br />
|-<br />
|Surreal64 CE<br />
|align=left|{{Icon|Xbox}}<br />
|[https://digiex.net/threads/surreal64-ce-b6-0-download-n64-emulator-for-xbox.13677 Beta 6.0]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|mupen64-360<br />
|align=left|{{Icon|Xbox360}}<br />
|[https://digiex.net/threads/mupen64-360-xbox-360-nintendo-64-n64-emulator-download.9352 0.96 beta]<br />
|?<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|[https://code.google.com/p/mupen64gc/ Wii64]<br />
|align=left|{{Icon|GCN|Wii}}<br />
|[https://code.google.com/archive/p/mupen64gc/downloads 1.1 beta]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|}<br />
<br />
*<nowiki>* Available exclusively as a libretro core</nowiki><br />
*<nowiki>¹ Only supports texture packs, and not filtering or upscaling</nowiki><br />
*<nowiki>² Requires replacing the input plugin to one with netplay support</nowiki><br />
*<nowiki>³ If not using Netplay, use RMG</nowiki><br />
*<nowiki>⁴ Highly recommended to use 1964 GEPD for Goldeneye 007 or Perfect Dark</nowiki><br />
<br />
===Comparisons===<br />
Although many Nintendo 64 emulators have been made and many games can be run between them, until recently complete compatibility and/or accuracy left a bit to be desired. For half a decade, Mupen64Plus and Project64 have vied for the most playable emulator, and which was more compatible often depended on when and in what configuration each emulator has been tested. As of August 2017, both emulators have roughly equal compatibility and accuracy when running with the same [[recommended N64 plugins]] setup, though both default to Glide64, a now relatively lackluster plugin.<br />
<br />
;[[Mupen64Plus]]<br />
:A multi-platform emulator based on Hacktarux's Mupen64. It's about as accurate as Project64,<ref>loganmc10. [https://github.com/mupen64plus/mupen64plus-core/pull/336 ''Ignore TLB write if TLB entry is unmapping itself'']. "By the way, once this, along with the other PR's I have waiting are merged, we are at "compatibility parity" with Project64 as far as I can tell. I don't know of any game that doesn't boot with mupen64plus that works in PJ64."</ref> when both emulators are run with GLideN64. However, Mupen64Plus lacks a native GUI, instead being launched either from the command line or by dragging and dropping ROMs onto the executable and editing the config with a text editor. [[BizHawk]] and [[OpenEmu]] use forks of Mupen64Plus and its plugins for their N64 emulation, but they seem to be shallow. As of 2022 Project64-style overclocking for faster frame rates has been added under the option 'CountPerOpDenomPot'.<br />
<br />
:;Mupen64Plus-Next and ParaLLEl-N64<br />
:Both are heavily-modified forks developed as [[libretro]] cores. They introduce many features and optimizations not present in mainline alongside [[RetroArch]]'s general features, including 3-point texture filtering for Glide64, superior A/V sync and latency, and even an initially exclusive LLE Vulkan renderer based on Angrylion's pixel-perfect RDP plugin now known as ParaLLEl-RDP, making it a better alternative to the standalone version in some cases. 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.<br />
<br />
::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.<br />
<br />
:;[[m64p]]<br />
:A fork of Mupen64Plus with a custom-made Qt GUI. This is probably the easiest "out of the box" solution for Nintendo 64 emulation, as it comes bundled with ParaLLEl-RDP and ParaLLEl-RSP, ensuring both excellent compatibility and good speed without needing to mess with plugins or settings, provided your hardware supports Vulkan. However, unlike other emulators, it does not allow you to use other plugins. If GLideN64 is desired instead, there is an older build that retains it - unfortunately lacking the texture enhancement suite required for use of texture packs and upscaling. While it began as a shallow fork, it has increasingly become something closer to a hard fork, making various accuracy-focused changes to the emulation core that will require additional work to port back to upstream or to other forks.<br />
<br />
:;[[RMG]]<br />
:Rosalie's Mupen GUI is a project aiming to close the gap between Project64 and Mupen64Plus in terms of user experience. Its interface is about on par with m64p's in terms of cleanliness and ease of use, but unlike m64p, it allows you to use other plugins. The latest version comes bundled with GLideN64 and ParaLLEl-RDP for video plugins, and mupen64plus-hle-rsp and ParaLLEl-RSP for RSP plugins. However, for some reason it currently does not allow you access to ParaLLEl-RDP's options within its GUI, so if you wish to make use of features such as upscaling or downsampling, you must do so by editing the mupen64plus.cfg file, whereas m64p does expose these options in its GUI. However, if you prefer GLideN64, this is a superior alternative, as it does have access to its settings GUI, and the last version of m64p that uses GLideN64 is becoming increasingly outdated.<br />
<br />
:;Wii64 and Not64<br />
:Both are based on Mupen64, with Not64 being a fork of Wii64. Not64 claims to be better optimized 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 releases whenever possible.<br />
<br />
;[[Project64]]<br />
: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 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.<br />
<br />
;[[Ares]]<br />
:An open-source multi-system emulator and successor to Near's [[higan]] project, with a mostly original N64 core. Unlike other N64 emulators, it aims for high accuracy and does not employ HLE RSP or RDP emulation of any kind, not does it use game-specific hacks. It uses Themaister's ParaLLEl-RDP Vulkan renderer (with the MAME renderer as a software-based fallback) for pixel-perfect LLE graphics. While it is currently less compatible than Mupen64Plus or Project64, it is quickly catching up to them [https://ares-emu.net/compatibility/15 (only a handful of games are currently listed as partially or not working)], and it currently passes several stringent [https://github.com/ares-emulator/ares/pull/613 accuracy tests] the other emulators do not. However, it remains to be seen how accurate its developers are willing to make it without compromising speed and playability on current machines.<br />
<br />
;[[CEN64]]<br />
:Aims for cycle accuracy while at the same time aiming to eventually be usable on modern PC hardware. It lacks many features and has spotty compatibility, but it can already emulate some well-known edge cases such as picture recognition in Pokemon Snap. Unfortunately, its creator appears to have abandoned the project [https://github.com/n64dev/cen64/releases/tag/v0.3 citing lack of satisfaction with the program's performance in its current interpreter-based incarnation], and while the baton has been collectively passed to the n64dev community for further development, progress has been slow.<br />
<br />
;[[1964]]<br />
:Along with its various versions and forks, it was once a decent, speedy open-source alternative to Project64 and Mupen64, though it usually lagged behind the two compatibility-wise. Nowadays it has completely fallen off the radar as development has halted, and there is no longer a central code repo to speak of. There is little reason to use it nowadays outside of historical purposes, very specific edge cases, or if your device is too slow to run Mupen64Plus or Project64.<br />
<br />
;Daedalus<br />
:Is a Nintendo 64 emulator for PC which was ported to the PSP under the name of DaedalusX64. The PSP version later became the main version and got ported to platforms such as the Dreamcast, the PS2, the PS Vita, and the 3DS. On PSP, several games are able to reach full speed and most of them work with few emulation issues.<br />
<br />
;[[Sixtyforce]]<br />
:Is macOS-only, closed-source, and asks you to pay for full access to its features. It was once one of the only choices for Mac users, particularly those with older Macs since it's the only emulator with a <abbr title="Power PC">PPC</abbr> [[Dynamic recompilation|dynarec]]), but, with the switch to x86 and Mupen64Plus being ported to macOS, it has now become less relevant. However, development is still ongoing and is currently in its [https://sixtyforce.com/rosetta/ third rewrite] to support the upcoming [https://en.wikipedia.org/wiki/Apple-designed_processors Apple Silicon].<br />
<br />
;[[UltraHLE]]<br />
: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.<br />
<br />
;[[Ryu64]]<br />
:Is a Nintendo 64 emulator made in C#. The 'Ryu' word is named after the "RyuJIT" used in both Visual Basic & C#. But it might have been inspired by the lead author's sole (so far) [https://github.com/Ryujinx/Ryujinx/commits?author=Dudejoe870 commit] at Switch emulator, [[Ryujinx]]'s Git repository, and his depreciated [https://github.com/Dudejoe870/RyujinxAutoUpdate Ryujinx Auto Updater] tool. "86RYU", an x86 JIT compiler, is being developed alongside this emulator too.<br />
<br />
;n64oid<br />
:An Android exclusive Nintendo 64 emulator. It is similar to Project 64 1.6 in terms of compatibility, although it is unknown who authored it, as the APK for n64oid circulates on many legally questionable APK sites. n64oid has the infamous problem in Mario Kart 64 of the screen in Wario Stadium not displaying properly, as it displays nothing but black. It upscales all games to widescreen, which works well most of time, but on many phones it will have performance issues. The emulator is relatively poor, but it is much easier to set up than other options. The emulator features a menu with many similarities to the mobile edition of Snes9x EX+, and the My Boy! family of Android emulators for Game Boy systems.<br />
<br />
==Emulation issues==<br />
{{Main|Recommended N64 plugins}}<br />
<br />
Nintendo 64 emulation is now decent. A lot of the major problems that N64 emulation had in the past, have been fixed for quite some time now. The only catch is that the accurate emulators have higher system requirements. The main remaining problem is the lack of accurate cycle counting.<br />
<br />
===[[High/Low level emulation|High-level vs. low-level]] graphics===<br />
<br />
One of the biggest hurdles to emulating the Nintendo 64 was the Reality Display Processor (RDP), which used a custom design that had to be fine-tuned to get more performance out of the system using microcode. To emulate the RDP accurately, one would have to execute said microcode the way the RDP did, which differed from PC graphics cards of the day. To complicate matters further, API standards that were available on PCs two decades ago were nowhere near as flexible as they are today. If you wanted to make an accurate GPU-accelerated RDP plugin in 2003, you simply couldn't with the APIs of the time (OpenGL 1.x and Direct3D 9). For the average user, hardware-accurate GPU acceleration would be out of reach for a long time.<br />
<br />
[[UltraHLE]] offered a compromise. In contrast to earlier consoles, whose video chips in hindsight had been easy to render to the host CPU's framebuffer, performant RDP emulation had to take shortcuts, including programming around specific games' microcode to cleanly translate their graphics commands into API calls using Direct3D, OpenGL, and even Glide. With this, the theoretical system requirements plummeted, 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 is an improvement is subjective and a common point of discussion. Unfortunately it proved to be hit and miss, owing to the nature of per-game microcode detection and having to tweak settings to prevent some games from running into graphical glitches.<br />
<br />
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).<br />
<br />
On the high-level side, gonetz and one or two assistants spent a large portion of development improving GlideN64's microcode handling 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 framebuffer is used as well as performance issues), VI emulation, and how combine/blending modes are emulated (such as noise issues and combiner accuracy).<br />
<br />
<gallery widths="300" mode="packed"><br />
Majora's mask accurate.png| Low-level emulation of Majora's Mask using SoftGraphic<br />
Project64 2013-07-26 14-20-17-55.png| High-level emulation of Majora's Mask using Jabo's Direct3D<br />
</gallery><br />
<br />
===[[Texture filtering]]===<br />
The Nintendo 64 was the first consumer device to be able to filter textures when rendering 3D objects. However, unlike every console and PC graphics card made after the N64, its implementation of bilinear was primitive in that, in order to reduce strain on the system, it only used three samples as opposed to four, resulting in slightly jagged, asymmetrically-filtered textures. Instead of faithfully applying this "imperfect" version of bilinear filtering, HLE plugins instead applied conventional bilinear filtering, interpolating straight from the source texture up to the output resolution the same way a PC game would. While that method is technically superior, it can result in textures that look even blurrier than on real hardware.<br />
<br />
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 pre-rendered backgrounds or menu screens, may look as though they are separated into squares (see images below; note how OoT's Quest Status screen appears to be divided into a grid). 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 oftentimes low resolutions.<br />
<br />
Modern emulators and plugins have taken some steps which help remedy these problems. For instance, GLideN64 now supports N64-style three-point texture filtering, which results in a more faithful look. It is also capable of rendering at 320x240, which sidesteps the issues with filtered text, UI elements, and menu screens, while still retaining texture filtering. Pixel-accurate plugins such as Angrylion and ParaLLEl-RDP do not have these problems at all.<br />
<gallery widths="300" mode="packed"><br />
Project64_2013-06-26_17-44-58-31.png|Conker's Bad Fur Day copyright screen, displaying issues with filtered text.<br />
Mupen64plus_2013-08-18_20-35-50-08.png|Ocarina of Time's menu subscreen, displaying issues with filtering.</gallery><br />
<br />
===Timing issues===<br />
One of the biggest remaining problems in N64 emulation is lack of accurate core timings, which in practice means games do not always run at the speed they would on real hardware. While this technically affects all games, the majority are only affected to a negligible degree, and in some instances (particularly in Rare games) this can actually result in less framerate drops and lag, which can be seen as beneficial. However, some game engines actually depend on accurate timings for proper game behavior, and not properly emulating them can result in considerable to major issues. Some notable examples include the following:<br />
* Intros and cutscenes playing too fast and not properly syncing up with musical cues. Seen in Goldeneye's intro and Body Harvest's beginning cutscene.<br />
* Gameplay demos running at hyper speed. Earthworm Jim 3D is most notorious for this, though the main game itself is largely unaffected.<br />
* Game physics not working properly due to being tied to framerate. A good example is Donkey Kong 64, which is programmed to boost the character's speed and momentum proportional to in-game lag (most likely to make up for the game's frequent framerate drops), which can be exploited for certain glitches and sequence breaks on real hardware. Emulators currently run the game too well and with too little lag, making most of these tricks impossible to pull off.<br />
* Possibly the most affected game is Knife's Edge, which runs like it's on permanent fast-forward, making it all but unplayable. Messing with timing-related settings such as CounterFactor can mitigate this somewhat, but nowhere near enough to fix the issue.<br />
Fortunately, tackling these problems has recently become a core focus of development in some N64 emulators, and attempts are underway to improve the situation. Ares currently has the most accurate timings overall, and already runs Earthworm Jim 3D's demos much better than other emulators. Meanwhile, m64p has recently pushed various timing-related commits aimed at improving accuracy, and as a result it may now be the only emulator that runs Donkey Kong 64 properly. As these efforts progress, it should be noted that a side-effect of improved timings may be greater in-game lag. This should not be seen as the emulator becoming slower, but rather the emulator behaving exactly like real hardware does, as many N64 games were notorious for framerate drops.<br />
<br />
==Peripherals==<br />
===Voice Recognition Unit emulation===<br />
The Voice Recognition Unit (VRU) is an accessory used primarily by ''Hey You, Pikachu''. No emulator or input plugin supports this, although there is an on-going effort to get it working.<ref name="emutalk">{{cite web|url=http://www.emutalk.net/threads/55279|title=Hey You! Pikachu - Possible HLE Implementation|publisher=emutalk|accessdate=2018-06-17|date=2014-10-27, Last edit: 2016-04-04}}</ref><br />
===''Densha De Go!'' Controller===<br />
Also available for the [[PlayStation emulators|PlayStation]], ''Densha De Go! 64'' is a Japan-only train simulator released by [[Wikipedia:Taito|Taito]] that is compatible with an optional special controller that plugs into the player 3 port.<ref name="ArcadeUSA">{{cite web|url=https://www.youtube.com/watch?v=cCcPAGhcnck|title=Densha De Go! Nintendo 64 Controller!|publisher=YouTube|accessdate=2018-06-17|date=2017-01-20}}</ref> No emulator supports it.<br />
<br />
===Pokémon Snap Station===<br />
There was a special kiosk designed to promote ''Pokémon Snap'' called the ''Pokémon Snap Station'', which is also compatible with the North American ''Pokémon Stadium'' with its gallery mode. It is just a Nintendo 64 with special hardware designed for the station.<ref name="Sixty Formula">{{cite web|url=https://www.youtube.com/watch?v=AMbjvGvPkV4|title=The Pokemon Snap Station|publisher=YouTube|accessdate=2018-06-17|date=2016-05-21}}</ref><ref name="MetalJesusRocks">{{cite web|url=https://www.youtube.com/watch?v=5_UGpRN6AnM&t=3m35s|title=VIDEO GAME KIOSKS - Extreme Game Collecting!|publisher=YouTube|accessdate=2018-06-17|date=2016-05-25}}</ref> Although the special cartridge boots in emulators compatible with the regular version, the printing functions are inaccessible due to no emulation of the printer for the player 4 slot, credit system, or the special board to switch between the regular and special cartridges.<br />
<br />
===Transfer Pak emulation===<br />
A few games use the Transfer Pak such as ''Mario Golf'', ''Mario Tennis'', ''Mario Artist: Paint Studio'', and the ''Pokémon Stadium'' games. Mostly, this can be done with NRage's input plugin, but a couple of things aren't emulated:<br />
<br />
*Taking pictures with the Japanese ''Game Boy Camera'' (called ''Pocket Camera'') while in Transfer Pak mode playing ''Mario Artist: Paint Studio'' displays static.<br />
<br />
===64DD emulation===<br />
The 64DD (an abbreviation for "64 Disk Drive") was a peripheral which allowed a proprietary disk format to be used with the N64. These disks had more space at a cheaper manufacturing cost. The peripheral was a commercial failure and was never released outside of Japan. Internal evidence suggests that, much like the GBA e-Reader, it wasn't even intended for a European release.<br />
<br />
Expansion disks are region-coded to either Japan or the US (obviously unused) and won't work with N64 games from the wrong region. Only F-Zero X has full support for this feature, but dummied-out expansion data in Ocarina of Time and Mario Party 2 (JP/PAL) exist as well.<br />
<br />
The special AV-In cartridge (NUS-028) that ''Mario Artist: Talent Studio'' can use doesn't work because it requires an RCA cable signal.<br />
<br />
Recently, there has been an effort to emulate the 64DD, and now [[Project64]] and [[MAME]] can run several commercial 64DD games as part of its N64 emulator. This is being ported to [[CEN64]] with the help of [https://twitter.com/LuigiBlood LuigiBlood]. The latest newcomer is Mupen64Plus which is the base of other emulators such as [[m64p]] and [[RMG]].<br />
<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Platform(s)<br />
! scope="col"|Latest Version<br />
! scope="col"|N64 Mouse<br />
! scope="col"|64DD Emulation<br />
! scope="col"|Active<br />
! scope="col"|[[Recommended emulators|Recommended]]<br />
|-<br />
! colspan="7"|PC / x86<br />
|-<br />
|ParaLLEl<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://www.retroarch.com/ 2.0-rc2]<br />
|{{✓}}<br />
|Mid/High<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Project64]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://github.com/project64/project64 {{Project64Ver}}]<br >[https://64dd.org/downloads.html 64DD.org Builds]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[CEN64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/tj90241/cen64 git]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[m64p]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
||[https://github.com/loganmc10/m64p/releases git]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|{{✗}} (WIP)<br />
|-<br />
|[[MAME]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[http://www.mamedev.org/release.html {{MAMEVer}}]<br />
|{{✗}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|}<br />
<br />
* Project64's latest versions emulate the N64 mouse and can load Zoinkity's hacked 64DD cartridge conversions at playable speeds. You'll need to set every game to have 8MB of Memory by default manually. Games do not save, some need "32-bit engine" to be unchecked (like Talent Studio), and some (like Polygon Studio to fix models and Paint Studio to fix stamps) need the Angrylion GFX plugin rather than GlideN64, which does the job for the rest.<br />
**The 64DD hardware started to be emulated around 2.3's release with the help of [https://github.com/LuigiBlood LuigiBlood]. Saving works but in the form of NDR files. NDR files are copied versions of NDD images with save data included as to not write to the clean unaltered images. In order to play 64DD games in their original forms, 8MB of memory is still needed because the real hardware needed the Expansion Pak upgrade. The IPL is also needed.<br />
<br />
* MAME includes early basic 64DD emulation as well but is much slower. Disk images need to be in head/track format. See [https://github.com/Happy-yappH/ddconvert.git here] for more information. It does not currently support disk swapping or saving disk to files. Writes only update the copy in memory, and, once the MAME process ends, the changes are lost. Current usage: <code>mame n64dd -quickload disk -cart cart -nodrc</code> (both disk and cart are optional)<br />
<br />
* CEN64, like Project64, had 64DD emulation ported to it from MAME. However, it focuses on accuracy and plays much slower than other emulators, aside from the 64DD emulation itself is imperfect.<br />
<br />
==Hardware variants==<br />
===iQue Player emulation===<br />
Before the GBA, DS, and 3DS, Nintendo released a modified version of their Nintendo 64 system for the Chinese market, which was called the iQue Player, through their not-quite-subsidiary iQue. Fourteen games were translated into Simplified Chinese, including Sin and Punishment, Ocarina of Time (the Majora's Mask port was canceled), Super Mario 64, and others.<br />
<br />
Unlike the Chinese releases of their more recent systems and their games, iQue Player releases are regular N64 roms wrapped with several layers of encryption, as well as a ticket and signature system like that on Wii, DSi, 3DS, Wii U, and Switch. The Chinese ROM-hacking scene is very active though and has translated the Japanese regular N64 releases for many of these to their language already, which explains some of the Chinese ROMs floating for those. However, recently, almost all pieces of iQue Player software were decrypted to regular .z64 ROM format.<br />
<br />
Several of the Chinese game localizations already run on N64 emulators, but as some hardware features of the iQue Player are not yet supported, some games, as well as the system menu and features in games such as saving, do not work yet.<br />
<br />
===Aleck 64 arcade emulation===<br />
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). 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.<br />
<br />
The Aleck 64 ROMs were dumped, and Zoinkity is working on converting them to regular N64 ROMs (with controls remapped to N64 controller buttons). They generally require an 8MB Expansion Pak to run at all and 4K EEPROM to save settings and scores. The ones covered by these patches are:<br />
<br />
* Donchan Puzzle Hanabi de Doon!<br />
* Eleven Beat: World Tournament<br />
* Hi Pai Paradise<br />
* Hi Pai Paradise 2<br />
* Kuru Kuru Fever<br />
* Magical Tetris Challenge<br />
* Mayjinsen 3 / Meijin-Sen<br />
* Star Soldier: Vanishing Earth (also ported to N64)<br />
* Super Real Mahjong VS<br />
* Tower & Shaft<br />
* Vivid Dolls (official eroge game on a Nintendo console)<br />
<br />
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.<br />
<br />
The remaining ones from the system's library not yet covered are:<br />
* Rev Limit<br />
* Variant Schwanzer<br />
<br />
==Virtual Console games in Dolphin==<br />
A number of N64 games were released for the Wii's Virtual Console service throughout its lifespan. While the emulators at the heart of each Virtual Console title were of average accuracy (rather than using one generic emulator used for every game, each title had an emulator specifically tailored to that game), they were good enough to render the games in full playable capacity with few to no glaring errors. Many of these titles are emulated well through Dolphin, and for a good while, due to persistent long-standing inaccuracies in N64 emulators and plugins, this was the best way to emulate certain N64 games, particularly Pokemon Snap and Mario Tennis. The system requirements are much higher than running them on regular N64 emulators, but it's doable for many games. Today, regular N64 emulators and plugins have advanced to the degree that this has become unnecessary, relegating this method of N64 game emulation to little more than a curiosity, at least on PC.<br />
<br />
The following games are on the N64 Virtual Console for Wii:<br />
<br />
{|width="100%"<br />
|- valign="top"<br />
|<br />
* 1080 Snowboarding<br />
* Bomberman Hero<br />
* Cruis'n USA<br />
* Custom Robo V2 (Japan only)<br />
* F-Zero X<br />
* Kirby 64: The Crystal Stars<br />
* The Legend of Zelda: Majora's Mask<br />
* The Legend of Zelda: Ocarina of Time<br />
|<br />
* Mario Golf<br />
* Mario Kart 64<br />
* Mario Party 2<br />
* Mario Tennis<br />
* Ogre Battle 64: Person of Lordly Caliber<br />
* Paper Mario<br />
* Pokemon Puzzle League<br />
|<br />
* Pokemon Snap<br />
* Sin & Punishment (English)<br />
* Star Fox 64<br />
* Super Mario 64<br />
* Super Smash Bros.<br />
* Wave Race 64<br />
* Yoshi's Story<br />
|}<br />
<br />
==Notes==<br />
<references group=N /><br />
<br />
==References==<br />
<references/><br />
<br />
{{Nintendo}}<br />
<br />
[[Category:Consoles]]<br />
[[Category:Home consoles]]<br />
[[Category:Fifth-generation video game consoles]]<br />
[[Category:Nintendo consoles]]<br />
[[Category:Nintendo 64 emulators|*]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=CRT_shaders&diff=48888CRT shaders2022-07-29T21:30:00Z<p>GPDP1: Updated info on crt-guest-advanced reflecting new updates</p>
<hr />
<div>[[File:Retroarch_2013-07-22_17-21-17-60.png|thumb|298px|CRT-Geom-Flat, with default settings]]<br />
CRT shaders are one of the most popular categories of shaders. While there had been many attempts to include some kind of CRT-esque filters in older emulators - usually involving little more than overlaying dark gray or black lines, colloquially referred to as scanlines, over the image - modern CRT shaders are much more complex and configurable.<br />
<br />
Many of these replicate aperture grille CRTs (exemplified primarily by Sony TVs and monitors, though other manufacturers released their own versions of the technology later on), which have sharp images and strong scanlines. If you find that these shaders don't look a damn thing like your old TV, it's probably because you owned a slot mask-style CRT, which typically had less noticeable scanlines, or simply had a smaller set, which tended to be less sharp. The easiest way to tell the difference is to feel the curve of the screen; aperture grilles only curve horizontally if at all. Alternatively, look at the left and right sides of the glass against the frame - if the sides are curved, it's a slot mask; if they're straight, it's an aperture grille. Old TVs usually had slot masks, whereas monitors usually had shadow masks. While slot masks and shadow masks can be emulated to a certain degree even at 1080p, much higher resolutions like 4K or higher are better suited to the task. Aperture grilles are much easier to emulate, and can be satisfactorily replicated at 1080p, though it goes without saying even better results can be achieved with higher resolution.<br />
<br />
It is advisable to use integer scaling when using CRT shaders. This means either using windowed mode (x2,x3,x4) or setting an integer scaling option in the video options. The reason is that non-integer scaled scanlines will result in uneven lines with artifacts, though some shaders use oversampling to try to avoid this. If the resulting letterboxing annoys you and you still want to fill up as much of your screen's real estate as possible, you can also try integer scale overscaling, which scales the image up by another integer to fill the vertical image space while still preserving integer scaling, at the expense of some of the image on the top and bottom being cut off. As an example, at 1080p, turning on overscaling would scale a typical SNES game running at 256x224 to 5x scale i.e. 1280x1120, cutting off twenty pixels from both the top and bottom of the image to reach 1080p. Before you fret, know that at 1080p and 4K the loss from overscaling is usually negligible and well within the area that would've been expected to be cut off on a real CRT anyway due to overscan, and developers almost always took this into account and made sure not to put any crucial game information there, so on many if not most older games, overscaling is completely safe.<br />
<br />
==Download==<br />
All official releases of RetroArch come bundled with a full set of slang and GLSL shaders, including CRT shaders, pulled from their shader repositories on Github, which are regularly maintained and updated. The simplest way to keep up to date with shader development is through RetroArch's built-in updater, though if you are only interested in the CRT shaders, you can alternatively grab them from the following repos:<br />
<br />
[https://github.com/libretro/slang-shaders/tree/master/crt slang shaders] - For use with devices that support Vulkan, OpenGL 3.x, GLES3, and/or D3D10/11/12. This is the most current, regularly maintained repository.<br />
<br />
[https://github.com/libretro/glsl-shaders/tree/master/crt GLSL shaders] - For use with devices that only support up to OpenGL 2.x or GLES2. Largely deprecated, though still sporadically maintained.<br />
<br />
[https://github.com/libretro/common-shaders/tree/master/crt Cg shaders] - For use on platforms that only support Cg or HLSL runtimes, such as the PS3. Deprecated.<br />
<br />
==Types==<br />
===CRT-Geom===<br />
[[File:Retroarch_2013-07-22_17-21-17-60.png|thumb|298px|CRT-Geom-Flat, with default settings]]<br />
{{Main|CRT Geom}}<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-geom.slang crt-geom.slang]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-cgwg-fast.slang crt-cgwg-fast.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/geom-deluxe crt-geom-deluxe]<br />
<br />
A very versatile and modifiable shader that simulates an aperture grille display (with the mask enabled). One of the first popular CRT shaders. The deluxe version adds more features, including more mask types. Visit the main article for more details.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
----<br />
===CRT-Caligari===<br />
[[File:crt-caligari-sm.png|thumb|298px|CRT-Caligari, with default settings at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-caligari.slang crt-caligari.slang]<br />
<br />
An older CRT shader similar to CRT-Geom that uses different methods to achieve its effects.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
----<br />
===CRT-Easymode===<br />
[[File:crt-easymode.png|thumb|298px|CRT-Easymode, with default settings at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-easymode.slang crt-easymode.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-easymode-halation crt-easymode-halation]<br />
<br />
A fast, relatively simple CRT shader with easy-to-understand settings. Similar to CRT-Geom in its effects.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
----<br />
===CRT-Hyllian===<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/hyllian crt-hyllian]<br />
*[https://forums.libretro.com/t/crt-hyllian-and-its-variants/38137 Hyllian's shader development thread]<br />
<br />
Aims only for picture quality, so it avoids things that degrade the image just for accuracy. It, however, uses far less power to run than most other CRT shaders, so it is possible to run this on lower end systems. <br />
<br />
Recently, after a long period of inactivity, Hyllian has restarted shader development anew, releasing all-new versions of this shader under heavy inspiration from CRT-Guest-Advanced and others. They can be acquired at his thread on the libretro forums, linked above.<br />
<br />
<br />
----<br />
===CRT-Lottes===<br />
[[File:crt-lottes-multipass.png|thumb|298px|CRT-Lottes-Multipass, with default settings at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-lottes.slang crt-lottes.slang]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-lottes-fast.slang crt-lottes-fast.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-lottes-multipass crt-lottes-multipass]<br />
<br />
A newer CRT shader that uses a horizontal shadow mask pattern with blooming. The horizontal pattern works quite well at 1080p, though it isn't entirely accurate to a true vertical slot mask pattern. The multipass version adds scanline bloom and a few other features.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
----<br />
===GTU===<br />
[[File:GTU.png|thumb|298px|GTU, with default settings at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/gtu-v050 GTUv050 slang]<br />
*[https://github.com/hizzlekizzle/quark-shaders/tree/master/GTU.shader GTUv040 Quark]<br />
*[https://github.com/libretro/slang-shaders/tree/master/nes_raw_palette/shaders/gtu-famicom GTU-Famicom slang]<br />
*[https://github.com/hunterk/interpolation-shaders/raw/master/GTUv050test.tar.gz GTUv50 Test program]<br />
<br />
A CRT shader that focuses more on simulating blur and blending effects and color levels of CRT screens rather than the physical attributes like phosphors and curvature. Highly configurable, can be really sharp, or really blurry or anywhere in between, with optional scanlines and contrast and gamma settings. Settings are stored in a separate "config.h" file for easy editing. GTU-Famicom is a variant that takes an image from an NES with "raw" colors and processes it to output an NTSC image much like an actual NES PPU.<br />
<br />
The test program is a program that can adjust various attributes, such as horizontal and vertical blur, scanlines, etc. It is useful for testing settings to use with the shader, and also to understand how CRT shaders work in general.<br />
<br />
<br />
<br />
<br />
<br />
<br />
----<br />
===ZFast_CRT===<br />
[[File:crt-zfast.png|thumb|298px|ZFast_CRT, with aperture grille mask enabled at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/zfast_crt zfast_crt]<br />
<br />
An extremely fast CRT shader made to run at full speed on extremely low-end hardware like the Raspberri Pi 3. Probably the fastest shader on this list.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
----<br />
===CRT-Royale===<br />
{{Main|CRT-Royale}}<br />
[[File:crt-royale.png|thumb|298px|CRT-Royale, with default settings at 1080p (view original for full details)]]<br />
<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-royale CRT-Royale]<br />
*[https://github.com/libretro/slang-shaders/blob/master/presets/crt-royale-kurozumi.slangp CRT-Royale-Kurozumi]<br />
<br />
A highly advanced multi-pass CRT shader that simulates almost every aspect of the CRT screen. There are tons of parameters to configure, such as phosphor type (aperture grille, slot mask, and EDP shadow mask) and size (i.e. dot pitch), convergence offsets, scanline blooming and many others. Higher resolution is better for this shader, especially with EDP shadow mask phosphor layout and with smaller phosphor dot pitch values. This shader is really complicated compared to most other CRT shaders, reading the README and the documentation in the user-settings.h is a must.<br />
<br />
CRT-Royale-Kurozumi is a preconfigured CRT-Royale made to look like a professional CRT monitor, specifically Sony's PVM/BVM line of monitors.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
----<br />
===CRT-Guest-Advanced===<br />
[[File:crt-guest-dr-venom.png|thumb|298px|CRT-Guest-Dr-Venom, with default settings at 1080p. The newer Advanced shader's default settings look identical (view original for full details)]]<br />
*[https://forums.libretro.com/t/new-crt-shader-from-guest-crt-guest-advanced-updates/25444 Guest's shader development thread]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/guest crt-guest-advanced]<br />
*[https://github.com/libretro/glsl-shaders/tree/master/crt/shaders/guest crt-guest-dr-venom]<br />
<br />
This is quite possibly the most advanced, feature-rich CRT shader of all. It has just as many if not more parameters to configure than CRT-Royale while being more optimized, and if greater speed is desired, there are several faster versions available, as well as variants that add other neat features such as NTSC emulation and better support for games that render at 480p or higher. It is also still in active development and continues to regularly gain features and optimizations. Take heed, however: while it is hosted on the RetroArch shader repositories, it is only updated in that platform when Guest himself deems it ready. Much more regular WIP releases are made in the libretro forums in the shader's dedicated thread, linked above. The version in the RetroArch repo is currently up-to-date, but it might not hurt to check on Guest's thread for newer developments.<br />
<br />
CRT-Guest-Dr-Venom is the precursor to CRT-Guest-Advanced. While it is now considered outdated and not as feature-filled as Guest's newest shaders, it is much faster, more so than even the fastest Advanced preset, and it still has plenty of things to tweak to deliver a pleasing image. It therefore fills a middle-of-the-road niche among CRT shaders, delivering a nice balance of features and performance. However, it has recently been removed from the slang shader repository, though it is still available as a glsl shader, and the slang version can still be acquired in the first post of Guest's thread. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===Sony Megatron===<br />
[[File:sony-megatron.png|thumb|298px|Sony Megatron, using the reference preset in SDR mode with the "1000 TVL" aperture grille mask (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/tree/master/hdr Sony Megatron]<br />
*[https://forums.libretro.com/t/sony-megatron-colour-video-monitor/36109 Sony Megatron development and discussion thread]<br />
<br />
This shader is quite unique among CRT shaders, and shaders in general. It is currently the only shader that takes advantage of HDR support for greater color depth and brightness, allowing for highly accurate CRT emulation on HDR-capable displays, though it is also usable on regular SDR displays through a parameter change. Unlike other CRT shaders, its inner workings are actually fairly simple and it doesn't have many bells and whistles, focusing mainly on drawing scanlines and accurate phosphor masks as well as color correction, which coincidentally also makes it one of the fastest shaders featured on this page. As it is primarily meant for use on bright HDR-capable displays, it draws phosphor masks at full strength with no attempt at mitigating the resulting loss in brightness through parameters such as bloom, glow or mask strength typically seen in other CRT shaders, instead counting on the display to make up for it. On an SDR display, it is highly recommended to use it with the backlight turned up all the way, as otherwise the image will likely be too dim to view comfortably. There are presets emulating various CRT models and types, including several PVM models, certain arcade displays, and even PC monitors.<br />
<br />
==Future==<br />
<br />
===Phosphor Mask Emulation===<br />
At the frontier of CRT shader development has been phosphor mask emulation. As stated previously, there are three overarching mask types: aperture grilles, shadow masks and slot masks. Aperture grilles were used primarily by Sony TVs, professional displays and PC monitors (with a few other brands such as Mitsubishi releasing their own version after Sony's Trinitron patent expired in the late 90's), shadow masks by the majority of PC CRT monitors from the late 80's onwards, and slot masks by just about every non-Sony consumer-level CRT TV, the vast majority of arcade monitors, and very early home computer/PC monitors. A key part of CRT emulation, then, depends on accurately replicating the look of these masks.<br />
<br />
However, even within each of these mask types, there is a lot of variance, as some CRTs were much sharper and were able to resolve a lot more detail than others. This is encapsulated in a specification known as TVL, or television lines, defined as the number of vertical white lines a mask can resolve along the horizontal dimension in a stretch equal to the height of the tube's viewable area (this means TVL is calculated by measuring the screen's height, then counting the number of resolved lines across a horizontal span equal to that height, not across the entire length of the screen). A higher TVL count is the result of higher phosphor density and results in a sharper, more detailed image, as well as more prominent scanlines in low-res content. Most consumer-level CRTs had a relatively low TVL count, whereas professional monitors such as Sony's PVM and BVM series had much higher TVL. In PC monitors, the usual specification to determine sharpness was instead dot pitch, or the distance between two phosphors of the same color. The lower the dot pitch, the sharper the monitor and the more detail it could resolve.<br />
<br />
Taking into account the three mask types and the variance in TVL and dot pitch, then, along with many other variables, it is no wonder no two CRTs looked alike.<br />
<br />
==External Links==<br />
*[http://filthypants.blogspot.com/2015/04/more-crt-shaders.html More CRT Shaders (filthypants.blogspot.com)] - hunterk's comparison of current CRT shaders. <br />
<br />
[[Category:FAQs]]<br />
[[Category:Shaders/Filters]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Nintendo_64_emulators&diff=48846Nintendo 64 emulators2022-07-26T09:03:42Z<p>GPDP1: Expanded info on m64p</p>
<hr />
<div>{{Infobox console<br />
|title = Nintendo 64<br />
|logo = Nintendo64Console.png<br />
|developer = [[:Nintendo]]<br />
|type = [[:Category:Home consoles|Home video game console]]<br />
|generation = [[:Category:Fifth-generation video game consoles|Fifth generation]]<br />
|release = 1996<br />
|discontinued = 2002<br />
|predecessor = [[Super Nintendo emulators|SNES]]<br />
|successor = [[GameCube emulators|GameCube]]<br />
|emulated = {{✓}}<br />
}}<br />
<br />
{{for|other emulators that run on N64 hardware|Emulators on N64}} <br />
<br />
<br />
The '''Nintendo 64''' is a 64-bit fifth-generation console released by Nintendo on September 29, 1996 for {{inflation|USD|199.99|1996}}.<br />
<br />
Nintendo was the second company approached by Silicon Graphics Inc. (SGI), who wanted to roll out their previously enterprise-only technology in the consumer space. They originally pitched their idea to Sega, but it's assumed that Nintendo's offer was more appealing. With the NEC VR4300 CPU clocked at 93.75 MHz, 4MB of RAM,<ref group=N>Though a separate add-on was later released called the "Expansion Pak" that added an additional 4MB of RAM, totaling 8MB.</ref> and an SGI RCP GPU, Nintendo had finalized much of the hardware at least a year before launch, preventing video games from needing drastic rewrites as a result of architectural changes. The development workstations were often Unix-based, something that would later help reverse engineers in some projects.<br />
<br />
==Emulators==<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Platform(s)<br />
! scope="col"|Latest version<br />
! scope="col"|Plugins<br />
! scope="col"|Controller Pak<br />
! scope="col"|Rumble Pak<br />
! scope="col"|Transfer Pak<br />
! scope="col"|64DD<br />
! scope="col"|Depth<br/>output<br />
! scope="col"|Texture<br/>enhancement<br />
! scope="col"|Netplay<br />
! scope="col"|[[libretro]]<br />
! scope="col"|<abbr title="Free/Libre and Open-Source Software">FLOSS</abbr><br />
! scope="col"|Active<br />
! scope="col"|[[Recommended emulators|Recommended]]<br />
|-<br />
!colspan="15"|PC / x86<br />
|-<br />
|[[m64p]] (ParaLLEl)<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/loganmc10/m64p/releases/latest git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}³<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|m64p (Final GLideN64)<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/loganmc10/m64p/releases/tag/v2021.5.30 Final GLideN64]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|Mupen64Plus-Next<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://www.retroarch.com/ git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}¹<br />
|{{✓}}<br />
|{{✓}}*<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[RMG]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/Rosalie241/RMG/releases {{RMGVer}}]<br >[https://github.com/Rosalie241/RMG/actions Dev]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Project64]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://www.pj64-emu.com/public-releases {{Project64Ver}}]<br >[https://www.pj64-emu.com/nightly-builds Dev]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[BizHawk]]<br />
|align=left|{{Icon|Windows}}<br />
|[http://tasvideos.org/BizHawk/ReleaseHistory.html {{BizHawkVer}}]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[ares]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/ares-emulator/ares/releases {{aresVer}}]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|{{~}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[CEN64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/tj90241/cen64 git]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://github.com/mupen64plus/mupen64plus-core/releases git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|ParaLLEl-N64<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://www.retroarch.com/ 2.0-rc2]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{✓}}*<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[Project64 Netplay]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://github.com/Project64Netplay/Project64-Netplay-2x git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[DaedalusX64]]<br />
|align=left|{{Icon|Linux}}<br />
|[https://github.com/DaedalusX64/daedalus/releases/latest git]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[1964]]<br />
|align=left|{{Icon|Windows}}<br />
|[http://www.emulation64.com/files/getfile/936/ 1.1] (Official)<br />[http://files.emulation64.fr/Emulateurs/EMU_1964_146.zip 1.2 r146] (Unofficial SVN)<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}⁴<br />
|-<br />
|[[Sixtyforce]]<br />
|align=left|{{Icon|macOS}}<br />
|[http://sixtyforce.com/download/ {{SixtyforceVer}}]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Larper64<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://drive.google.com/file/d/1IWyw5UG9Uf24KG0zrcXSFoOmcQoHWmyc/view {{Larper64Ver}}]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|[[UltraHLE]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://web.archive.org/web/20070312015944/http://www.emuunlim.com/UltraHLE/ultrahle.zip 1.0]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|[[MAME]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[http://www.mamedev.org/release.html {{MAMEVer}}]<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[Ryu64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/Ryu64Emulator/Ryu64 git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|R64Emu<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/rasky/r64emu git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
!colspan="15"|Mobile / ARM<br />
|-<br />
|[[Mupen64Plus]] FZ<br />
|align=left|{{Icon|Android}}<br />
|[https://play.google.com/store/apps/details?id=org.mupen64plusae.v3.fzurita 3.0.322 (beta)]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}¹<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Pandora|Pyra}}<br />
|[http://repo.openpandora.org/?page=detail&app=mupen64plus Pandora]<br/>[https://pyra-handheld.com/repo/apps/39 Pyra]<br />
|?<br />
|{{✓}}<br />
|?<br />
|?<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
!colspan="15"|Consoles<br />
|-<br />
|[[Virtual Console]]<br />
|align=left|{{Icon|Wii|WiiU}}<br />
|N/A<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Not64<br />
|align=left|{{Icon|GCN|Wii}}<br />
|[https://github.com/Extrems/Not64/releases/latest git]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|[[DaedalusX64]]<br />
|align=left|{{Icon|PSP|3DS}}<br>{{Icon|Vita|PS2}}<br />
|[https://github.com/DaedalusX64/daedalus/releases/latest PSP]<br/>[https://github.com/masterfeizz/DaedalusX64-3DS/releases 3DS]<br/>[https://github.com/Rinnegatamante/DaedalusX64-vitaGL/releases VitaGL]<br/>[https://www.ps2-home.com/forum/viewtopic.php?f=99&p=39957#p39957 PS2]<br />
|?<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}} <small>(PSP)</small><br />
|{{~}}<br />
|-<br />
|Surreal64 CE<br />
|align=left|{{Icon|Xbox}}<br />
|[https://digiex.net/threads/surreal64-ce-b6-0-download-n64-emulator-for-xbox.13677 Beta 6.0]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|mupen64-360<br />
|align=left|{{Icon|Xbox360}}<br />
|[https://digiex.net/threads/mupen64-360-xbox-360-nintendo-64-n64-emulator-download.9352 0.96 beta]<br />
|?<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|[https://code.google.com/p/mupen64gc/ Wii64]<br />
|align=left|{{Icon|GCN|Wii}}<br />
|[https://code.google.com/archive/p/mupen64gc/downloads 1.1 beta]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|}<br />
<br />
*<nowiki>* Available exclusively as a libretro core</nowiki><br />
*<nowiki>¹ Only supports texture packs, and not filtering or upscaling</nowiki><br />
*<nowiki>² Requires replacing the input plugin to one with netplay support</nowiki><br />
*<nowiki>³ If not using Netplay, use RMG</nowiki><br />
*<nowiki>⁴ Highly recommended to use 1964 GEPD for Goldeneye 007 or Perfect Dark</nowiki><br />
<br />
===Comparisons===<br />
Although many Nintendo 64 emulators have been made and many games can be run between them, until recently complete compatibility and/or accuracy left a bit to be desired. For half a decade, Mupen64Plus and Project64 have vied for the most playable emulator, and which was more compatible often depended on when and in what configuration each emulator has been tested. As of August 2017, both emulators have roughly equal compatibility and accuracy when running with the same [[recommended N64 plugins]] setup, though both default to Glide64, a now relatively lackluster plugin.<br />
<br />
;[[Mupen64Plus]]<br />
:A multi-platform emulator based on Hacktarux's Mupen64. It's about as accurate as Project64,<ref>loganmc10. [https://github.com/mupen64plus/mupen64plus-core/pull/336 ''Ignore TLB write if TLB entry is unmapping itself'']. "By the way, once this, along with the other PR's I have waiting are merged, we are at "compatibility parity" with Project64 as far as I can tell. I don't know of any game that doesn't boot with mupen64plus that works in PJ64."</ref> when both emulators are run with GLideN64. However, Mupen64Plus lacks a native GUI, instead being launched either from the command line or by dragging and dropping ROMs onto the executable and editing the config with a text editor. [[BizHawk]] and [[OpenEmu]] use forks of Mupen64Plus and its plugins for their N64 emulation, but they seem to be shallow. As of 2022 Project64-style overclocking for faster frame rates has been added under the option 'CountPerOpDenomPot'.<br />
<br />
:;Mupen64Plus-Next and ParaLLEl-N64<br />
:Both are heavily-modified forks developed as [[libretro]] cores. They introduce many features and optimizations not present in mainline alongside [[RetroArch]]'s general features, including 3-point texture filtering for Glide64, superior A/V sync and latency, and even an initially exclusive LLE Vulkan renderer based on Angrylion's pixel-perfect RDP plugin now known as ParaLLEl-RDP, making it a better alternative to the standalone version in some cases. 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.<br />
<br />
::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.<br />
<br />
:;[[m64p]]<br />
:A fork of Mupen64Plus with a custom-made Qt GUI. This is probably the easiest "out of the box" solution for Nintendo 64 emulation, as it comes bundled with ParaLLEl-RDP and ParaLLEl-RSP, ensuring both excellent compatibility and good speed without needing to mess with plugins or settings, provided your hardware supports Vulkan. However, unlike other emulators, it does not allow you to use other plugins. If GLideN64 is desired instead, there is an older build that retains it - unfortunately lacking the texture enhancement suite required for use of texture packs and upscaling. While it began as a shallow fork, it has increasingly become something closer to a hard fork, making various accuracy-focused changes to the emulation core that will require additional work to port back to upstream or to other forks.<br />
<br />
:;[[RMG]]<br />
:Rosalie's Mupen GUI is a project aiming to close the gap between Project64 and Mupen64Plus in terms of user experience. Its interface is about on par with m64p's in terms of cleanliness and ease of use, but unlike m64p, it allows you to use other plugins. The latest version comes bundled with GLideN64 and ParaLLEl-RDP for video plugins, and mupen64plus-hle-rsp and ParaLLEl-RSP for RSP plugins. However, for some reason it currently does not allow you access to ParaLLEl-RDP's options within its GUI, so if you wish to make use of features such as upscaling or downsampling, you must do so by editing the mupen64plus.cfg file, whereas m64p does expose these options in its GUI. However, if you prefer GLideN64, this is a superior alternative, as it does have access to its settings GUI, and the last version of m64p that uses GLideN64 is becoming increasingly outdated.<br />
<br />
:;Wii64 and Not64<br />
:Both are based on Mupen64, with Not64 being a fork of Wii64. Not64 claims to be better optimized 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 releases whenever possible.<br />
<br />
;[[Project64]]<br />
: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 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.<br />
<br />
;[[Ares]]<br />
:An open-source multi-system emulator and successor to Near's [[higan]] project, with a mostly original N64 core. Unlike other N64 emulators, it aims for high accuracy and does not employ HLE RSP or RDP emulation of any kind, not does it use game-specific hacks. It uses Themaister's ParaLLEl-RDP Vulkan renderer (with the MAME renderer as a software-based fallback) for pixel-perfect LLE graphics. While it is currently less compatible than Mupen64Plus or Project64, it is quickly catching up to them [https://ares-emu.net/compatibility/15 (only a handful of games are currently listed as partially or not working)], and it currently passes several stringent [https://github.com/ares-emulator/ares/pull/613 accuracy tests] the other emulators do not. However, it remains to be seen how accurate its developers are willing to make it without compromising speed and playability on current machines.<br />
<br />
;[[CEN64]]<br />
:Aims for cycle accuracy while at the same time aiming to eventually be usable on modern PC hardware. It lacks many features and has spotty compatibility, but it can already emulate some well-known edge cases such as picture recognition in Pokemon Snap. Unfortunately, its creator appears to have abandoned the project citing lack of satisfaction with his stated goal of fast cycle-accurate emulation, and development has all but stopped.<br />
<br />
;[[1964]]<br />
:Along with its various versions and forks, it was once a decent, speedy open-source alternative to Project64 and Mupen64, though it usually lagged behind the two compatibility-wise. Nowadays it has completely fallen off the radar as development has halted, and there is no longer a central code repo to speak of. There is little reason to use it nowadays outside of historical purposes, very specific edge cases, or if your device is too slow to run Mupen64Plus or Project64.<br />
<br />
;Daedalus<br />
:Is a Nintendo 64 emulator for PC which was ported to the PSP under the name of DaedalusX64. The PSP version later became the main version and got ported to platforms such as the Dreamcast, the PS2, the PS Vita, and the 3DS. On PSP, several games are able to reach full speed and most of them work with few emulation issues.<br />
<br />
;[[Sixtyforce]]<br />
:Is macOS-only, closed-source, and asks you to pay for full access to its features. It was once one of the only choices for Mac users, particularly those with older Macs since it's the only emulator with a <abbr title="Power PC">PPC</abbr> [[Dynamic recompilation|dynarec]]), but, with the switch to x86 and Mupen64Plus being ported to macOS, it has now become less relevant. However, development is still ongoing and is currently in its [https://sixtyforce.com/rosetta/ third rewrite] to support the upcoming [https://en.wikipedia.org/wiki/Apple-designed_processors Apple Silicon].<br />
<br />
;[[UltraHLE]]<br />
: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.<br />
<br />
;[[Ryu64]]<br />
:Is a Nintendo 64 emulator made in C#. The 'Ryu' word is named after the "RyuJIT" used in both Visual Basic & C#. But it might have been inspired by the lead author's sole (so far) [https://github.com/Ryujinx/Ryujinx/commits?author=Dudejoe870 commit] at Switch emulator, [[Ryujinx]]'s Git repository, and his depreciated [https://github.com/Dudejoe870/RyujinxAutoUpdate Ryujinx Auto Updater] tool. "86RYU", an x86 JIT compiler, is being developed alongside this emulator too.<br />
<br />
;n64oid<br />
:An Android exclusive Nintendo 64 emulator. It is similar to Project 64 1.6 in terms of compatibility, although it is unknown who authored it, as the APK for n64oid circulates on many legally questionable APK sites. n64oid has the infamous problem in Mario Kart 64 of the screen in Wario Stadium not displaying properly, as it displays nothing but black. It upscales all games to widescreen, which works well most of time, but on many phones it will have performance issues. The emulator is relatively poor, but it is much easier to set up than other options. The emulator features a menu with many similarities to the mobile edition of Snes9x EX+, and the My Boy! family of Android emulators for Game Boy systems.<br />
<br />
==Emulation issues==<br />
{{Main|Recommended N64 plugins}}<br />
<br />
Nintendo 64 emulation is now decent. A lot of the major problems that N64 emulation had in the past, have been fixed for quite some time now. The only catch is that the accurate emulators have higher system requirements. The main remaining problem is the lack of accurate cycle counting.<br />
<br />
===[[High/Low level emulation|High-level vs. low-level]] graphics===<br />
<br />
One of the biggest hurdles to emulating the Nintendo 64 was the Reality Display Processor (RDP), which used a custom design that had to be fine-tuned to get more performance out of the system using microcode. To emulate the RDP accurately, one would have to execute said microcode the way the RDP did, which differed from PC graphics cards of the day. To complicate matters further, API standards that were available on PCs two decades ago were nowhere near as flexible as they are today. If you wanted to make an accurate GPU-accelerated RDP plugin in 2003, you simply couldn't with the APIs of the time (OpenGL 1.x and Direct3D 9). For the average user, hardware-accurate GPU acceleration would be out of reach for a long time.<br />
<br />
[[UltraHLE]] offered a compromise. In contrast to earlier consoles, whose video chips in hindsight had been easy to render to the host CPU's framebuffer, performant RDP emulation had to take shortcuts, including programming around specific games' microcode to cleanly translate their graphics commands into API calls using Direct3D, OpenGL, and even Glide. With this, the theoretical system requirements plummeted, 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 is an improvement is subjective and a common point of discussion. Unfortunately it proved to be hit and miss, owing to the nature of per-game microcode detection and having to tweak settings to prevent some games from running into graphical glitches.<br />
<br />
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).<br />
<br />
On the high-level side, gonetz and one or two assistants spent a large portion of development improving GlideN64's microcode handling 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 framebuffer is used as well as performance issues), VI emulation, and how combine/blending modes are emulated (such as noise issues and combiner accuracy).<br />
<br />
<gallery widths="300" mode="packed"><br />
Majora's mask accurate.png| Low-level emulation of Majora's Mask using SoftGraphic<br />
Project64 2013-07-26 14-20-17-55.png| High-level emulation of Majora's Mask using Jabo's Direct3D<br />
</gallery><br />
<br />
===[[Texture filtering]]===<br />
The Nintendo 64 was the first consumer device to be able to filter textures when rendering 3D objects. However, unlike every console and PC graphics card made after the N64, its implementation of bilinear was primitive in that, in order to reduce strain on the system, it only used three samples as opposed to four, resulting in slightly jagged, asymmetrically-filtered textures. Instead of faithfully applying this "imperfect" version of bilinear filtering, HLE plugins instead applied conventional bilinear filtering, interpolating straight from the source texture up to the output resolution the same way a PC game would. While that method is technically superior, it can result in textures that look even blurrier than on real hardware.<br />
<br />
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 pre-rendered backgrounds or menu screens, may look as though they are separated into squares (see images below; note how OoT's Quest Status screen appears to be divided into a grid). 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 oftentimes low resolutions.<br />
<br />
Modern emulators and plugins have taken some steps which help remedy these problems. For instance, GLideN64 now supports N64-style three-point texture filtering, which results in a more faithful look. It is also capable of rendering at 320x240, which sidesteps the issues with filtered text, UI elements, and menu screens, while still retaining texture filtering. Pixel-accurate plugins such as Angrylion and ParaLLEl-RDP do not have these problems at all.<br />
<gallery widths="300" mode="packed"><br />
Project64_2013-06-26_17-44-58-31.png|Conker's Bad Fur Day copyright screen, displaying issues with filtered text.<br />
Mupen64plus_2013-08-18_20-35-50-08.png|Ocarina of Time's menu subscreen, displaying issues with filtering.</gallery><br />
<br />
===Timing issues===<br />
One of the biggest remaining problems in N64 emulation is lack of accurate core timings, which in practice means games do not always run at the speed they would on real hardware. While this technically affects all games, the majority are only affected to a negligible degree, and in some instances (particularly in Rare games) this can actually result in less framerate drops and lag, which can be seen as beneficial. However, some game engines actually depend on accurate timings for proper game behavior, and not properly emulating them can result in considerable to major issues. Some notable examples include the following:<br />
* Intros and cutscenes playing too fast and not properly syncing up with musical cues. Seen in Goldeneye's intro and Body Harvest's beginning cutscene.<br />
* Gameplay demos running at hyper speed. Earthworm Jim 3D is most notorious for this, though the main game itself is largely unaffected.<br />
* Game physics not working properly due to being tied to framerate. A good example is Donkey Kong 64, which is programmed to boost the character's speed and momentum proportional to in-game lag (most likely to make up for the game's frequent framerate drops), which can be exploited for certain glitches and sequence breaks on real hardware. Emulators currently run the game too well and with too little lag, making most of these tricks impossible to pull off.<br />
* Possibly the most affected game is Knife's Edge, which runs like it's on permanent fast-forward, making it all but unplayable. Messing with timing-related settings such as CounterFactor can mitigate this somewhat, but nowhere near enough to fix the issue.<br />
Fortunately, tackling these problems has recently become a core focus of development in some N64 emulators, and attempts are underway to improve the situation. Ares currently has the most accurate timings overall, and already runs Earthworm Jim 3D's demos much better than other emulators. Meanwhile, m64p has recently pushed various timing-related commits aimed at improving accuracy, and as a result it may now be the only emulator that runs Donkey Kong 64 properly. As these efforts progress, it should be noted that a side-effect of improved timings may be greater in-game lag. This should not be seen as the emulator becoming slower, but rather the emulator behaving exactly like real hardware does, as many N64 games were notorious for framerate drops.<br />
<br />
==Peripherals==<br />
===Voice Recognition Unit emulation===<br />
The Voice Recognition Unit (VRU) is an accessory used primarily by ''Hey You, Pikachu''. No emulator or input plugin supports this, although there is an on-going effort to get it working.<ref name="emutalk">{{cite web|url=http://www.emutalk.net/threads/55279|title=Hey You! Pikachu - Possible HLE Implementation|publisher=emutalk|accessdate=2018-06-17|date=2014-10-27, Last edit: 2016-04-04}}</ref><br />
===''Densha De Go!'' Controller===<br />
Also available for the [[PlayStation emulators|PlayStation]], ''Densha De Go! 64'' is a Japan-only train simulator released by [[Wikipedia:Taito|Taito]] that is compatible with an optional special controller that plugs into the player 3 port.<ref name="ArcadeUSA">{{cite web|url=https://www.youtube.com/watch?v=cCcPAGhcnck|title=Densha De Go! Nintendo 64 Controller!|publisher=YouTube|accessdate=2018-06-17|date=2017-01-20}}</ref> No emulator supports it.<br />
<br />
===Pokémon Snap Station===<br />
There was a special kiosk designed to promote ''Pokémon Snap'' called the ''Pokémon Snap Station'', which is also compatible with the North American ''Pokémon Stadium'' with its gallery mode. It is just a Nintendo 64 with special hardware designed for the station.<ref name="Sixty Formula">{{cite web|url=https://www.youtube.com/watch?v=AMbjvGvPkV4|title=The Pokemon Snap Station|publisher=YouTube|accessdate=2018-06-17|date=2016-05-21}}</ref><ref name="MetalJesusRocks">{{cite web|url=https://www.youtube.com/watch?v=5_UGpRN6AnM&t=3m35s|title=VIDEO GAME KIOSKS - Extreme Game Collecting!|publisher=YouTube|accessdate=2018-06-17|date=2016-05-25}}</ref> Although the special cartridge boots in emulators compatible with the regular version, the printing functions are inaccessible due to no emulation of the printer for the player 4 slot, credit system, or the special board to switch between the regular and special cartridges.<br />
<br />
===Transfer Pak emulation===<br />
A few games use the Transfer Pak such as ''Mario Golf'', ''Mario Tennis'', ''Mario Artist: Paint Studio'', and the ''Pokémon Stadium'' games. Mostly, this can be done with NRage's input plugin, but a couple of things aren't emulated:<br />
<br />
*Taking pictures with the Japanese ''Game Boy Camera'' (called ''Pocket Camera'') while in Transfer Pak mode playing ''Mario Artist: Paint Studio'' displays static.<br />
<br />
===64DD emulation===<br />
The 64DD (an abbreviation for "64 Disk Drive") was a peripheral which allowed a proprietary disk format to be used with the N64. These disks had more space at a cheaper manufacturing cost. The peripheral was a commercial failure and was never released outside of Japan. Internal evidence suggests that, much like the GBA e-Reader, it wasn't even intended for a European release.<br />
<br />
Expansion disks are region-coded to either Japan or the US (obviously unused) and won't work with N64 games from the wrong region. Only F-Zero X has full support for this feature, but dummied-out expansion data in Ocarina of Time and Mario Party 2 (JP/PAL) exist as well.<br />
<br />
The special AV-In cartridge (NUS-028) that ''Mario Artist: Talent Studio'' can use doesn't work because it requires an RCA cable signal.<br />
<br />
Recently, there has been an effort to emulate the 64DD, and now [[Project64]] and [[MAME]] can run several commercial 64DD games as part of its N64 emulator. This is being ported to [[CEN64]] with the help of [https://twitter.com/LuigiBlood LuigiBlood]. The latest newcomer is Mupen64Plus which is the base of other emulators such as [[m64p]] and [[RMG]].<br />
<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Platform(s)<br />
! scope="col"|Latest Version<br />
! scope="col"|N64 Mouse<br />
! scope="col"|64DD Emulation<br />
! scope="col"|Active<br />
! scope="col"|[[Recommended emulators|Recommended]]<br />
|-<br />
! colspan="7"|PC / x86<br />
|-<br />
|ParaLLEl<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://www.retroarch.com/ 2.0-rc2]<br />
|{{✓}}<br />
|Mid/High<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Project64]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://github.com/project64/project64 {{Project64Ver}}]<br >[https://64dd.org/downloads.html 64DD.org Builds]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[CEN64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/tj90241/cen64 git]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[m64p]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
||[https://github.com/loganmc10/m64p/releases git]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|{{✗}} (WIP)<br />
|-<br />
|[[MAME]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[http://www.mamedev.org/release.html {{MAMEVer}}]<br />
|{{✗}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|}<br />
<br />
* Project64's latest versions emulate the N64 mouse and can load Zoinkity's hacked 64DD cartridge conversions at playable speeds. You'll need to set every game to have 8MB of Memory by default manually. Games do not save, some need "32-bit engine" to be unchecked (like Talent Studio), and some (like Polygon Studio to fix models and Paint Studio to fix stamps) need the Angrylion GFX plugin rather than GlideN64, which does the job for the rest.<br />
**The 64DD hardware started to be emulated around 2.3's release with the help of [https://github.com/LuigiBlood LuigiBlood]. Saving works but in the form of NDR files. NDR files are copied versions of NDD images with save data included as to not write to the clean unaltered images. In order to play 64DD games in their original forms, 8MB of memory is still needed because the real hardware needed the Expansion Pak upgrade. The IPL is also needed.<br />
<br />
* MAME includes early basic 64DD emulation as well but is much slower. Disk images need to be in head/track format. See [https://github.com/Happy-yappH/ddconvert.git here] for more information. It does not currently support disk swapping or saving disk to files. Writes only update the copy in memory, and, once the MAME process ends, the changes are lost. Current usage: <code>mame n64dd -quickload disk -cart cart -nodrc</code> (both disk and cart are optional)<br />
<br />
* CEN64, like Project64, had 64DD emulation ported to it from MAME. However, it focuses on accuracy and plays much slower than other emulators, aside from the 64DD emulation itself is imperfect.<br />
<br />
==Hardware variants==<br />
===iQue Player emulation===<br />
Before the GBA, DS, and 3DS, Nintendo released a modified version of their Nintendo 64 system for the Chinese market, which was called the iQue Player, through their not-quite-subsidiary iQue. Fourteen games were translated into Simplified Chinese, including Sin and Punishment, Ocarina of Time (the Majora's Mask port was canceled), Super Mario 64, and others.<br />
<br />
Unlike the Chinese releases of their more recent systems and their games, iQue Player releases are regular N64 roms wrapped with several layers of encryption, as well as a ticket and signature system like that on Wii, DSi, 3DS, Wii U, and Switch. The Chinese ROM-hacking scene is very active though and has translated the Japanese regular N64 releases for many of these to their language already, which explains some of the Chinese ROMs floating for those. However, recently, almost all pieces of iQue Player software were decrypted to regular .z64 ROM format.<br />
<br />
Several of the Chinese game localizations already run on N64 emulators, but as some hardware features of the iQue Player are not yet supported, some games, as well as the system menu and features in games such as saving, do not work yet.<br />
<br />
===Aleck 64 arcade emulation===<br />
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). 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.<br />
<br />
The Aleck 64 ROMs were dumped, and Zoinkity is working on converting them to regular N64 ROMs (with controls remapped to N64 controller buttons). They generally require an 8MB Expansion Pak to run at all and 4K EEPROM to save settings and scores. The ones covered by these patches are:<br />
<br />
* Donchan Puzzle Hanabi de Doon!<br />
* Eleven Beat: World Tournament<br />
* Hi Pai Paradise<br />
* Hi Pai Paradise 2<br />
* Kuru Kuru Fever<br />
* Magical Tetris Challenge<br />
* Mayjinsen 3 / Meijin-Sen<br />
* Star Soldier: Vanishing Earth (also ported to N64)<br />
* Super Real Mahjong VS<br />
* Tower & Shaft<br />
* Vivid Dolls (official eroge game on a Nintendo console)<br />
<br />
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.<br />
<br />
The remaining ones from the system's library not yet covered are:<br />
* Rev Limit<br />
* Variant Schwanzer<br />
<br />
==Virtual Console games in Dolphin==<br />
A number of N64 games were released for the Wii's Virtual Console service throughout its lifespan. While the emulators at the heart of each Virtual Console title were of average accuracy (rather than using one generic emulator used for every game, each title had an emulator specifically tailored to that game), they were good enough to render the games in full playable capacity with few to no glaring errors. Many of these titles are emulated well through Dolphin, and for a good while, due to persistent long-standing inaccuracies in N64 emulators and plugins, this was the best way to emulate certain N64 games, particularly Pokemon Snap and Mario Tennis. The system requirements are much higher than running them on regular N64 emulators, but it's doable for many games. Today, regular N64 emulators and plugins have advanced to the degree that this has become unnecessary, relegating this method of N64 game emulation to little more than a curiosity, at least on PC.<br />
<br />
The following games are on the N64 Virtual Console for Wii:<br />
<br />
{|width="100%"<br />
|- valign="top"<br />
|<br />
* 1080 Snowboarding<br />
* Bomberman Hero<br />
* Cruis'n USA<br />
* Custom Robo V2 (Japan only)<br />
* F-Zero X<br />
* Kirby 64: The Crystal Stars<br />
* The Legend of Zelda: Majora's Mask<br />
* The Legend of Zelda: Ocarina of Time<br />
|<br />
* Mario Golf<br />
* Mario Kart 64<br />
* Mario Party 2<br />
* Mario Tennis<br />
* Ogre Battle 64: Person of Lordly Caliber<br />
* Paper Mario<br />
* Pokemon Puzzle League<br />
|<br />
* Pokemon Snap<br />
* Sin & Punishment (English)<br />
* Star Fox 64<br />
* Super Mario 64<br />
* Super Smash Bros.<br />
* Wave Race 64<br />
* Yoshi's Story<br />
|}<br />
<br />
==Notes==<br />
<references group=N /><br />
<br />
==References==<br />
<references/><br />
<br />
{{Nintendo}}<br />
<br />
[[Category:Consoles]]<br />
[[Category:Home consoles]]<br />
[[Category:Fifth-generation video game consoles]]<br />
[[Category:Nintendo consoles]]<br />
[[Category:Nintendo 64 emulators|*]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Nintendo_64_emulators&diff=48541Nintendo 64 emulators2022-07-18T22:48:02Z<p>GPDP1: Updated N64 timing issues section to reflect new developments</p>
<hr />
<div>{{Infobox console<br />
|title = Nintendo 64<br />
|logo = Nintendo64Console.png<br />
|developer = [[:Nintendo]]<br />
|type = [[:Category:Home consoles|Home video game console]]<br />
|generation = [[:Category:Fifth-generation video game consoles|Fifth generation]]<br />
|release = 1996<br />
|discontinued = 2002<br />
|predecessor = [[Super Nintendo emulators|SNES]]<br />
|successor = [[GameCube emulators|GameCube]]<br />
|emulated = {{✓}}<br />
}}<br />
<br />
{{for|other emulators that run on N64 hardware|Emulators on N64}} <br />
<br />
<br />
The '''Nintendo 64''' is a 64-bit fifth-generation console released by Nintendo on September 29, 1996 for {{inflation|USD|199.99|1996}}.<br />
<br />
Nintendo was the second company approached by Silicon Graphics Inc. (SGI), who wanted to roll out their previously enterprise-only technology in the consumer space. They originally pitched their idea to Sega, but it's assumed that Nintendo's offer was more appealing. With the NEC VR4300 CPU clocked at 93.75 MHz, 4MB of RAM,<ref group=N>Though a separate add-on was later released called the "Expansion Pak" that added an additional 4MB of RAM, totaling 8MB.</ref> and an SGI RCP GPU, Nintendo had finalized much of the hardware at least a year before launch, preventing video games from needing drastic rewrites as a result of architectural changes. The development workstations were often Unix-based, something that would later help reverse engineers in some projects.<br />
<br />
==Emulators==<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Platform(s)<br />
! scope="col"|Latest version<br />
! scope="col"|Plugins<br />
! scope="col"|Controller Pak<br />
! scope="col"|Rumble Pak<br />
! scope="col"|Transfer Pak<br />
! scope="col"|64DD<br />
! scope="col"|Depth<br/>output<br />
! scope="col"|Texture<br/>enhancement<br />
! scope="col"|Netplay<br />
! scope="col"|[[libretro]]<br />
! scope="col"|<abbr title="Free/Libre and Open-Source Software">FLOSS</abbr><br />
! scope="col"|Active<br />
! scope="col"|[[Recommended emulators|Recommended]]<br />
|-<br />
!colspan="15"|PC / x86<br />
|-<br />
|[[m64p]] (ParaLLEl)<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/loganmc10/m64p/releases/latest git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}³<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|m64p (Final GLideN64)<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/loganmc10/m64p/releases/tag/v2021.5.30 Final GLideN64]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|Mupen64Plus-Next<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://www.retroarch.com/ git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}¹<br />
|{{✓}}<br />
|{{✓}}*<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[RMG]]<br />
|align=left|{{Icon|Windows|Linux}}<br />
|[https://github.com/Rosalie241/RMG/releases {{RMGVer}}]<br >[https://github.com/Rosalie241/RMG/actions Dev]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Project64]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://www.pj64-emu.com/public-releases {{Project64Ver}}]<br >[https://www.pj64-emu.com/nightly-builds Dev]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[BizHawk]]<br />
|align=left|{{Icon|Windows}}<br />
|[http://tasvideos.org/BizHawk/ReleaseHistory.html {{BizHawkVer}}]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[ares]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/ares-emulator/ares/releases {{aresVer}}]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|{{~}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[CEN64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/tj90241/cen64 git]<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://github.com/mupen64plus/mupen64plus-core/releases git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|ParaLLEl-N64<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://www.retroarch.com/ 2.0-rc2]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{✓}}*<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|[[Project64 Netplay]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://github.com/Project64Netplay/Project64-Netplay-2x git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[DaedalusX64]]<br />
|align=left|{{Icon|Linux}}<br />
|[https://github.com/DaedalusX64/daedalus/releases/latest git]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[1964]]<br />
|align=left|{{Icon|Windows}}<br />
|[http://www.emulation64.com/files/getfile/936/ 1.1] (Official)<br />[http://files.emulation64.fr/Emulateurs/EMU_1964_146.zip 1.2 r146] (Unofficial SVN)<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{~}}²<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}⁴<br />
|-<br />
|[[Sixtyforce]]<br />
|align=left|{{Icon|macOS}}<br />
|[http://sixtyforce.com/download/ {{SixtyforceVer}}]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Larper64<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://drive.google.com/file/d/1IWyw5UG9Uf24KG0zrcXSFoOmcQoHWmyc/view {{Larper64Ver}}]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|[[UltraHLE]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://web.archive.org/web/20070312015944/http://www.emuunlim.com/UltraHLE/ultrahle.zip 1.0]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|[[MAME]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[http://www.mamedev.org/release.html {{MAMEVer}}]<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[Ryu64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/Ryu64Emulator/Ryu64 git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|R64Emu<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/rasky/r64emu git]<br />
|?<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
!colspan="15"|Mobile / ARM<br />
|-<br />
|[[Mupen64Plus]] FZ<br />
|align=left|{{Icon|Android}}<br />
|[https://play.google.com/store/apps/details?id=org.mupen64plusae.v3.fzurita 3.0.322 (beta)]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}¹<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Mupen64Plus]]<br />
|align=left|{{Icon|Pandora|Pyra}}<br />
|[http://repo.openpandora.org/?page=detail&app=mupen64plus Pandora]<br/>[https://pyra-handheld.com/repo/apps/39 Pyra]<br />
|?<br />
|{{✓}}<br />
|?<br />
|?<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
!colspan="15"|Consoles<br />
|-<br />
|[[Virtual Console]]<br />
|align=left|{{Icon|Wii|WiiU}}<br />
|N/A<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Not64<br />
|align=left|{{Icon|GCN|Wii}}<br />
|[https://github.com/Extrems/Not64/releases/latest git]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|[[DaedalusX64]]<br />
|align=left|{{Icon|PSP|3DS}}<br>{{Icon|Vita|PS2}}<br />
|[https://github.com/DaedalusX64/daedalus/releases/latest PSP]<br/>[https://github.com/masterfeizz/DaedalusX64-3DS/releases 3DS]<br/>[https://github.com/Rinnegatamante/DaedalusX64-vitaGL/releases VitaGL]<br/>[https://www.ps2-home.com/forum/viewtopic.php?f=99&p=39957#p39957 PS2]<br />
|?<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}} <small>(PSP)</small><br />
|{{~}}<br />
|-<br />
|Surreal64 CE<br />
|align=left|{{Icon|Xbox}}<br />
|[https://digiex.net/threads/surreal64-ce-b6-0-download-n64-emulator-for-xbox.13677 Beta 6.0]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|mupen64-360<br />
|align=left|{{Icon|Xbox360}}<br />
|[https://digiex.net/threads/mupen64-360-xbox-360-nintendo-64-n64-emulator-download.9352 0.96 beta]<br />
|?<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{~}}<br />
|-<br />
|[https://code.google.com/p/mupen64gc/ Wii64]<br />
|align=left|{{Icon|GCN|Wii}}<br />
|[https://code.google.com/archive/p/mupen64gc/downloads 1.1 beta]<br />
|?<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{?}}<br />
|{{?}}<br />
|{{?}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|}<br />
<br />
*<nowiki>* Available exclusively as a libretro core</nowiki><br />
*<nowiki>¹ Only supports texture packs, and not filtering or upscaling</nowiki><br />
*<nowiki>² Requires replacing the input plugin to one with netplay support</nowiki><br />
*<nowiki>³ If not using Netplay, use RMG</nowiki><br />
*<nowiki>⁴ Highly recommended to use 1964 GEPD for Goldeneye 007 or Perfect Dark</nowiki><br />
<br />
===Comparisons===<br />
Although many Nintendo 64 emulators have been made and many games can be run between them, until recently complete compatibility and/or accuracy left a bit to be desired. For half a decade, Mupen64Plus and Project64 have vied for the most playable emulator, and which was more compatible often depended on when and in what configuration each emulator has been tested. As of August 2017, both emulators have roughly equal compatibility and accuracy when running with the same [[recommended N64 plugins]] setup, though both default to Glide64, a now relatively lackluster plugin.<br />
<br />
;[[Mupen64Plus]]<br />
:A multi-platform emulator based on Hacktarux's Mupen64. It's about as accurate as Project64,<ref>loganmc10. [https://github.com/mupen64plus/mupen64plus-core/pull/336 ''Ignore TLB write if TLB entry is unmapping itself'']. "By the way, once this, along with the other PR's I have waiting are merged, we are at "compatibility parity" with Project64 as far as I can tell. I don't know of any game that doesn't boot with mupen64plus that works in PJ64."</ref> when both emulators are run with GLideN64. However, Mupen64Plus lacks a native GUI, instead being launched either from the command line or by dragging and dropping ROMs onto the executable and editing the config with a text editor. [[BizHawk]] and [[OpenEmu]] use forks of Mupen64Plus and its plugins for their N64 emulation, but they seem to be shallow. As of 2022 Project64-style overclocking for faster frame rates has been added under the option 'CountPerOpDenomPot'.<br />
<br />
:;Mupen64Plus-Next and ParaLLEl-N64<br />
:Both are heavily-modified forks developed as [[libretro]] cores. They introduce many features and optimizations not present in mainline alongside [[RetroArch]]'s general features, including 3-point texture filtering for Glide64, superior A/V sync and latency, and even an initially exclusive LLE Vulkan renderer based on Angrylion's pixel-perfect RDP plugin now known as ParaLLEl-RDP, making it a better alternative to the standalone version in some cases. 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.<br />
<br />
::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.<br />
<br />
:;[[m64p]]<br />
:Probably the easiest "out of the box" solution for Nintendo 64 emulation. In keeping with its theme of simplicity for the end user, it uses ParaLLEl-RDP and ParaLLEl-RSP for its video and RSP plugins, as well as its own custom GUI and input plugin, and unlike other emulators, it does not allow you to use anything else. If GLideN64 is desired instead, there is an older build that retains it - unfortunately lacking the texture enhancement suite required for use of texture packs and upscaling.<br />
<br />
:;[[RMG]]<br />
:Rosalie's Mupen GUI is a project aiming to close the gap between Project64 and Mupen64Plus in terms of user experience. Its interface is about on par with m64p's in terms of cleanliness and ease of use, but unlike m64p, it allows you to use other plugins. The latest version comes bundled with GLideN64 and ParaLLEl-RDP for video plugins, and mupen64plus-hle-rsp and ParaLLEl-RSP for RSP plugins. However, for some reason it currently does not allow you access to ParaLLEl-RDP's options within its GUI, so if you wish to make use of features such as upscaling or downsampling, you must do so by editing the mupen64plus.cfg file, whereas m64p does expose these options in its GUI. However, if you prefer GLideN64, this is a superior alternative, as it does have access to its settings GUI, and the last version of m64p that uses GLideN64 is becoming increasingly outdated.<br />
<br />
:;Wii64 and Not64<br />
:Both are based on Mupen64, with Not64 being a fork of Wii64. Not64 claims to be better optimized 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 releases whenever possible.<br />
<br />
;[[Project64]]<br />
: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 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.<br />
<br />
;[[Ares]]<br />
:An open-source multi-system emulator and successor to Near's [[higan]] project, with a mostly original N64 core. Unlike other N64 emulators, it aims for high accuracy and does not employ HLE RSP or RDP emulation of any kind, not does it use game-specific hacks. It uses Themaister's ParaLLEl-RDP Vulkan renderer (with Angrylion's MAME renderer as a software-based fallback) for pixel-perfect LLE graphics. While it is currently less compatible than Mupen64Plus or Project64, it is quickly catching up to them [https://github.com/ares-emulator/ares/issues/143 (only a handful of games are currently listed as partially or not working)], and it currently passes several stringent [https://github.com/ares-emulator/ares/pull/613 accuracy tests] the other emulators do not. However, it remains to be seen how accurate its developers are willing to make it without compromising speed and playability on current machines.<br />
<br />
;[[CEN64]]<br />
:Aims for cycle accuracy while at the same time aiming to eventually be usable on modern PC hardware. It lacks many features and has spotty compatibility, but it can already emulate some well-known edge cases such as picture recognition in Pokemon Snap. Unfortunately, its creator appears to have abandoned the project citing lack of satisfaction with his stated goal of fast cycle-accurate emulation, and development has all but stopped.<br />
<br />
;[[1964]]<br />
:Along with its various versions and forks, it was once a decent, speedy open-source alternative to Project64 and Mupen64, though it usually lagged behind the two compatibility-wise. Nowadays it has completely fallen off the radar as development has halted, and there is no longer a central code repo to speak of. There is little reason to use it nowadays outside of historical purposes, very specific edge cases, or if your device is too slow to run Mupen64Plus or Project64.<br />
<br />
;Daedalus<br />
:Is a Nintendo 64 emulator for PC which was ported to the PSP under the name of DaedalusX64. The PSP version later became the main version and got ported to platforms such as the Dreamcast, the PS2, the PS Vita, and the 3DS. On PSP, several games are able to reach full speed and most of them work with few emulation issues.<br />
<br />
;[[Sixtyforce]]<br />
:Is macOS-only, closed-source, and asks you to pay for full access to its features. It was once one of the only choices for Mac users, particularly those with older Macs since it's the only emulator with a <abbr title="Power PC">PPC</abbr> [[Dynamic recompilation|dynarec]]), but, with the switch to x86 and Mupen64Plus being ported to macOS, it has now become less relevant. However, development is still ongoing and is currently in its [https://sixtyforce.com/rosetta/ third rewrite] to support the upcoming [https://en.wikipedia.org/wiki/Apple-designed_processors Apple Silicon].<br />
<br />
;[[UltraHLE]]<br />
: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.<br />
<br />
;[[Ryu64]]<br />
:Is a Nintendo 64 emulator made in C#. The 'Ryu' word is named after the "RyuJIT" used in both Visual Basic & C#. But it might have been inspired by the lead author's sole (so far) [https://github.com/Ryujinx/Ryujinx/commits?author=Dudejoe870 commit] at Switch emulator, [[Ryujinx]]'s Git repository, and his depreciated [https://github.com/Dudejoe870/RyujinxAutoUpdate Ryujinx Auto Updater] tool. "86RYU", an x86 JIT compiler, is being developed alongside this emulator too.<br />
<br />
;n64oid<br />
:An Android exclusive Nintendo 64 emulator. It is similar to Project 64 1.6 in terms of compatibility, although it is unknown who authored it, as the APK for n64oid circulates on many legally questionable APK sites. n64oid has the infamous problem in Mario Kart 64 of the screen in Wario Stadium not displaying properly, as it displays nothing but black. It upscales all games to widescreen, which works well most of time, but on many phones it will have performance issues. The emulator is relatively poor, but it is much easier to set up than other options. The emulator features a menu with many similarities to the mobile edition of Snes9x EX+, and the My Boy! family of Android emulators for Game Boy systems.<br />
<br />
==Emulation issues==<br />
{{Main|Recommended N64 plugins}}<br />
<br />
Nintendo 64 emulation is now decent. A lot of the major problems that N64 emulation had in the past, have been fixed for quite some time now. The only catch is that the accurate emulators have higher system requirements. The main remaining problem is the lack of accurate cycle counting.<br />
<br />
===[[High/Low level emulation|High-level vs. low-level]] graphics===<br />
<br />
One of the biggest hurdles to emulating the Nintendo 64 was the Reality Display Processor (RDP), which used a custom design that had to be fine-tuned to get more performance out of the system using microcode. To emulate the RDP accurately, one would have to execute said microcode the way the RDP did, which differed from PC graphics cards of the day. To complicate matters further, API standards that were available on PCs two decades ago were nowhere near as flexible as they are today. If you wanted to make an accurate GPU-accelerated RDP plugin in 2003, you simply couldn't with the APIs of the time (OpenGL 1.x and Direct3D 9). For the average user, hardware-accurate GPU acceleration would be out of reach for a long time.<br />
<br />
[[UltraHLE]] offered a compromise. In contrast to earlier consoles, whose video chips in hindsight had been easy to render to the host CPU's framebuffer, performant RDP emulation had to take shortcuts, including programming around specific games' microcode to cleanly translate their graphics commands into API calls using Direct3D, OpenGL, and even Glide. With this, the theoretical system requirements plummeted, 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 is an improvement is subjective and a common point of discussion. Unfortunately it proved to be hit and miss, owing to the nature of per-game microcode detection and having to tweak settings to prevent some games from running into graphical glitches.<br />
<br />
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).<br />
<br />
On the high-level side, gonetz and one or two assistants spent a large portion of development improving GlideN64's microcode handling 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 framebuffer is used as well as performance issues), VI emulation, and how combine/blending modes are emulated (such as noise issues and combiner accuracy).<br />
<br />
<gallery widths="300" mode="packed"><br />
Majora's mask accurate.png| Low-level emulation of Majora's Mask using SoftGraphic<br />
Project64 2013-07-26 14-20-17-55.png| High-level emulation of Majora's Mask using Jabo's Direct3D<br />
</gallery><br />
<br />
===[[Texture filtering]]===<br />
The Nintendo 64 was the first consumer device to be able to filter textures when rendering 3D objects. However, unlike every console and PC graphics card made after the N64, its implementation of bilinear was primitive in that, in order to reduce strain on the system, it only used three samples as opposed to four, resulting in slightly jagged, asymmetrically-filtered textures. Instead of faithfully applying this "imperfect" version of bilinear filtering, HLE plugins instead applied conventional bilinear filtering, interpolating straight from the source texture up to the output resolution the same way a PC game would. While that method is technically superior, it can result in textures that look even blurrier than on real hardware.<br />
<br />
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 pre-rendered backgrounds or menu screens, may look as though they are separated into squares (see images below; note how OoT's Quest Status screen appears to be divided into a grid). 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 oftentimes low resolutions.<br />
<br />
Modern emulators and plugins have taken some steps which help remedy these problems. For instance, GLideN64 now supports N64-style three-point texture filtering, which results in a more faithful look. It is also capable of rendering at 320x240, which sidesteps the issues with filtered text, UI elements, and menu screens, while still retaining texture filtering. Pixel-accurate plugins such as Angrylion and ParaLLEl-RDP do not have these problems at all.<br />
<gallery widths="300" mode="packed"><br />
Project64_2013-06-26_17-44-58-31.png|Conker's Bad Fur Day copyright screen, displaying issues with filtered text.<br />
Mupen64plus_2013-08-18_20-35-50-08.png|Ocarina of Time's menu subscreen, displaying issues with filtering.</gallery><br />
<br />
===Timing issues===<br />
One of the biggest remaining problems in N64 emulation is lack of accurate core timings, which in practice means games do not always run at the speed they would on real hardware. While this technically affects all games, the majority are only affected to a negligible degree, and in some instances (particularly in Rare games) this can actually result in less framerate drops and lag, which can be seen as beneficial. However, some game engines actually depend on accurate timings for proper game behavior, and not properly emulating them can result in considerable to major issues. Some notable examples include the following:<br />
* Intros and cutscenes playing too fast and not properly syncing up with musical cues. Seen in Goldeneye's intro and Body Harvest's beginning cutscene.<br />
* Gameplay demos running at hyper speed. Earthworm Jim 3D is most notorious for this, though the main game itself is largely unaffected.<br />
* Game physics not working properly due to being tied to framerate. A good example is Donkey Kong 64, which is programmed to boost the character's speed and momentum proportional to in-game lag (most likely to make up for the game's frequent framerate drops), which can be exploited for certain glitches and sequence breaks on real hardware. Emulators currently run the game too well and with too little lag, making most of these tricks impossible to pull off.<br />
* Possibly the most affected game is Knife's Edge, which runs like it's on permanent fast-forward, making it all but unplayable. Messing with timing-related settings such as CounterFactor can mitigate this somewhat, but nowhere near enough to fix the issue.<br />
Fortunately, tackling these problems has recently become a core focus of development in some N64 emulators, and attempts are underway to improve the situation. Ares currently has the most accurate timings overall, and already runs Earthworm Jim 3D's demos much better than other emulators. Meanwhile, m64p has recently pushed various timing-related commits aimed at improving accuracy, and as a result it may now be the only emulator that runs Donkey Kong 64 properly. As these efforts progress, it should be noted that a side-effect of improved timings may be greater in-game lag. This should not be seen as the emulator becoming slower, but rather the emulator behaving exactly like real hardware does, as many N64 games were notorious for framerate drops.<br />
<br />
==Peripherals==<br />
===Voice Recognition Unit emulation===<br />
The Voice Recognition Unit (VRU) is an accessory used primarily by ''Hey You, Pikachu''. No emulator or input plugin supports this, although there is an on-going effort to get it working.<ref name="emutalk">{{cite web|url=http://www.emutalk.net/threads/55279|title=Hey You! Pikachu - Possible HLE Implementation|publisher=emutalk|accessdate=2018-06-17|date=2014-10-27, Last edit: 2016-04-04}}</ref><br />
===''Densha De Go!'' Controller===<br />
Also available for the [[PlayStation emulators|PlayStation]], ''Densha De Go! 64'' is a Japan-only train simulator released by [[Wikipedia:Taito|Taito]] that is compatible with an optional special controller that plugs into the player 3 port.<ref name="ArcadeUSA">{{cite web|url=https://www.youtube.com/watch?v=cCcPAGhcnck|title=Densha De Go! Nintendo 64 Controller!|publisher=YouTube|accessdate=2018-06-17|date=2017-01-20}}</ref> No emulator supports it.<br />
<br />
===Pokémon Snap Station===<br />
There was a special kiosk designed to promote ''Pokémon Snap'' called the ''Pokémon Snap Station'', which is also compatible with the North American ''Pokémon Stadium'' with its gallery mode. It is just a Nintendo 64 with special hardware designed for the station.<ref name="Sixty Formula">{{cite web|url=https://www.youtube.com/watch?v=AMbjvGvPkV4|title=The Pokemon Snap Station|publisher=YouTube|accessdate=2018-06-17|date=2016-05-21}}</ref><ref name="MetalJesusRocks">{{cite web|url=https://www.youtube.com/watch?v=5_UGpRN6AnM&t=3m35s|title=VIDEO GAME KIOSKS - Extreme Game Collecting!|publisher=YouTube|accessdate=2018-06-17|date=2016-05-25}}</ref> Although the special cartridge boots in emulators compatible with the regular version, the printing functions are inaccessible due to no emulation of the printer for the player 4 slot, credit system, or the special board to switch between the regular and special cartridges.<br />
<br />
===Transfer Pak emulation===<br />
A few games use the Transfer Pak such as ''Mario Golf'', ''Mario Tennis'', ''Mario Artist: Paint Studio'', and the ''Pokémon Stadium'' games. Mostly, this can be done with NRage's input plugin, but a couple of things aren't emulated:<br />
<br />
*Taking pictures with the Japanese ''Game Boy Camera'' (called ''Pocket Camera'') while in Transfer Pak mode playing ''Mario Artist: Paint Studio'' displays static.<br />
<br />
===64DD emulation===<br />
The 64DD (an abbreviation for "64 Disk Drive") was a peripheral which allowed a proprietary disk format to be used with the N64. These disks had more space at a cheaper manufacturing cost. The peripheral was a commercial failure and was never released outside of Japan. Internal evidence suggests that, much like the GBA e-Reader, it wasn't even intended for a European release.<br />
<br />
Expansion disks are region-coded to either Japan or the US (obviously unused) and won't work with N64 games from the wrong region. Only F-Zero X has full support for this feature, but dummied-out expansion data in Ocarina of Time and Mario Party 2 (JP/PAL) exist as well.<br />
<br />
The special AV-In cartridge (NUS-028) that ''Mario Artist: Talent Studio'' can use doesn't work because it requires an RCA cable signal.<br />
<br />
Recently, there has been an effort to emulate the 64DD, and now [[Project64]] and [[MAME]] can run several commercial 64DD games as part of its N64 emulator. This is being ported to [[CEN64]] with the help of [https://twitter.com/LuigiBlood LuigiBlood]. The latest newcomer is Mupen64Plus which is the base of other emulators such as [[m64p]] and [[RMG]].<br />
<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Platform(s)<br />
! scope="col"|Latest Version<br />
! scope="col"|N64 Mouse<br />
! scope="col"|64DD Emulation<br />
! scope="col"|Active<br />
! scope="col"|[[Recommended emulators|Recommended]]<br />
|-<br />
! colspan="7"|PC / x86<br />
|-<br />
|ParaLLEl<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[https://www.retroarch.com/ 2.0-rc2]<br />
|{{✓}}<br />
|Mid/High<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[Project64]]<br />
|align=left|{{Icon|Windows}}<br />
|[https://github.com/project64/project64 {{Project64Ver}}]<br >[https://64dd.org/downloads.html 64DD.org Builds]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|[[CEN64]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
|[https://github.com/tj90241/cen64 git]<br />
|{{✓}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|[[m64p]]<br />
|align=left|{{Icon|Windows|Linux|macOS}}<br />
||[https://github.com/loganmc10/m64p/releases git]<br />
|{{✓}}<br />
|?<br />
|{{✓}}<br />
|{{✗}} (WIP)<br />
|-<br />
|[[MAME]]<br />
|align=left|{{Icon|Windows|Linux|macOS|FreeBSD}}<br />
|[http://www.mamedev.org/release.html {{MAMEVer}}]<br />
|{{✗}}<br />
|Mid<br />
|{{✓}}<br />
|{{✗}}<br />
|}<br />
<br />
* Project64's latest versions emulate the N64 mouse and can load Zoinkity's hacked 64DD cartridge conversions at playable speeds. You'll need to set every game to have 8MB of Memory by default manually. Games do not save, some need "32-bit engine" to be unchecked (like Talent Studio), and some (like Polygon Studio to fix models and Paint Studio to fix stamps) need the Angrylion GFX plugin rather than GlideN64, which does the job for the rest.<br />
**The 64DD hardware started to be emulated around 2.3's release with the help of [https://github.com/LuigiBlood LuigiBlood]. Saving works but in the form of NDR files. NDR files are copied versions of NDD images with save data included as to not write to the clean unaltered images. In order to play 64DD games in their original forms, 8MB of memory is still needed because the real hardware needed the Expansion Pak upgrade. The IPL is also needed.<br />
<br />
* MAME includes early basic 64DD emulation as well but is much slower. Disk images need to be in head/track format. See [https://github.com/Happy-yappH/ddconvert.git here] for more information. It does not currently support disk swapping or saving disk to files. Writes only update the copy in memory, and, once the MAME process ends, the changes are lost. Current usage: <code>mame n64dd -quickload disk -cart cart -nodrc</code> (both disk and cart are optional)<br />
<br />
* CEN64, like Project64, had 64DD emulation ported to it from MAME. However, it focuses on accuracy and plays much slower than other emulators, aside from the 64DD emulation itself is imperfect.<br />
<br />
==Hardware variants==<br />
===iQue Player emulation===<br />
Before the GBA, DS, and 3DS, Nintendo released a modified version of their Nintendo 64 system for the Chinese market, which was called the iQue Player, through their not-quite-subsidiary iQue. Fourteen games were translated into Simplified Chinese, including Sin and Punishment, Ocarina of Time (the Majora's Mask port was canceled), Super Mario 64, and others.<br />
<br />
Unlike the Chinese releases of their more recent systems and their games, iQue Player releases are regular N64 roms wrapped with several layers of encryption, as well as a ticket and signature system like that on Wii, DSi, 3DS, Wii U, and Switch. The Chinese ROM-hacking scene is very active though and has translated the Japanese regular N64 releases for many of these to their language already, which explains some of the Chinese ROMs floating for those. However, recently, almost all pieces of iQue Player software were decrypted to regular .z64 ROM format.<br />
<br />
Several of the Chinese game localizations already run on N64 emulators, but as some hardware features of the iQue Player are not yet supported, some games, as well as the system menu and features in games such as saving, do not work yet.<br />
<br />
===Aleck 64 arcade emulation===<br />
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). 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.<br />
<br />
The Aleck 64 ROMs were dumped, and Zoinkity is working on converting them to regular N64 ROMs (with controls remapped to N64 controller buttons). They generally require an 8MB Expansion Pak to run at all and 4K EEPROM to save settings and scores. The ones covered by these patches are:<br />
<br />
* Donchan Puzzle Hanabi de Doon!<br />
* Eleven Beat: World Tournament<br />
* Hi Pai Paradise<br />
* Hi Pai Paradise 2<br />
* Kuru Kuru Fever<br />
* Magical Tetris Challenge<br />
* Mayjinsen 3 / Meijin-Sen<br />
* Star Soldier: Vanishing Earth (also ported to N64)<br />
* Super Real Mahjong VS<br />
* Tower & Shaft<br />
* Vivid Dolls (official eroge game on a Nintendo console)<br />
<br />
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.<br />
<br />
The remaining ones from the system's library not yet covered are:<br />
* Rev Limit<br />
* Variant Schwanzer<br />
<br />
==Virtual Console games in Dolphin==<br />
A number of N64 games were released for the Wii's Virtual Console service throughout its lifespan. While the emulators at the heart of each Virtual Console title were of average accuracy (rather than using one generic emulator used for every game, each title had an emulator specifically tailored to that game), they were good enough to render the games in full playable capacity with few to no glaring errors. Many of these titles are emulated well through Dolphin, and for a good while, due to persistent long-standing inaccuracies in N64 emulators and plugins, this was the best way to emulate certain N64 games, particularly Pokemon Snap and Mario Tennis. The system requirements are much higher than running them on regular N64 emulators, but it's doable for many games. Today, regular N64 emulators and plugins have advanced to the degree that this has become unnecessary, relegating this method of N64 game emulation to little more than a curiosity, at least on PC.<br />
<br />
The following games are on the N64 Virtual Console for Wii:<br />
<br />
{|width="100%"<br />
|- valign="top"<br />
|<br />
* 1080 Snowboarding<br />
* Bomberman Hero<br />
* Cruis'n USA<br />
* Custom Robo V2 (Japan only)<br />
* F-Zero X<br />
* Kirby 64: The Crystal Stars<br />
* The Legend of Zelda: Majora's Mask<br />
* The Legend of Zelda: Ocarina of Time<br />
|<br />
* Mario Golf<br />
* Mario Kart 64<br />
* Mario Party 2<br />
* Mario Tennis<br />
* Ogre Battle 64: Person of Lordly Caliber<br />
* Paper Mario<br />
* Pokemon Puzzle League<br />
|<br />
* Pokemon Snap<br />
* Sin & Punishment (English)<br />
* Star Fox 64<br />
* Super Mario 64<br />
* Super Smash Bros.<br />
* Wave Race 64<br />
* Yoshi's Story<br />
|}<br />
<br />
==Notes==<br />
<references group=N /><br />
<br />
==References==<br />
<references/><br />
<br />
{{Nintendo}}<br />
<br />
[[Category:Consoles]]<br />
[[Category:Home consoles]]<br />
[[Category:Fifth-generation video game consoles]]<br />
[[Category:Nintendo consoles]]<br />
[[Category:Nintendo 64 emulators|*]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Recommended_N64_plugins&diff=48525Recommended N64 plugins2022-07-17T22:01:55Z<p>GPDP1: Added an Overview section explaining the "profiles" under Recommended Setups</p>
<hr />
<div>The N64 emulation scene had previously been described as a broken mess, the very definition of plugin hell. With recent developments in the scene, however, the situation has markedly improved, and it is no longer considered necessary to have multiple emulators and plugins on hand to get most games to work. This page will outline the best plugins currently available for the benefit of both the casual and enthusiast looking to get their N64 emulation fix.<br />
<br />
==The Plugin Specs==<br />
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.<br />
<br />
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.<br />
<br />
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. Unsurprisingly, this situation often led to a lot of confusion from users, who often wondered why there were so many plugins, and which ones were the best to use, only to find out it often depended on the game, and even then, some games would refuse to work as intended no matter what was tried. Hence the label "plugin hell" was coined, and stuck as a description of the travails of trying to emulate N64 games well into the 2010's.<br />
<br />
However, as time went on, things began to change, though 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.<br />
<br />
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 changes and 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) video plugin there is but was initially only available for the zilmar spec, was ported to Mupen64Plus and integrated into 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.<br />
<br />
All that said, the issue is that there are now three plugin standards to account for:<br />
<br />
*The zilmar spec - Utilized by Project64 and most other legacy emulators; only Project64 still uses it today.*<br />
<br />
*The Mupen64Plus spec - Utilized by Mupen64Plus and most of its forks.<br />
<br />
*Libretro - Not really a spec per se, as the plugins are integrated directly into the libretro core, so there's no DLL files to download or add.<br />
<br />
As of right now, not all plugins are readily available on all three. Consult the tables below for reference:<br />
<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Latest Version<br />
! scope="col"|Project64<br />
! scope="col"|Mupen64Plus<br />
! scope="col"|Libretro<br />
! scope="col"|HLE<br />
! scope="col"|LLE<br />
! scope="col"|Widescreen Hack<br />
! scope="col"|Custom Texture Packs<br />
! scope="col"|Recommended<br />
|-<br />
!colspan="13"|Video Plugins<br />
|-<br />
|ParaLLEl-RDP<br />
|[https://github.com/Themaister/parallel-rdp git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|GLideN64<br />
|[https://github.com/gonetz/GLideN64/releases/tag/github-actions github-actions]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Angrylion RDP Plus<br />
|[https://github.com/ata4/angrylion-rdp-plus/releases/tag/v1.6 1.6]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|Glide64**<br />
|Final<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|Jabo's Direct3D8<br />
|1.7.0.57-ver5<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Rice Video<br />
|0.4.4<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|glN64<br />
|0.4.1<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|z64gl<br />
|R17<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Angrylion (Official)<br />
|r114<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|}<br />
<br />
<nowiki>*</nowiki>It should be noted that Project64 after version 2.x made some changes to the zilmar plugin spec, and while it remains backwards compatible with the older version of the spec (meaning most older plugins will still work with Project64), plugins targeting the newer version will not work on older versions of Project64 or other zilmar spec-based emulators.<br />
<br />
<nowiki>**</nowiki>Funnily enough, Glide64 actually DOES have LLE code (much of it apparently comes from z64gl) and can technically run in LLE mode by using it alongside an LLE RSP plugin such as CXD4. However, it is not a complete implementation, and actually trying to run it in such a mode results in massive visual glitches, making it unusable. Practically speaking, then, Glide64 cannot be considered a true LLE plugin, and will not be designated as such, nor was it ever meant to be.<br />
<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Latest Version<br />
! scope="col"|Project64<br />
! scope="col"|Mupen64Plus<br />
! scope="col"|Libretro<br />
! scope="col"|HLE Compatible*<br />
! scope="col"|LLE Compatible*<br />
! scope="col"|Recommended<br />
|-<br />
!colspan="13"|RSP Plugins<br />
|-<br />
|Zilmar's RSP<br />
|1.7<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Mupen64Plus HLE RSP<br />
|[https://github.com/mupen64plus/mupen64plus-rsp-hle git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|Static Interpreter/CXD4<br />
|[https://github.com/cxd4/rsp git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|ParaLLEl-RSP<br />
|[https://github.com/Themaister/parallel-rsp git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Mupen64 HLE RSP<br />
|0.5.1<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|z64<br />
|r17<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|}<br />
<br />
<nowiki>*</nowiki>These terms signify whether an RSP plugin can work alongside HLE and/or LLE audio and video plugins. As for the type of emulation employed by the RSP plugins themselves, all but the Mupen64/plus HLE RSP plugins are LLE in nature. The LLE RSP plugins that can work with HLE plugins do so by passing the N64 display and audio lists onto the plugins themselves.<br />
<br />
==Video==<br />
===Currently Recommended Plugins===<br />
The following are the current best video plugins for use on modern PCs and devices.<br />
[[File:SuperMario64-Comparison.png|thumb|right|Jabo's Direct3D8 (left) compared with angrylion's RDP with OpenGL (right), while playing ''Super Mario 64''.]]<br />
====[https://github.com/Themaister/parallel-rdp ParaLLEl-RDP]====<br />
An LLE video plugin inspired by and referenced against Angrylion's RDP plugin, 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 several forks of Mupen64Plus and Project64, such as [[m64p]] and [https://www.64dd.org/downloads.html this build] of Project64. This is currently considered the best video plugin by most measures. It is almost 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 can also render at a high resolution and downsample back down to a lower one, should one wish to improve the 3D graphics without making them stick out from the often low-res 2D elements. Due to its LLE nature, it does not support widescreen hacks or high-res textures - try GLideN64 if you seek to use such features.<br />
<br />
System requirements for ParaLLEl-RDP are higher than for the other plugins. It requires a GPU with Vulkan support and up-to-date drivers (most Nvidia and AMD GPUs made after 2012 should be covered, though Intel graphics requires Skylake or newer), and upscaling increases the GPU requirements even further, far more than GLideN64. It must also be used in conjunction with an LLE RSP plugin, preferably its sister plugin ParaLLEl-RSP, as it features a recompiler for added speed. At native resolution, however, a modest PC with Vulkan support can handle it without much issue, even on integrated graphics.<br />
<br />
====[https://github.com/gonetz/GLideN64/ GLideN64]====<br />
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 z64gl and, 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 emulation of every game, gamma correction, flat and prim shading, VI emulation, and LLE graphics support. 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]], MSAA 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]].<br />
<br />
GLideN64 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.<br />
<br />
====[https://github.com/ata4/angrylion-rdp-plus/releases Angrylion RDP Plus]====<br />
This is a fork of Angrylion's RDP that supports multithreading. It 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, as does using it alongside an RSP plugin with a recompiler such as ParaLLEl-RSP, but some games are still not full speed even on a Core i7-8700K. It also allows you to disable VI filters for slightly better performance. This fork has at least one accuracy regression compared to the official version of Angrylion. 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.<br />
<br />
====Glide64====<br />
The former best general-use plugin. Versions of this are included in Project64, mainline Mupen64Plus, and the ParaLLEl-N64 libretro core. While it is no longer updated and is far less accurate and compatible than the newer offerings, it still has a few use cases, such as better support for older ROM hacks. It works relatively well for many (most?) games, has support for hi-res textures, and it is also faster than the newer plugins, which makes it suitable for slower devices such as the older Raspberry Pis. Otherwise, to ensure the highest possible compatibility, stick to either ParaLLEl-RDP or GLideN64.<br />
<br />
Note that the Project64 version of Glide64 has been renamed to Project64 Video and has undergone some changes and rewrites since it was initially forked, and thus may contain regressions compared to the last official standalone release of the plugin by Gonetz. Since this fork only works with current versions of Project64, should you wish to use this plugin on an older zilmar-spec emulator like 1964 or the original Mupen64, or if you want to avoid potential regressions with the Project64 version, use [https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/glidehqplusglitch64/Glide64_Final.zip Glide64 Final] instead.<br />
<br />
===Deprecated Plugins===<br />
The following video plugins are old and deprecated, and should not be used or considered unless you have a VERY old or underpowered device that cannot handle the recommended plugins, or there's a very specific use case not covered by modern implementations.<br />
<br />
*Jabo's Direct3D8 - Comes with Project64, and was once its default video plugin. Very speedy, has built-in AA and AF options, and includes a [[Widescreen_Hack|widescreen hack]]. The version included with the most recent versions of Project64 (1.7.0.57-ver5) is somewhat buggy and has regressions, however. [http://www.jabosoft.com/articles/114 Jabo's 1.6.1 patch] is better, though version 1.7 can run in LLE mode, which can help with a few games. Sadly, it will likely never see another update again, and though it is still included in Project64 to this day, it is no longer the default, and should not be used unless you have a very old PC that cannot handle Glide64 or GLideN64.<br />
*[http://www.emutalk.net/threads/54166-Rice-Video-Community-version Rice Video] - A very fast, highly configurable video plugin primarily based around the Direct3D API. It was once famous for being the first plugin that allowed the user to load [[Texture_Packs|custom hi-res textures]], which made 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, all aiming to fix issues or add features (one fork even featured early shader support), and forks of it are included in mainline Mupen64Plus and in the ParaLLEl-N64 libretro core. However, even during its heyday it lagged behind Glide64 and even Jabo in both compatibility and accuracy, and once Glide64 gained the ability to load custom textures, there remained little reason to use it beyond its speed. A "Community Version" popped up that aimed at improving it and fixing its issues, but it ended up introducing many regressions compared to older versions and the effort was eventually abandoned. 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) or are trying to emulate on a very old and/or severely underpowered PC or handheld device. If you are absolutely resolved to try it out, seek out the original versions by Rice, primarily 6.1.0 or 6.1.1b, and stick to the Direct3D renderer, as the OpenGL backend included in some versions is buggy and incomplete outside of the Mupen64Plus fork.<br />
*[http://www.emutalk.net/threads/40640-Z64-a-LLE-graphics-plugin z64gl] - A hardware-rendered, low-level plugin developed by ziggy, derived from MAME's N64 driver. A fork is maintained by the Mupen64Plus team, though not included in their official releases. It was once notable for being one of the only plugins that could play games without an HLE microcode implementation such as Rogue Squadron. However, it was rather glitchy, had higher system requirements than the HLE plugins, needed an LLE RSP plugin to work (such as the bundled z64 RSP or Project64's RSP plugin set to LLE graphics), and configuration required editing the config file directly. A [https://github.com/purplemarshmallow/z64/tree/angrylion-integration fork] cropped up that aimed at improving it, but it did not get very far. Nowadays, it's obsolete, as GLideN64 can now play every game through HLE (thus subverting z64gl's only selling point), and its LLE has been surpassed by Angrylion-derived plugins and even GLideN64's LLE mode.<br />
*[https://sourceforge.net/p/angrylions-stuff/code/HEAD/tree/ Official Angrylion RDP] - A software-rendered, hardware-accurate plugin, developed by angrylion (though derived from MAME, much like z64gl). This is the most accurate N64 video plugin in existence, emulating almost* every facet of the N64's RDP precisely and thus making it capable of playing almost every single game in the N64 library with no issues, fixing even notorious cases such as the ''Pokémon Snap'' red dot and the ''Body Harvest'' bridge. This, however, comes at the cost of insane CPU requirements while making games look like, well, N64 games running on real hardware, which means native resolution, no widescreen, no hi-res textures - just the N64 in its full, vaseline-covered glory. Since this particular version is single-threaded, uses DirectDraw and is Windows only, it is recommended to use Angrylion RDP Plus or ParaLLEl-RDP instead, which offer much more reasonable performance. Only try it out if you have a tricked-out rig and want to test your CPU's mettle, or if you can compile it from source and need it for testing/debugging purposes, as the latest updates are always made to this version first.<br />
*[http://www.emutalk.net/threads/55481-angrylion-s-Per-Pixel-RDP-with-OpenGL HatCat/angrylion's Pixel-Accurate N64 Plugin] - This is a fork of Angrylion's RDP, done by HatCat. It has some optimizations not present in the official code, but is outdated and lacking some accuracy improvements and optimizations written by Angrylion. It has the option to disable the VI filters (which gives a speed boost), as well as the ability to set custom resolutions. Also, this version uses OpenGL 1.x instead of Direct Draw and supports Linux. Obsoleted by newer forks such as Angrylion RDP Plus.<br />
<br />
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:<br />
<br />
<gallery widths="300" mode="packed"><br />
Mario Tennis Rice.png|Mario Tennis running on ParaLLEl-N64 using Rice. Missing various effects, heavily glitched court.<br />
Mario Tennis Glide64.png|Mario Tennis running on ParaLLEl-N64 using Glide64. Missing various effects and shadows, some glitches.<br />
Mario Tennis glN64.png|Mario Tennis running on ParaLLEl-N64 using glN64. Missing various effects; shadows are present, but glitched.<br />
Mario Tennis GLideN64 HLE.png|Mario Tennis running on Mupen64Plus-Next using GLideN64 in HLE mode with 16xMSAA. Minor text cutoff on bottom of scoreboard.<br />
Mario Tennis GLideN64 LLE.png|Mario Tennis running on Mupen64Plus-Next using GLideN64 in LLE mode with 16xMSAA. Minor text cutoff on bottom of scoreboard. Has slight polygon jitter not present in HLE.<br />
Mario Tennis ParaLLEl 1x.png|Mario Tennis running on Mupen64Plus-Next using ParaLLEl-RDP at native resolution. Identical to Angrylion, and thus a pixel-perfect representation of real hardware.<br />
Mario Tennis ParaLLEl 4x Downsampled.png|Mario Tennis running on Mupen64Plus-Next using ParaLLEl-RDP rendering at 4x resolution, then downsampled back to native resolution.<br />
Mario Tennis ParaLLEl 4x.png|Mario Tennis running on Mupen64Plus-Next using ParaLLEl-RDP rendering at 4x resolution. Has very slight polygon jitter, though less than GLideN64 in LLE.<br />
</gallery><br />
<br />
<nowiki>*</nowiki> There is at least [https://sourceforge.net/p/angrylions-stuff/tickets/10/ one known, relatively minor graphical glitch in Pokemon Snap] (go figure) using Angrylion that requires currently-unimplemented cycle-accurate behavior to fix without resorting to hacks.<br />
<br />
==Audio==<br />
This section will only cover the zilmar spec plugins, as Mupen64Plus does not have any alternative audio plugins besides the default, and neither do the libretro forks.<br />
<br />
*Project64 Audio - The default audio plugin for Project64, apparently loosely based off of code from Mupen64Plus's HLE RSP. Very barebones, with no options to speak off.<br />
*Jabo's DirectSound - Comes with Project64. It works fine for the most part, but some games may not play nice with it. It is a low-level plugin, so it needs an accompanying LLE RSP plugin. Will probably never be updated again.<br />
*[http://www.emutalk.net/threads/27610-Audio-v0-56-WIP2-Download-Feedback Azimer's HLE Audio] - This popular HLE audio plugin boasts high compatibility. Version 0.56WIP2 is old as hell, but it is the tried and true standard to which audio plugins are compared against. Recently, [https://github.com/Azimer/AziAudio Azimer open sourced his plugin], and there were plans to integrate it into Project64, though this has yet to happen. While the latest development versions have a few issues, it now works in LLE, and has integrated code from Mupen64Plus's HLE RSP plugin, allowing it to work with the Factor 5 and BOSS games even in HLE.<br />
*[http://forum.pj64-emu.com/showthread.php?t=3644 Shunyuan's HLE Audio] - An audio plugin, apparently based on 1964Audio and HatCat's RSP plugin. Can run in both LLE and HLE modes despite the name, though the HLE mode just makes it run an outdated, baked-in version of HatCat's RSP, which makes it not a true HLE plugin. Has been abandoned after charges of just taking others' code without revealing a source. If games run at a weird speed using this plugin, go to the ROM's Game Settings, and disable Fixed Audio Timing and Sync using Audio. Though it worked surprisingly well despite its Frankenstein nature, modern development versions of Project64 no longer work with it, apparently due to it depending on a bug that has now been fixed. As such, it is probably better to use Azimer's plugin instead.<br />
<br />
==Input==<br />
*Project64 Input - Comes with Project64 as of the latest versions. Very simple input plugin which looks suspiciously a lot like Jabo's, but at least has XInput support, which is nice.<br />
*[https://sourceforge.net/projects/nragev20/ NRage Input] - Also comes with Project64 as of version 2.2. Hands down the best input plugin as it is more feature complete than Jabo's DirectInput. Has a ton of options and great controller compatibility, including XInput support for use with Xbox 360 controllers. It can't emulate the microphone that is required by ''Hey You, Pikachu'' or the printer required for the ''Pokémon Snap Station''. It has the ability to emulate Controller Pak (''Mario Kart 64'''s ghost saves), Rumble Pak (''Star Fox 64''), and Transfer Pak (''Pokémon Stadium'' series) functionality fairly well. Version 2.3 of Project64 introduced a version of the plug-in that can emulate the N64's mouse accessory designed for the 64DD to coincide with Project64's newest ability to emulate the 64DD accessory. Surprisingly, ''Mario Artist: Paint Studio'' can use the Japanese ''Game Boy Camera'' (called ''Pocket Camera'') in Transfer Pak mode, but the camera function doesn't work as it displays static, although importing captured images still works technically.<br />
*Jabo's DirectInput - Used to come with Project64, but now removed in favor of NRage Input. It isn't too bad, 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 usual, do not expect any updates.<br />
*[https://www.raphnet-tech.com/products/raphnetraw/index.php/ Raphnetraw] - This open source plugin allows streamlined use of N64 controller(s) via raphnet [https://www.raphnet-tech.com/products/n64_usb_adapter_gen3/index.php N64-to-USB v3+ adapters]. It supports rumble and is available for Project64 and mupen64plus. Also contains various DLLs for special port arrangements [https://www.raphnet.net/programmation/mupen64plus-input-raphnetraw/index_en.php#4 (link)].<br />
<br />
==RSP==<br />
===Recommended Plugins===<br />
*Zilmar's RSP - Comes with Project64. Reasonably accurate, quite fast in Recompiler mode (enabled by default), and will work fine for the 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.<br />
*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. 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 work with Jabo's, as that is a pure LLE audio plugin and requires LLE RSP emulation.<br />
*[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 one of the most accurate RSP plugins, though zilmar's RSP in Recompiler mode as well as ParaLLEl-RSP both trump it in speed. It can take advantage of SSSE3 for greater performance, though it also comes in SSE2 and non-SSE variations in case your PC does not support those instruction sets. In both the zilmar and Mupen64Plus versions (though not in libretro, it seems), it is capable of working with both HLE and LLE audio and video plugins via the following settings:<br />
**Simulate RSP graphics from external plugin - Check if using an HLE graphics plugin, uncheck if using LLE<br />
**Simulate RSP audio from external plugin - Check if using an HLE audio plugin, uncheck if using LLE<br />
**Force semaphore locking - Check to fix issues with Mario no Photopie. Only works with Project64 2.x and beyond.<br />
*ParaLLEl-RSP - A fast and accurate RSP written by [https://github.com/Themaister/parallel-rsp Themaister], though it borrows heavily from both CXD4 and CEN64's RSP code. It is about as accurate and compatible as the Static Interpreter/CXD4 RSP, while being much faster owing to its inclusion of a dynamic recompiler. 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). Note that it only works with LLE video and audio plugins, though it is highly recommended if using such.<br />
<br />
===Deprecated Plugins===<br />
*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 and many other compatibility fixes were later added to the Mupen64Plus version, which has now been ported to the zilmar spec after years of exclusivity on the Mupen64Plus side of things. As such, this version is officially obsolete.<br />
*z64 RSP plugin pack - Largely deprecated by the Static Interpreter/CXD4 RSP plugin. This set of RSP plugins comes with the z64 video plugin, each with their own purpose:<br />
**Ziggy-z64RSP - This RSP is based on the MAME/MESS RSP code. It is slower but more accurate.<br />
**Ziggy-PJ64 - Based on the Project64 1.4 RSP, this plugin is much faster.<br />
**angrylion - This RSP is a simple Interpreter, and is required for a few games like World Driver Championship to work correctly with z64gl.<br />
<br />
==Recommended N64 Setups==<br />
<br />
===Overview===<br />
While in general only a small handful of plugins are necessary to play the vast majority of N64 games these days, there are nevertheless a variety of use cases which may necessitate using some plugins in specific combinations over others. The following section will be divided primarily by plugin specs, then further subdivided by the following use case "profiles":<br />
*General Use - A profile that strikes a good balance of speed, accuracy and compatibility. Most games will be playable on average hardware and should run with few to no issues.<br />
*Performance - Focuses primarily on speed for lower-end devices that cannot handle the General Use profile. Many games will be playable, but expect lower overall compatibility, glitches and missing effects.<br />
*Accuracy - Attains the maximum compatibility and accuracy made possible by the emulator. Almost all games will be playable and look as intended, but requires much higher system specifications.<br />
As a rule of thumb, start with the General Use profile. If it's too slow, move down to the Performance profile. Conversely, if there's a problem with the game (or you just want to be as close to real hardware as possible), move up to the Accuracy profile. It should be said there may be configurations within the emulator or plugin settings that may help with speed or compatibility, but it is generally not recommended to mess with them unless you know what you're doing, as both emulators and plugins are usually already optimized on a per-game basis, so moving settings around could result in breaking things. Should you wish to try to eke out more performance out of a given profile, it may be wise to consult with the emulator/plugin developers or communities centered around N64 emulation first.<br />
<br />
===Project64 and Others===<br />
Project64 comes bundled with the following plugins:<br />
*Video: Jabo's Direct3D8, Project64 Video (Glide64 under another name), GLideN64<br />
*Audio: Jabo's DirectSound, Project64 Audio<br />
*Input: NRage for Project64, Project64 Input<br />
*RSP: zilmar's RSP<br />
Should you wish to use other plugins, they must be downloaded from a third party source and dropped into their respective plugin folder categories in the Project64 directory. Video plugins go under Plugin/GFX, audio plugins under Plugin/Audio, etc.<br />
<br />
*'''General Use'''<br />
**GLideN64<br />
**Azimer's Audio NEW (set to LLE)<br />
**Static Interpreter RSP or Zilmar's RSP<br />
**Either of the RSP plugins should be fine for most games. The Static Interpreter RSP is slightly more accurate, whereas zilmar's is much faster. Should you wish to use GLideN64 in LLE mode (or any LLE video plugin for that matter), if using zilmar's RSP, simply uncheck "Graphics HLE" in the Plugin configuration screen. If using the Static Interpreter RSP, you'll have to run the spconfig.exe that comes with that plugin, and tell it to NOT "simulate RSP graphics from external plugin" (in other words, type "0"). ParaLLEl-RSP only works in LLE, so GLideN64's HLE mode will be unavailable with that plugin.<br />
*'''Performance'''<br />
**Project64 Video or Glide64 Final<br />
**Azimer's HLE Audio<br />
**Zilmar's RSP or Mupen64Plus HLE RSP<br />
**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. Recommended for the older zilmar-spec emulators as well (replace Project64 Video with Glide64 Final for those, though you may want to do that even with Project64 should you run into a regression). 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.<br />
*'''Accuracy'''<br />
**Angrylion RDP Plus<br />
**Azimer's Audio NEW<br />
**Static RSP Interpreter<br />
**If you have a decent quad-core CPU, you can run many N64 games with pixel-perfect graphics at full speed, thanks to the new multithreaded version of angrylion's software plugin. The new Azimer's plugin (still WIP) works good in LLE. Since there's almost no visual difference, you may as well use ParaLLEl-RSP to get better performance, and/or move to ParaLLEl-RDP outright for even greater speed and upscaling options to boot (though it goes without saying upscaling would no longer be accurate). Conversely, if you want even greater accuracy, disable "Hide advanced settings" under Configuration, then enable "Always use interpreter core" under Advanced, and under Angrylion's options, disable multi-threading and set compatibility to "Slow". Performance WILL crash, but hey, it'll be accurate!<br />
<br />
===Mupen64Plus===<br />
The official releases of Mupen64Plus only come bundled with a handful of video and RSP plugins, namely Glide64mk2, Rice, and the HLE RSP. The developers also maintain forks of the CXD4 RSP and the z64 video and RSP plugins, but they are not included in the official release bundles for some reason. Should you wish to use those plugins or third party ones such as GLideN64 or the ParaLLEl plugins, you must build them yourself or get them from outside sources. Due to this fact, the mediocre nature of the "official" video plugins, and the overall lack of user-friendliness, it may be better to use a fork such as [[m64p]] or [[RMG]], though note that m64p only comes and works with the ParaLLEl plugins, so RMG is a better choice if you wish to use something else, as that comes with more plugins and allows you to use whichever ones you want.<br />
*'''General Use'''<br />
**Video: GLideN64 or ParaLLEl-RDP<br />
**RSP: RSP-HLE (for GLideN64) or ParaLLEl-RSP (for ParaLLEl-RDP)<br />
**Either one of these combinations will enable you to play the vast majority of N64 games while having reasonable system requirements. GLideN64 is faster and has more enhancement options, but ParaLLEl-RDP is much more accurate to the real console. You can also use the CXD4 RSP with GLideN64 if you want, but be sure to set it to pass display lists to the graphics plugin in mupen64plus.cfg, else GLideN64 will switch to its LLE mode, which is not generally recommended to use.<br />
*'''Performance'''<br />
**Video: Glide64mk2<br />
**RSP: RSP-HLE<br />
**These are Mupen64Plus's default plugins. Glide64mk2 is based on Glide64 Final, and is named so as to differentiate it from the original, now obsolete fork of Glide64 that Mupen64Plus used at its inception. It is not up to GLideN64's level, but it does well enough for many games and is quite fast. Use this combination if you have a lower end PC that can't handle the General Use setup. If your device STILL can't handle this setup, try the Rice video plugin, but expect many missing effects, glitches and incompatibilities.<br />
*'''Accuracy'''<br />
**Video: Angrylion Plus or ParaLLEl-RDP<br />
**RSP: CXD4-ssse3 or ParaLLEl-RSP<br />
**Any combination of these should result in very high accuracy. Technically, the most accurate setup is Angrylion combined with CXD4, but the difference between these and the ParaLLEl plugins is almost negligible, while being a lot slower. Be sure to set the CPU core to Pure Interpreter for even greater accuracy, along with plummeting framerates.<br />
<br />
Note: In some cases the cfg file may not appear, in which case you may do this:<br />
*Open terminal in emulator folder on in its respective directory<br />
*''mupen64plus --configdir'' /directory/where/you/want/it/to/be<br />
<br />
===Libretro===<br />
There are two N64 libretro emulator cores for use on libretro frontends such as [[RetroArch]]: Mupen64Plus-Next and ParaLLEl-N64. The former is up-to-date and is recommended for most use cases, while the latter is no longer updated and is only around for performance reasons. They also have access to the following plugins:<br />
*Shared by both cores<br />
**Video: ParaLLEl-RDP , Angrylion<br />
**RSP: ParaLLEl-RSP, HLE, CXD4<br />
*Exclusive to Mupen64Plus-Next<br />
**GLideN64<br />
*Exclusive to ParaLLEl-N64<br />
**glN64, Rice, Glide64<br />
Due to these differences, it is advisable to use Mupen64Plus-Next for general use, and ParaLLEl-N64 for performance.<br />
*'''General Use (LLE)'''<br />
**Core: Mupen64Plus-Next<br />
**Video: ParaLLEl-RDP<br />
**RSP: ParaLLEl-RSP<br />
**By default ParaLLEl-RDP will output at native resolution with all the VI filters on, making it look exactly like Angrylion and the real N64 console. Upscaling must therefore be enabled in the core options. You can also alternatively render at a high resolution and downsample to a lower one if you want to improve 3D without making it stick out from 2D elements too much.<br />
*'''General Use (HLE)'''<br />
**Core: Mupen64Plus-Next<br />
**Video: GLideN64<br />
**RSP: HLE<br />
**While GLideN64 also works with the ParaLLEl and CXD4 RSP plugins, using them will cause GLideN64 to switch to its LLE mode, which is currently glitchier and slower than the HLE mode, for few compatibility or accuracy benefits, if any. As such, it is recommended to stick with the HLE RSP for GLideN64.<br />
*'''Performance'''<br />
**Core: ParaLLEl-N64<br />
**Video: Glide64<br />
**RSP: HLE<br />
**For slow, low-end devices and old PCs only. If further speed is desired or needed, you may try glN64 or Rice, but using them comes at a steep cost in compatibility and accuracy, and many low-end devices in use today ought to be able to handle Glide64 just fine (well, with the exception of certain underpowered "retro gaming" handhelds).<br />
*'''Accuracy'''<br />
**Core: Mupen64Plus-Next<br />
**Video: Angrylion<br />
**RSP: CXD4<br />
**Just like the developers intended! If you want to go all out, set the CPU core to Pure Interpreter, turn off multi-threading and set thread sync level to High in Angrylion's options for the real 30 VI/s experience. Closest you'll get to real hardware until a complete cycle-accurate N64 emulator surfaces.<br />
<br />
[[Category:Recommendations]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Recommended_N64_plugins&diff=48524Recommended N64 plugins2022-07-17T21:19:15Z<p>GPDP1: zilmar's RSP is known to have some issues in LLE, so it doesn't make sense to recommend it for the Accuracy setup</p>
<hr />
<div>The N64 emulation scene had previously been described as a broken mess, the very definition of plugin hell. With recent developments in the scene, however, the situation has markedly improved, and it is no longer considered necessary to have multiple emulators and plugins on hand to get most games to work. This page will outline the best plugins currently available for the benefit of both the casual and enthusiast looking to get their N64 emulation fix.<br />
<br />
==The Plugin Specs==<br />
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.<br />
<br />
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.<br />
<br />
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. Unsurprisingly, this situation often led to a lot of confusion from users, who often wondered why there were so many plugins, and which ones were the best to use, only to find out it often depended on the game, and even then, some games would refuse to work as intended no matter what was tried. Hence the label "plugin hell" was coined, and stuck as a description of the travails of trying to emulate N64 games well into the 2010's.<br />
<br />
However, as time went on, things began to change, though 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.<br />
<br />
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 changes and 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) video plugin there is but was initially only available for the zilmar spec, was ported to Mupen64Plus and integrated into 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.<br />
<br />
All that said, the issue is that there are now three plugin standards to account for:<br />
<br />
*The zilmar spec - Utilized by Project64 and most other legacy emulators; only Project64 still uses it today.*<br />
<br />
*The Mupen64Plus spec - Utilized by Mupen64Plus and most of its forks.<br />
<br />
*Libretro - Not really a spec per se, as the plugins are integrated directly into the libretro core, so there's no DLL files to download or add.<br />
<br />
As of right now, not all plugins are readily available on all three. Consult the tables below for reference:<br />
<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Latest Version<br />
! scope="col"|Project64<br />
! scope="col"|Mupen64Plus<br />
! scope="col"|Libretro<br />
! scope="col"|HLE<br />
! scope="col"|LLE<br />
! scope="col"|Widescreen Hack<br />
! scope="col"|Custom Texture Packs<br />
! scope="col"|Recommended<br />
|-<br />
!colspan="13"|Video Plugins<br />
|-<br />
|ParaLLEl-RDP<br />
|[https://github.com/Themaister/parallel-rdp git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|GLideN64<br />
|[https://github.com/gonetz/GLideN64/releases/tag/github-actions github-actions]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Angrylion RDP Plus<br />
|[https://github.com/ata4/angrylion-rdp-plus/releases/tag/v1.6 1.6]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|Glide64**<br />
|Final<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|Jabo's Direct3D8<br />
|1.7.0.57-ver5<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Rice Video<br />
|0.4.4<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|glN64<br />
|0.4.1<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|z64gl<br />
|R17<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Angrylion (Official)<br />
|r114<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|}<br />
<br />
<nowiki>*</nowiki>It should be noted that Project64 after version 2.x made some changes to the zilmar plugin spec, and while it remains backwards compatible with the older version of the spec (meaning most older plugins will still work with Project64), plugins targeting the newer version will not work on older versions of Project64 or other zilmar spec-based emulators.<br />
<br />
<nowiki>**</nowiki>Funnily enough, Glide64 actually DOES have LLE code (much of it apparently comes from z64gl) and can technically run in LLE mode by using it alongside an LLE RSP plugin such as CXD4. However, it is not a complete implementation, and actually trying to run it in such a mode results in massive visual glitches, making it unusable. Practically speaking, then, Glide64 cannot be considered a true LLE plugin, and will not be designated as such, nor was it ever meant to be.<br />
<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Latest Version<br />
! scope="col"|Project64<br />
! scope="col"|Mupen64Plus<br />
! scope="col"|Libretro<br />
! scope="col"|HLE Compatible*<br />
! scope="col"|LLE Compatible*<br />
! scope="col"|Recommended<br />
|-<br />
!colspan="13"|RSP Plugins<br />
|-<br />
|Zilmar's RSP<br />
|1.7<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Mupen64Plus HLE RSP<br />
|[https://github.com/mupen64plus/mupen64plus-rsp-hle git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|Static Interpreter/CXD4<br />
|[https://github.com/cxd4/rsp git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|ParaLLEl-RSP<br />
|[https://github.com/Themaister/parallel-rsp git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Mupen64 HLE RSP<br />
|0.5.1<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|z64<br />
|r17<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|}<br />
<br />
<nowiki>*</nowiki>These terms signify whether an RSP plugin can work alongside HLE and/or LLE audio and video plugins. As for the type of emulation employed by the RSP plugins themselves, all but the Mupen64/plus HLE RSP plugins are LLE in nature. The LLE RSP plugins that can work with HLE plugins do so by passing the N64 display and audio lists onto the plugins themselves.<br />
<br />
==Video==<br />
===Currently Recommended Plugins===<br />
The following are the current best video plugins for use on modern PCs and devices.<br />
[[File:SuperMario64-Comparison.png|thumb|right|Jabo's Direct3D8 (left) compared with angrylion's RDP with OpenGL (right), while playing ''Super Mario 64''.]]<br />
====[https://github.com/Themaister/parallel-rdp ParaLLEl-RDP]====<br />
An LLE video plugin inspired by and referenced against Angrylion's RDP plugin, 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 several forks of Mupen64Plus and Project64, such as [[m64p]] and [https://www.64dd.org/downloads.html this build] of Project64. This is currently considered the best video plugin by most measures. It is almost 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 can also render at a high resolution and downsample back down to a lower one, should one wish to improve the 3D graphics without making them stick out from the often low-res 2D elements. Due to its LLE nature, it does not support widescreen hacks or high-res textures - try GLideN64 if you seek to use such features.<br />
<br />
System requirements for ParaLLEl-RDP are higher than for the other plugins. It requires a GPU with Vulkan support and up-to-date drivers (most Nvidia and AMD GPUs made after 2012 should be covered, though Intel graphics requires Skylake or newer), and upscaling increases the GPU requirements even further, far more than GLideN64. It must also be used in conjunction with an LLE RSP plugin, preferably its sister plugin ParaLLEl-RSP, as it features a recompiler for added speed. At native resolution, however, a modest PC with Vulkan support can handle it without much issue, even on integrated graphics.<br />
<br />
====[https://github.com/gonetz/GLideN64/ GLideN64]====<br />
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 z64gl and, 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 emulation of every game, gamma correction, flat and prim shading, VI emulation, and LLE graphics support. 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]], MSAA 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]].<br />
<br />
GLideN64 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.<br />
<br />
====[https://github.com/ata4/angrylion-rdp-plus/releases Angrylion RDP Plus]====<br />
This is a fork of Angrylion's RDP that supports multithreading. It 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, as does using it alongside an RSP plugin with a recompiler such as ParaLLEl-RSP, but some games are still not full speed even on a Core i7-8700K. It also allows you to disable VI filters for slightly better performance. This fork has at least one accuracy regression compared to the official version of Angrylion. 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.<br />
<br />
====Glide64====<br />
The former best general-use plugin. Versions of this are included in Project64, mainline Mupen64Plus, and the ParaLLEl-N64 libretro core. While it is no longer updated and is far less accurate and compatible than the newer offerings, it still has a few use cases, such as better support for older ROM hacks. It works relatively well for many (most?) games, has support for hi-res textures, and it is also faster than the newer plugins, which makes it suitable for slower devices such as the older Raspberry Pis. Otherwise, to ensure the highest possible compatibility, stick to either ParaLLEl-RDP or GLideN64.<br />
<br />
Note that the Project64 version of Glide64 has been renamed to Project64 Video and has undergone some changes and rewrites since it was initially forked, and thus may contain regressions compared to the last official standalone release of the plugin by Gonetz. Since this fork only works with current versions of Project64, should you wish to use this plugin on an older zilmar-spec emulator like 1964 or the original Mupen64, or if you want to avoid potential regressions with the Project64 version, use [https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/glidehqplusglitch64/Glide64_Final.zip Glide64 Final] instead.<br />
<br />
===Deprecated Plugins===<br />
The following video plugins are old and deprecated, and should not be used or considered unless you have a VERY old or underpowered device that cannot handle the recommended plugins, or there's a very specific use case not covered by modern implementations.<br />
<br />
*Jabo's Direct3D8 - Comes with Project64, and was once its default video plugin. Very speedy, has built-in AA and AF options, and includes a [[Widescreen_Hack|widescreen hack]]. The version included with the most recent versions of Project64 (1.7.0.57-ver5) is somewhat buggy and has regressions, however. [http://www.jabosoft.com/articles/114 Jabo's 1.6.1 patch] is better, though version 1.7 can run in LLE mode, which can help with a few games. Sadly, it will likely never see another update again, and though it is still included in Project64 to this day, it is no longer the default, and should not be used unless you have a very old PC that cannot handle Glide64 or GLideN64.<br />
*[http://www.emutalk.net/threads/54166-Rice-Video-Community-version Rice Video] - A very fast, highly configurable video plugin primarily based around the Direct3D API. It was once famous for being the first plugin that allowed the user to load [[Texture_Packs|custom hi-res textures]], which made 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, all aiming to fix issues or add features (one fork even featured early shader support), and forks of it are included in mainline Mupen64Plus and in the ParaLLEl-N64 libretro core. However, even during its heyday it lagged behind Glide64 and even Jabo in both compatibility and accuracy, and once Glide64 gained the ability to load custom textures, there remained little reason to use it beyond its speed. A "Community Version" popped up that aimed at improving it and fixing its issues, but it ended up introducing many regressions compared to older versions and the effort was eventually abandoned. 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) or are trying to emulate on a very old and/or severely underpowered PC or handheld device. If you are absolutely resolved to try it out, seek out the original versions by Rice, primarily 6.1.0 or 6.1.1b, and stick to the Direct3D renderer, as the OpenGL backend included in some versions is buggy and incomplete outside of the Mupen64Plus fork.<br />
*[http://www.emutalk.net/threads/40640-Z64-a-LLE-graphics-plugin z64gl] - A hardware-rendered, low-level plugin developed by ziggy, derived from MAME's N64 driver. A fork is maintained by the Mupen64Plus team, though not included in their official releases. It was once notable for being one of the only plugins that could play games without an HLE microcode implementation such as Rogue Squadron. However, it was rather glitchy, had higher system requirements than the HLE plugins, needed an LLE RSP plugin to work (such as the bundled z64 RSP or Project64's RSP plugin set to LLE graphics), and configuration required editing the config file directly. A [https://github.com/purplemarshmallow/z64/tree/angrylion-integration fork] cropped up that aimed at improving it, but it did not get very far. Nowadays, it's obsolete, as GLideN64 can now play every game through HLE (thus subverting z64gl's only selling point), and its LLE has been surpassed by Angrylion-derived plugins and even GLideN64's LLE mode.<br />
*[https://sourceforge.net/p/angrylions-stuff/code/HEAD/tree/ Official Angrylion RDP] - A software-rendered, hardware-accurate plugin, developed by angrylion (though derived from MAME, much like z64gl). This is the most accurate N64 video plugin in existence, emulating almost* every facet of the N64's RDP precisely and thus making it capable of playing almost every single game in the N64 library with no issues, fixing even notorious cases such as the ''Pokémon Snap'' red dot and the ''Body Harvest'' bridge. This, however, comes at the cost of insane CPU requirements while making games look like, well, N64 games running on real hardware, which means native resolution, no widescreen, no hi-res textures - just the N64 in its full, vaseline-covered glory. Since this particular version is single-threaded, uses DirectDraw and is Windows only, it is recommended to use Angrylion RDP Plus or ParaLLEl-RDP instead, which offer much more reasonable performance. Only try it out if you have a tricked-out rig and want to test your CPU's mettle, or if you can compile it from source and need it for testing/debugging purposes, as the latest updates are always made to this version first.<br />
*[http://www.emutalk.net/threads/55481-angrylion-s-Per-Pixel-RDP-with-OpenGL HatCat/angrylion's Pixel-Accurate N64 Plugin] - This is a fork of Angrylion's RDP, done by HatCat. It has some optimizations not present in the official code, but is outdated and lacking some accuracy improvements and optimizations written by Angrylion. It has the option to disable the VI filters (which gives a speed boost), as well as the ability to set custom resolutions. Also, this version uses OpenGL 1.x instead of Direct Draw and supports Linux. Obsoleted by newer forks such as Angrylion RDP Plus.<br />
<br />
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:<br />
<br />
<gallery widths="300" mode="packed"><br />
Mario Tennis Rice.png|Mario Tennis running on ParaLLEl-N64 using Rice. Missing various effects, heavily glitched court.<br />
Mario Tennis Glide64.png|Mario Tennis running on ParaLLEl-N64 using Glide64. Missing various effects and shadows, some glitches.<br />
Mario Tennis glN64.png|Mario Tennis running on ParaLLEl-N64 using glN64. Missing various effects; shadows are present, but glitched.<br />
Mario Tennis GLideN64 HLE.png|Mario Tennis running on Mupen64Plus-Next using GLideN64 in HLE mode with 16xMSAA. Minor text cutoff on bottom of scoreboard.<br />
Mario Tennis GLideN64 LLE.png|Mario Tennis running on Mupen64Plus-Next using GLideN64 in LLE mode with 16xMSAA. Minor text cutoff on bottom of scoreboard. Has slight polygon jitter not present in HLE.<br />
Mario Tennis ParaLLEl 1x.png|Mario Tennis running on Mupen64Plus-Next using ParaLLEl-RDP at native resolution. Identical to Angrylion, and thus a pixel-perfect representation of real hardware.<br />
Mario Tennis ParaLLEl 4x Downsampled.png|Mario Tennis running on Mupen64Plus-Next using ParaLLEl-RDP rendering at 4x resolution, then downsampled back to native resolution.<br />
Mario Tennis ParaLLEl 4x.png|Mario Tennis running on Mupen64Plus-Next using ParaLLEl-RDP rendering at 4x resolution. Has very slight polygon jitter, though less than GLideN64 in LLE.<br />
</gallery><br />
<br />
<nowiki>*</nowiki> There is at least [https://sourceforge.net/p/angrylions-stuff/tickets/10/ one known, relatively minor graphical glitch in Pokemon Snap] (go figure) using Angrylion that requires currently-unimplemented cycle-accurate behavior to fix without resorting to hacks.<br />
<br />
==Audio==<br />
This section will only cover the zilmar spec plugins, as Mupen64Plus does not have any alternative audio plugins besides the default, and neither do the libretro forks.<br />
<br />
*Project64 Audio - The default audio plugin for Project64, apparently loosely based off of code from Mupen64Plus's HLE RSP. Very barebones, with no options to speak off.<br />
*Jabo's DirectSound - Comes with Project64. It works fine for the most part, but some games may not play nice with it. It is a low-level plugin, so it needs an accompanying LLE RSP plugin. Will probably never be updated again.<br />
*[http://www.emutalk.net/threads/27610-Audio-v0-56-WIP2-Download-Feedback Azimer's HLE Audio] - This popular HLE audio plugin boasts high compatibility. Version 0.56WIP2 is old as hell, but it is the tried and true standard to which audio plugins are compared against. Recently, [https://github.com/Azimer/AziAudio Azimer open sourced his plugin], and there were plans to integrate it into Project64, though this has yet to happen. While the latest development versions have a few issues, it now works in LLE, and has integrated code from Mupen64Plus's HLE RSP plugin, allowing it to work with the Factor 5 and BOSS games even in HLE.<br />
*[http://forum.pj64-emu.com/showthread.php?t=3644 Shunyuan's HLE Audio] - An audio plugin, apparently based on 1964Audio and HatCat's RSP plugin. Can run in both LLE and HLE modes despite the name, though the HLE mode just makes it run an outdated, baked-in version of HatCat's RSP, which makes it not a true HLE plugin. Has been abandoned after charges of just taking others' code without revealing a source. If games run at a weird speed using this plugin, go to the ROM's Game Settings, and disable Fixed Audio Timing and Sync using Audio. Though it worked surprisingly well despite its Frankenstein nature, modern development versions of Project64 no longer work with it, apparently due to it depending on a bug that has now been fixed. As such, it is probably better to use Azimer's plugin instead.<br />
<br />
==Input==<br />
*Project64 Input - Comes with Project64 as of the latest versions. Very simple input plugin which looks suspiciously a lot like Jabo's, but at least has XInput support, which is nice.<br />
*[https://sourceforge.net/projects/nragev20/ NRage Input] - Also comes with Project64 as of version 2.2. Hands down the best input plugin as it is more feature complete than Jabo's DirectInput. Has a ton of options and great controller compatibility, including XInput support for use with Xbox 360 controllers. It can't emulate the microphone that is required by ''Hey You, Pikachu'' or the printer required for the ''Pokémon Snap Station''. It has the ability to emulate Controller Pak (''Mario Kart 64'''s ghost saves), Rumble Pak (''Star Fox 64''), and Transfer Pak (''Pokémon Stadium'' series) functionality fairly well. Version 2.3 of Project64 introduced a version of the plug-in that can emulate the N64's mouse accessory designed for the 64DD to coincide with Project64's newest ability to emulate the 64DD accessory. Surprisingly, ''Mario Artist: Paint Studio'' can use the Japanese ''Game Boy Camera'' (called ''Pocket Camera'') in Transfer Pak mode, but the camera function doesn't work as it displays static, although importing captured images still works technically.<br />
*Jabo's DirectInput - Used to come with Project64, but now removed in favor of NRage Input. It isn't too bad, 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 usual, do not expect any updates.<br />
*[https://www.raphnet-tech.com/products/raphnetraw/index.php/ Raphnetraw] - This open source plugin allows streamlined use of N64 controller(s) via raphnet [https://www.raphnet-tech.com/products/n64_usb_adapter_gen3/index.php N64-to-USB v3+ adapters]. It supports rumble and is available for Project64 and mupen64plus. Also contains various DLLs for special port arrangements [https://www.raphnet.net/programmation/mupen64plus-input-raphnetraw/index_en.php#4 (link)].<br />
<br />
==RSP==<br />
===Recommended Plugins===<br />
*Zilmar's RSP - Comes with Project64. Reasonably accurate, quite fast in Recompiler mode (enabled by default), and will work fine for the 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.<br />
*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. 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 work with Jabo's, as that is a pure LLE audio plugin and requires LLE RSP emulation.<br />
*[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 one of the most accurate RSP plugins, though zilmar's RSP in Recompiler mode as well as ParaLLEl-RSP both trump it in speed. It can take advantage of SSSE3 for greater performance, though it also comes in SSE2 and non-SSE variations in case your PC does not support those instruction sets. In both the zilmar and Mupen64Plus versions (though not in libretro, it seems), it is capable of working with both HLE and LLE audio and video plugins via the following settings:<br />
**Simulate RSP graphics from external plugin - Check if using an HLE graphics plugin, uncheck if using LLE<br />
**Simulate RSP audio from external plugin - Check if using an HLE audio plugin, uncheck if using LLE<br />
**Force semaphore locking - Check to fix issues with Mario no Photopie. Only works with Project64 2.x and beyond.<br />
*ParaLLEl-RSP - A fast and accurate RSP written by [https://github.com/Themaister/parallel-rsp Themaister], though it borrows heavily from both CXD4 and CEN64's RSP code. It is about as accurate and compatible as the Static Interpreter/CXD4 RSP, while being much faster owing to its inclusion of a dynamic recompiler. 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). Note that it only works with LLE video and audio plugins, though it is highly recommended if using such.<br />
<br />
===Deprecated Plugins===<br />
*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 and many other compatibility fixes were later added to the Mupen64Plus version, which has now been ported to the zilmar spec after years of exclusivity on the Mupen64Plus side of things. As such, this version is officially obsolete.<br />
*z64 RSP plugin pack - Largely deprecated by the Static Interpreter/CXD4 RSP plugin. This set of RSP plugins comes with the z64 video plugin, each with their own purpose:<br />
**Ziggy-z64RSP - This RSP is based on the MAME/MESS RSP code. It is slower but more accurate.<br />
**Ziggy-PJ64 - Based on the Project64 1.4 RSP, this plugin is much faster.<br />
**angrylion - This RSP is a simple Interpreter, and is required for a few games like World Driver Championship to work correctly with z64gl.<br />
<br />
==Recommended N64 Setups==<br />
<br />
===Project64 and Others===<br />
Project64 comes bundled with the following plugins:<br />
*Video: Jabo's Direct3D8, Project64 Video (Glide64 under another name), GLideN64<br />
*Audio: Jabo's DirectSound, Project64 Audio<br />
*Input: NRage for Project64, Project64 Input<br />
*RSP: zilmar's RSP<br />
Should you wish to use other plugins, they must be downloaded from a third party source and dropped into their respective plugin folder categories in the Project64 directory. Video plugins go under Plugin/GFX, audio plugins under Plugin/Audio, etc.<br />
<br />
*'''General Use'''<br />
**GLideN64<br />
**Azimer's Audio NEW (set to LLE)<br />
**Static Interpreter RSP or Zilmar's RSP<br />
**Either of the RSP plugins should be fine for most games. The Static Interpreter RSP is slightly more accurate, whereas zilmar's is much faster. Should you wish to use GLideN64 in LLE mode (or any LLE video plugin for that matter), if using zilmar's RSP, simply uncheck "Graphics HLE" in the Plugin configuration screen. If using the Static Interpreter RSP, you'll have to run the spconfig.exe that comes with that plugin, and tell it to NOT "simulate RSP graphics from external plugin" (in other words, type "0"). ParaLLEl-RSP only works in LLE, so GLideN64's HLE mode will be unavailable with that plugin.<br />
*'''Best Performance'''<br />
**Project64 Video or Glide64 Final<br />
**Azimer's HLE Audio<br />
**Zilmar's RSP or Mupen64Plus HLE RSP<br />
**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. Recommended for the older zilmar-spec emulators as well (replace Project64 Video with Glide64 Final for those, though you may want to do that even with Project64 should you run into a regression). 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.<br />
*'''Accuracy'''<br />
**Angrylion RDP Plus<br />
**Azimer's Audio NEW<br />
**Static RSP Interpreter<br />
**If you have a decent quad-core CPU, you can run many N64 games with pixel-perfect graphics at full speed, thanks to the new multithreaded version of angrylion's software plugin. The new Azimer's plugin (still WIP) works good in LLE. Since there's almost no visual difference, you may as well use ParaLLEl-RSP to get better performance, and/or move to ParaLLEl-RDP outright for even greater speed and upscaling options to boot (though it goes without saying upscaling would no longer be accurate). Conversely, if you want even greater accuracy, disable "Hide advanced settings" under Configuration, then enable "Always use interpreter core" under Advanced, and under Angrylion's options, disable multi-threading and set compatibility to "Slow". Performance WILL crash, but hey, it'll be accurate!<br />
<br />
===Mupen64Plus===<br />
The official releases of Mupen64Plus only come bundled with a handful of video and RSP plugins, namely Glide64mk2, Rice, and the HLE RSP. The developers also maintain forks of the CXD4 RSP and the z64 video and RSP plugins, but they are not included in the official release bundles for some reason. Should you wish to use those plugins or third party ones such as GLideN64 or the ParaLLEl plugins, you must build them yourself or get them from outside sources. Due to this fact, the mediocre nature of the "official" video plugins, and the overall lack of user-friendliness, it may be better to use a fork such as [[m64p]] or [[RMG]], though note that m64p only comes and works with the ParaLLEl plugins, so RMG is a better choice if you wish to use something else, as that comes with more plugins and allows you to use whichever ones you want.<br />
*'''General Use'''<br />
**Video: GLideN64 or ParaLLEl-RDP<br />
**RSP: RSP-HLE (for GLideN64) or ParaLLEl-RSP (for ParaLLEl-RDP)<br />
**Either one of these combinations will enable you to play the vast majority of N64 games while having reasonable system requirements. GLideN64 is faster and has more enhancement options, but ParaLLEl-RDP is much more accurate to the real console. You can also use the CXD4 RSP with GLideN64 if you want, but be sure to set it to pass display lists to the graphics plugin in mupen64plus.cfg, else GLideN64 will switch to its LLE mode, which is not generally recommended to use.<br />
*'''Best Performance'''<br />
**Video: Glide64mk2<br />
**RSP: RSP-HLE<br />
**These are Mupen64Plus's default plugins. Glide64mk2 is based on Glide64 Final, and is named so as to differentiate it from the original, now obsolete fork of Glide64 that Mupen64Plus used at its inception. It is not up to GLideN64's level, but it does well enough for many games and is quite fast. Use this combination if you have a lower end PC that can't handle the General Use setup. If your device STILL can't handle this setup, try the Rice video plugin, but expect many missing effects, glitches and incompatibilities.<br />
*'''Accuracy'''<br />
**Video: Angrylion Plus or ParaLLEl-RDP<br />
**RSP: CXD4-ssse3 or ParaLLEl-RSP<br />
**Any combination of these should result in very high accuracy. Technically, the most accurate setup is Angrylion combined with CXD4, but the difference between these and the ParaLLEl plugins is almost negligible, while being a lot slower. Be sure to set the CPU core to Pure Interpreter for even greater accuracy, along with plummeting framerates.<br />
<br />
Note: In some cases the cfg file may not appear, in which case you may do this:<br />
*Open terminal in emulator folder on in its respective directory<br />
*''mupen64plus --configdir'' /directory/where/you/want/it/to/be<br />
<br />
===Libretro===<br />
There are two N64 libretro emulator cores for use on libretro frontends such as [[RetroArch]]: Mupen64Plus-Next and ParaLLEl-N64. The former is up-to-date and is recommended for most use cases, while the latter is no longer updated and is only around for performance reasons. They also have access to the following plugins:<br />
*Shared by both cores<br />
**Video: ParaLLEl-RDP , Angrylion<br />
**RSP: ParaLLEl-RSP, HLE, CXD4<br />
*Exclusive to Mupen64Plus-Next<br />
**GLideN64<br />
*Exclusive to ParaLLEl-N64<br />
**glN64, Rice, Glide64<br />
Due to these differences, it is advisable to use Mupen64Plus-Next for general use, and ParaLLEl-N64 for performance.<br />
*'''General Use (LLE)'''<br />
**Core: Mupen64Plus-Next<br />
**Video: ParaLLEl-RDP<br />
**RSP: ParaLLEl-RSP<br />
**By default ParaLLEl-RDP will output at native resolution with all the VI filters on, making it look exactly like Angrylion and the real N64 console. Upscaling must therefore be enabled in the core options. You can also alternatively render at a high resolution and downsample to a lower one if you want to improve 3D without making it stick out from 2D elements too much.<br />
*'''General Use (HLE)'''<br />
**Core: Mupen64Plus-Next<br />
**Video: GLideN64<br />
**RSP: HLE<br />
**While GLideN64 also works with the ParaLLEl and CXD4 RSP plugins, using them will cause GLideN64 to switch to its LLE mode, which is currently glitchier and slower than the HLE mode, for few compatibility or accuracy benefits, if any. As such, it is recommended to stick with the HLE RSP for GLideN64.<br />
*'''Best Performance'''<br />
**Core: ParaLLEl-N64<br />
**Video: Glide64<br />
**RSP: HLE<br />
**For slow, low-end devices and old PCs only. If further speed is desired or needed, you may try glN64 or Rice, but using them comes at a steep cost in compatibility and accuracy, and many low-end devices in use today ought to be able to handle Glide64 just fine (well, with the exception of certain underpowered "retro gaming" handhelds).<br />
*'''Accuracy'''<br />
**Core: Mupen64Plus-Next<br />
**Video: Angrylion<br />
**RSP: CXD4<br />
**Just like the developers intended! If you want to go all out, set the CPU core to Pure Interpreter, turn off multi-threading and set thread sync level to High in Angrylion's options for the real 30 VI/s experience. Closest you'll get to real hardware until a complete cycle-accurate N64 emulator surfaces.<br />
<br />
[[Category:Recommendations]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Recommended_N64_plugins&diff=48523Recommended N64 plugins2022-07-17T21:14:51Z<p>GPDP1: /* Recommended Plugins */</p>
<hr />
<div>The N64 emulation scene had previously been described as a broken mess, the very definition of plugin hell. With recent developments in the scene, however, the situation has markedly improved, and it is no longer considered necessary to have multiple emulators and plugins on hand to get most games to work. This page will outline the best plugins currently available for the benefit of both the casual and enthusiast looking to get their N64 emulation fix.<br />
<br />
==The Plugin Specs==<br />
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.<br />
<br />
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.<br />
<br />
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. Unsurprisingly, this situation often led to a lot of confusion from users, who often wondered why there were so many plugins, and which ones were the best to use, only to find out it often depended on the game, and even then, some games would refuse to work as intended no matter what was tried. Hence the label "plugin hell" was coined, and stuck as a description of the travails of trying to emulate N64 games well into the 2010's.<br />
<br />
However, as time went on, things began to change, though 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.<br />
<br />
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 changes and 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) video plugin there is but was initially only available for the zilmar spec, was ported to Mupen64Plus and integrated into 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.<br />
<br />
All that said, the issue is that there are now three plugin standards to account for:<br />
<br />
*The zilmar spec - Utilized by Project64 and most other legacy emulators; only Project64 still uses it today.*<br />
<br />
*The Mupen64Plus spec - Utilized by Mupen64Plus and most of its forks.<br />
<br />
*Libretro - Not really a spec per se, as the plugins are integrated directly into the libretro core, so there's no DLL files to download or add.<br />
<br />
As of right now, not all plugins are readily available on all three. Consult the tables below for reference:<br />
<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Latest Version<br />
! scope="col"|Project64<br />
! scope="col"|Mupen64Plus<br />
! scope="col"|Libretro<br />
! scope="col"|HLE<br />
! scope="col"|LLE<br />
! scope="col"|Widescreen Hack<br />
! scope="col"|Custom Texture Packs<br />
! scope="col"|Recommended<br />
|-<br />
!colspan="13"|Video Plugins<br />
|-<br />
|ParaLLEl-RDP<br />
|[https://github.com/Themaister/parallel-rdp git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|GLideN64<br />
|[https://github.com/gonetz/GLideN64/releases/tag/github-actions github-actions]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Angrylion RDP Plus<br />
|[https://github.com/ata4/angrylion-rdp-plus/releases/tag/v1.6 1.6]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|Glide64**<br />
|Final<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|Jabo's Direct3D8<br />
|1.7.0.57-ver5<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Rice Video<br />
|0.4.4<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|glN64<br />
|0.4.1<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|z64gl<br />
|R17<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Angrylion (Official)<br />
|r114<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|}<br />
<br />
<nowiki>*</nowiki>It should be noted that Project64 after version 2.x made some changes to the zilmar plugin spec, and while it remains backwards compatible with the older version of the spec (meaning most older plugins will still work with Project64), plugins targeting the newer version will not work on older versions of Project64 or other zilmar spec-based emulators.<br />
<br />
<nowiki>**</nowiki>Funnily enough, Glide64 actually DOES have LLE code (much of it apparently comes from z64gl) and can technically run in LLE mode by using it alongside an LLE RSP plugin such as CXD4. However, it is not a complete implementation, and actually trying to run it in such a mode results in massive visual glitches, making it unusable. Practically speaking, then, Glide64 cannot be considered a true LLE plugin, and will not be designated as such, nor was it ever meant to be.<br />
<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Latest Version<br />
! scope="col"|Project64<br />
! scope="col"|Mupen64Plus<br />
! scope="col"|Libretro<br />
! scope="col"|HLE Compatible*<br />
! scope="col"|LLE Compatible*<br />
! scope="col"|Recommended<br />
|-<br />
!colspan="13"|RSP Plugins<br />
|-<br />
|Zilmar's RSP<br />
|1.7<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Mupen64Plus HLE RSP<br />
|[https://github.com/mupen64plus/mupen64plus-rsp-hle git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|Static Interpreter/CXD4<br />
|[https://github.com/cxd4/rsp git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|ParaLLEl-RSP<br />
|[https://github.com/Themaister/parallel-rsp git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Mupen64 HLE RSP<br />
|0.5.1<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|z64<br />
|r17<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|}<br />
<br />
<nowiki>*</nowiki>These terms signify whether an RSP plugin can work alongside HLE and/or LLE audio and video plugins. As for the type of emulation employed by the RSP plugins themselves, all but the Mupen64/plus HLE RSP plugins are LLE in nature. The LLE RSP plugins that can work with HLE plugins do so by passing the N64 display and audio lists onto the plugins themselves.<br />
<br />
==Video==<br />
===Currently Recommended Plugins===<br />
The following are the current best video plugins for use on modern PCs and devices.<br />
[[File:SuperMario64-Comparison.png|thumb|right|Jabo's Direct3D8 (left) compared with angrylion's RDP with OpenGL (right), while playing ''Super Mario 64''.]]<br />
====[https://github.com/Themaister/parallel-rdp ParaLLEl-RDP]====<br />
An LLE video plugin inspired by and referenced against Angrylion's RDP plugin, 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 several forks of Mupen64Plus and Project64, such as [[m64p]] and [https://www.64dd.org/downloads.html this build] of Project64. This is currently considered the best video plugin by most measures. It is almost 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 can also render at a high resolution and downsample back down to a lower one, should one wish to improve the 3D graphics without making them stick out from the often low-res 2D elements. Due to its LLE nature, it does not support widescreen hacks or high-res textures - try GLideN64 if you seek to use such features.<br />
<br />
System requirements for ParaLLEl-RDP are higher than for the other plugins. It requires a GPU with Vulkan support and up-to-date drivers (most Nvidia and AMD GPUs made after 2012 should be covered, though Intel graphics requires Skylake or newer), and upscaling increases the GPU requirements even further, far more than GLideN64. It must also be used in conjunction with an LLE RSP plugin, preferably its sister plugin ParaLLEl-RSP, as it features a recompiler for added speed. At native resolution, however, a modest PC with Vulkan support can handle it without much issue, even on integrated graphics.<br />
<br />
====[https://github.com/gonetz/GLideN64/ GLideN64]====<br />
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 z64gl and, 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 emulation of every game, gamma correction, flat and prim shading, VI emulation, and LLE graphics support. 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]], MSAA 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]].<br />
<br />
GLideN64 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.<br />
<br />
====[https://github.com/ata4/angrylion-rdp-plus/releases Angrylion RDP Plus]====<br />
This is a fork of Angrylion's RDP that supports multithreading. It 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, as does using it alongside an RSP plugin with a recompiler such as ParaLLEl-RSP, but some games are still not full speed even on a Core i7-8700K. It also allows you to disable VI filters for slightly better performance. This fork has at least one accuracy regression compared to the official version of Angrylion. 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.<br />
<br />
====Glide64====<br />
The former best general-use plugin. Versions of this are included in Project64, mainline Mupen64Plus, and the ParaLLEl-N64 libretro core. While it is no longer updated and is far less accurate and compatible than the newer offerings, it still has a few use cases, such as better support for older ROM hacks. It works relatively well for many (most?) games, has support for hi-res textures, and it is also faster than the newer plugins, which makes it suitable for slower devices such as the older Raspberry Pis. Otherwise, to ensure the highest possible compatibility, stick to either ParaLLEl-RDP or GLideN64.<br />
<br />
Note that the Project64 version of Glide64 has been renamed to Project64 Video and has undergone some changes and rewrites since it was initially forked, and thus may contain regressions compared to the last official standalone release of the plugin by Gonetz. Since this fork only works with current versions of Project64, should you wish to use this plugin on an older zilmar-spec emulator like 1964 or the original Mupen64, or if you want to avoid potential regressions with the Project64 version, use [https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/glidehqplusglitch64/Glide64_Final.zip Glide64 Final] instead.<br />
<br />
===Deprecated Plugins===<br />
The following video plugins are old and deprecated, and should not be used or considered unless you have a VERY old or underpowered device that cannot handle the recommended plugins, or there's a very specific use case not covered by modern implementations.<br />
<br />
*Jabo's Direct3D8 - Comes with Project64, and was once its default video plugin. Very speedy, has built-in AA and AF options, and includes a [[Widescreen_Hack|widescreen hack]]. The version included with the most recent versions of Project64 (1.7.0.57-ver5) is somewhat buggy and has regressions, however. [http://www.jabosoft.com/articles/114 Jabo's 1.6.1 patch] is better, though version 1.7 can run in LLE mode, which can help with a few games. Sadly, it will likely never see another update again, and though it is still included in Project64 to this day, it is no longer the default, and should not be used unless you have a very old PC that cannot handle Glide64 or GLideN64.<br />
*[http://www.emutalk.net/threads/54166-Rice-Video-Community-version Rice Video] - A very fast, highly configurable video plugin primarily based around the Direct3D API. It was once famous for being the first plugin that allowed the user to load [[Texture_Packs|custom hi-res textures]], which made 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, all aiming to fix issues or add features (one fork even featured early shader support), and forks of it are included in mainline Mupen64Plus and in the ParaLLEl-N64 libretro core. However, even during its heyday it lagged behind Glide64 and even Jabo in both compatibility and accuracy, and once Glide64 gained the ability to load custom textures, there remained little reason to use it beyond its speed. A "Community Version" popped up that aimed at improving it and fixing its issues, but it ended up introducing many regressions compared to older versions and the effort was eventually abandoned. 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) or are trying to emulate on a very old and/or severely underpowered PC or handheld device. If you are absolutely resolved to try it out, seek out the original versions by Rice, primarily 6.1.0 or 6.1.1b, and stick to the Direct3D renderer, as the OpenGL backend included in some versions is buggy and incomplete outside of the Mupen64Plus fork.<br />
*[http://www.emutalk.net/threads/40640-Z64-a-LLE-graphics-plugin z64gl] - A hardware-rendered, low-level plugin developed by ziggy, derived from MAME's N64 driver. A fork is maintained by the Mupen64Plus team, though not included in their official releases. It was once notable for being one of the only plugins that could play games without an HLE microcode implementation such as Rogue Squadron. However, it was rather glitchy, had higher system requirements than the HLE plugins, needed an LLE RSP plugin to work (such as the bundled z64 RSP or Project64's RSP plugin set to LLE graphics), and configuration required editing the config file directly. A [https://github.com/purplemarshmallow/z64/tree/angrylion-integration fork] cropped up that aimed at improving it, but it did not get very far. Nowadays, it's obsolete, as GLideN64 can now play every game through HLE (thus subverting z64gl's only selling point), and its LLE has been surpassed by Angrylion-derived plugins and even GLideN64's LLE mode.<br />
*[https://sourceforge.net/p/angrylions-stuff/code/HEAD/tree/ Official Angrylion RDP] - A software-rendered, hardware-accurate plugin, developed by angrylion (though derived from MAME, much like z64gl). This is the most accurate N64 video plugin in existence, emulating almost* every facet of the N64's RDP precisely and thus making it capable of playing almost every single game in the N64 library with no issues, fixing even notorious cases such as the ''Pokémon Snap'' red dot and the ''Body Harvest'' bridge. This, however, comes at the cost of insane CPU requirements while making games look like, well, N64 games running on real hardware, which means native resolution, no widescreen, no hi-res textures - just the N64 in its full, vaseline-covered glory. Since this particular version is single-threaded, uses DirectDraw and is Windows only, it is recommended to use Angrylion RDP Plus or ParaLLEl-RDP instead, which offer much more reasonable performance. Only try it out if you have a tricked-out rig and want to test your CPU's mettle, or if you can compile it from source and need it for testing/debugging purposes, as the latest updates are always made to this version first.<br />
*[http://www.emutalk.net/threads/55481-angrylion-s-Per-Pixel-RDP-with-OpenGL HatCat/angrylion's Pixel-Accurate N64 Plugin] - This is a fork of Angrylion's RDP, done by HatCat. It has some optimizations not present in the official code, but is outdated and lacking some accuracy improvements and optimizations written by Angrylion. It has the option to disable the VI filters (which gives a speed boost), as well as the ability to set custom resolutions. Also, this version uses OpenGL 1.x instead of Direct Draw and supports Linux. Obsoleted by newer forks such as Angrylion RDP Plus.<br />
<br />
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:<br />
<br />
<gallery widths="300" mode="packed"><br />
Mario Tennis Rice.png|Mario Tennis running on ParaLLEl-N64 using Rice. Missing various effects, heavily glitched court.<br />
Mario Tennis Glide64.png|Mario Tennis running on ParaLLEl-N64 using Glide64. Missing various effects and shadows, some glitches.<br />
Mario Tennis glN64.png|Mario Tennis running on ParaLLEl-N64 using glN64. Missing various effects; shadows are present, but glitched.<br />
Mario Tennis GLideN64 HLE.png|Mario Tennis running on Mupen64Plus-Next using GLideN64 in HLE mode with 16xMSAA. Minor text cutoff on bottom of scoreboard.<br />
Mario Tennis GLideN64 LLE.png|Mario Tennis running on Mupen64Plus-Next using GLideN64 in LLE mode with 16xMSAA. Minor text cutoff on bottom of scoreboard. Has slight polygon jitter not present in HLE.<br />
Mario Tennis ParaLLEl 1x.png|Mario Tennis running on Mupen64Plus-Next using ParaLLEl-RDP at native resolution. Identical to Angrylion, and thus a pixel-perfect representation of real hardware.<br />
Mario Tennis ParaLLEl 4x Downsampled.png|Mario Tennis running on Mupen64Plus-Next using ParaLLEl-RDP rendering at 4x resolution, then downsampled back to native resolution.<br />
Mario Tennis ParaLLEl 4x.png|Mario Tennis running on Mupen64Plus-Next using ParaLLEl-RDP rendering at 4x resolution. Has very slight polygon jitter, though less than GLideN64 in LLE.<br />
</gallery><br />
<br />
<nowiki>*</nowiki> There is at least [https://sourceforge.net/p/angrylions-stuff/tickets/10/ one known, relatively minor graphical glitch in Pokemon Snap] (go figure) using Angrylion that requires currently-unimplemented cycle-accurate behavior to fix without resorting to hacks.<br />
<br />
==Audio==<br />
This section will only cover the zilmar spec plugins, as Mupen64Plus does not have any alternative audio plugins besides the default, and neither do the libretro forks.<br />
<br />
*Project64 Audio - The default audio plugin for Project64, apparently loosely based off of code from Mupen64Plus's HLE RSP. Very barebones, with no options to speak off.<br />
*Jabo's DirectSound - Comes with Project64. It works fine for the most part, but some games may not play nice with it. It is a low-level plugin, so it needs an accompanying LLE RSP plugin. Will probably never be updated again.<br />
*[http://www.emutalk.net/threads/27610-Audio-v0-56-WIP2-Download-Feedback Azimer's HLE Audio] - This popular HLE audio plugin boasts high compatibility. Version 0.56WIP2 is old as hell, but it is the tried and true standard to which audio plugins are compared against. Recently, [https://github.com/Azimer/AziAudio Azimer open sourced his plugin], and there were plans to integrate it into Project64, though this has yet to happen. While the latest development versions have a few issues, it now works in LLE, and has integrated code from Mupen64Plus's HLE RSP plugin, allowing it to work with the Factor 5 and BOSS games even in HLE.<br />
*[http://forum.pj64-emu.com/showthread.php?t=3644 Shunyuan's HLE Audio] - An audio plugin, apparently based on 1964Audio and HatCat's RSP plugin. Can run in both LLE and HLE modes despite the name, though the HLE mode just makes it run an outdated, baked-in version of HatCat's RSP, which makes it not a true HLE plugin. Has been abandoned after charges of just taking others' code without revealing a source. If games run at a weird speed using this plugin, go to the ROM's Game Settings, and disable Fixed Audio Timing and Sync using Audio. Though it worked surprisingly well despite its Frankenstein nature, modern development versions of Project64 no longer work with it, apparently due to it depending on a bug that has now been fixed. As such, it is probably better to use Azimer's plugin instead.<br />
<br />
==Input==<br />
*Project64 Input - Comes with Project64 as of the latest versions. Very simple input plugin which looks suspiciously a lot like Jabo's, but at least has XInput support, which is nice.<br />
*[https://sourceforge.net/projects/nragev20/ NRage Input] - Also comes with Project64 as of version 2.2. Hands down the best input plugin as it is more feature complete than Jabo's DirectInput. Has a ton of options and great controller compatibility, including XInput support for use with Xbox 360 controllers. It can't emulate the microphone that is required by ''Hey You, Pikachu'' or the printer required for the ''Pokémon Snap Station''. It has the ability to emulate Controller Pak (''Mario Kart 64'''s ghost saves), Rumble Pak (''Star Fox 64''), and Transfer Pak (''Pokémon Stadium'' series) functionality fairly well. Version 2.3 of Project64 introduced a version of the plug-in that can emulate the N64's mouse accessory designed for the 64DD to coincide with Project64's newest ability to emulate the 64DD accessory. Surprisingly, ''Mario Artist: Paint Studio'' can use the Japanese ''Game Boy Camera'' (called ''Pocket Camera'') in Transfer Pak mode, but the camera function doesn't work as it displays static, although importing captured images still works technically.<br />
*Jabo's DirectInput - Used to come with Project64, but now removed in favor of NRage Input. It isn't too bad, 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 usual, do not expect any updates.<br />
*[https://www.raphnet-tech.com/products/raphnetraw/index.php/ Raphnetraw] - This open source plugin allows streamlined use of N64 controller(s) via raphnet [https://www.raphnet-tech.com/products/n64_usb_adapter_gen3/index.php N64-to-USB v3+ adapters]. It supports rumble and is available for Project64 and mupen64plus. Also contains various DLLs for special port arrangements [https://www.raphnet.net/programmation/mupen64plus-input-raphnetraw/index_en.php#4 (link)].<br />
<br />
==RSP==<br />
===Recommended Plugins===<br />
*Zilmar's RSP - Comes with Project64. Reasonably accurate, quite fast in Recompiler mode (enabled by default), and will work fine for the 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.<br />
*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. 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 work with Jabo's, as that is a pure LLE audio plugin and requires LLE RSP emulation.<br />
*[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 one of the most accurate RSP plugins, though zilmar's RSP in Recompiler mode as well as ParaLLEl-RSP both trump it in speed. It can take advantage of SSSE3 for greater performance, though it also comes in SSE2 and non-SSE variations in case your PC does not support those instruction sets. In both the zilmar and Mupen64Plus versions (though not in libretro, it seems), it is capable of working with both HLE and LLE audio and video plugins via the following settings:<br />
**Simulate RSP graphics from external plugin - Check if using an HLE graphics plugin, uncheck if using LLE<br />
**Simulate RSP audio from external plugin - Check if using an HLE audio plugin, uncheck if using LLE<br />
**Force semaphore locking - Check to fix issues with Mario no Photopie. Only works with Project64 2.x and beyond.<br />
*ParaLLEl-RSP - A fast and accurate RSP written by [https://github.com/Themaister/parallel-rsp Themaister], though it borrows heavily from both CXD4 and CEN64's RSP code. It is about as accurate and compatible as the Static Interpreter/CXD4 RSP, while being much faster owing to its inclusion of a dynamic recompiler. 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). Note that it only works with LLE video and audio plugins, though it is highly recommended if using such.<br />
<br />
===Deprecated Plugins===<br />
*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 and many other compatibility fixes were later added to the Mupen64Plus version, which has now been ported to the zilmar spec after years of exclusivity on the Mupen64Plus side of things. As such, this version is officially obsolete.<br />
*z64 RSP plugin pack - Largely deprecated by the Static Interpreter/CXD4 RSP plugin. This set of RSP plugins comes with the z64 video plugin, each with their own purpose:<br />
**Ziggy-z64RSP - This RSP is based on the MAME/MESS RSP code. It is slower but more accurate.<br />
**Ziggy-PJ64 - Based on the Project64 1.4 RSP, this plugin is much faster.<br />
**angrylion - This RSP is a simple Interpreter, and is required for a few games like World Driver Championship to work correctly with z64gl.<br />
<br />
==Recommended N64 Setups==<br />
<br />
===Project64 and Others===<br />
Project64 comes bundled with the following plugins:<br />
*Video: Jabo's Direct3D8, Project64 Video (Glide64 under another name), GLideN64<br />
*Audio: Jabo's DirectSound, Project64 Audio<br />
*Input: NRage for Project64, Project64 Input<br />
*RSP: zilmar's RSP<br />
Should you wish to use other plugins, they must be downloaded from a third party source and dropped into their respective plugin folder categories in the Project64 directory. Video plugins go under Plugin/GFX, audio plugins under Plugin/Audio, etc.<br />
<br />
*'''General Use'''<br />
**GLideN64<br />
**Azimer's Audio NEW (set to LLE)<br />
**Static Interpreter RSP or Zilmar's RSP<br />
**Either of the RSP plugins should be fine for most games. The Static Interpreter RSP is slightly more accurate, whereas zilmar's is much faster. Should you wish to use GLideN64 in LLE mode (or any LLE video plugin for that matter), if using zilmar's RSP, simply uncheck "Graphics HLE" in the Plugin configuration screen. If using the Static Interpreter RSP, you'll have to run the spconfig.exe that comes with that plugin, and tell it to NOT "simulate RSP graphics from external plugin" (in other words, type "0"). ParaLLEl-RSP only works in LLE, so GLideN64's HLE mode will be unavailable with that plugin.<br />
*'''Best Performance'''<br />
**Project64 Video or Glide64 Final<br />
**Azimer's HLE Audio<br />
**Zilmar's RSP or Mupen64Plus HLE RSP<br />
**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. Recommended for the older zilmar-spec emulators as well (replace Project64 Video with Glide64 Final for those, though you may want to do that even with Project64 should you run into a regression). 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.<br />
*'''Accuracy'''<br />
**Angrylion RDP Plus<br />
**Azimer's Audio NEW<br />
**Static RSP Interpreter<br />
**If you have a decent quad-core CPU, you can run many N64 games with pixel-perfect graphics at full speed, thanks to the new multithreaded version of angrylion's software plugin. The new Azimer's plugin (still WIP) works good in LLE. Since there's almost no visual difference, you may as well use PJ64's RSP or ParaLLEl-RSP to get better performance, and/or move to ParaLLEl-RDP outright for even greater speed and upscaling options to boot (though it goes without saying upscaling would no longer be accurate). Conversely, if you want even greater accuracy, disable "Hide advanced settings" under Configuration, then enable "Always use interpreter core" under Advanced, and under Angrylion's options, disable multi-threading and set compatibility to "Slow". Performance WILL crash, but hey, it'll be accurate!<br />
<br />
===Mupen64Plus===<br />
The official releases of Mupen64Plus only come bundled with a handful of video and RSP plugins, namely Glide64mk2, Rice, and the HLE RSP. The developers also maintain forks of the CXD4 RSP and the z64 video and RSP plugins, but they are not included in the official release bundles for some reason. Should you wish to use those plugins or third party ones such as GLideN64 or the ParaLLEl plugins, you must build them yourself or get them from outside sources. Due to this fact, the mediocre nature of the "official" video plugins, and the overall lack of user-friendliness, it may be better to use a fork such as [[m64p]] or [[RMG]], though note that m64p only comes and works with the ParaLLEl plugins, so RMG is a better choice if you wish to use something else, as that comes with more plugins and allows you to use whichever ones you want.<br />
*'''General Use'''<br />
**Video: GLideN64 or ParaLLEl-RDP<br />
**RSP: RSP-HLE (for GLideN64) or ParaLLEl-RSP (for ParaLLEl-RDP)<br />
**Either one of these combinations will enable you to play the vast majority of N64 games while having reasonable system requirements. GLideN64 is faster and has more enhancement options, but ParaLLEl-RDP is much more accurate to the real console. You can also use the CXD4 RSP with GLideN64 if you want, but be sure to set it to pass display lists to the graphics plugin in mupen64plus.cfg, else GLideN64 will switch to its LLE mode, which is not generally recommended to use.<br />
*'''Best Performance'''<br />
**Video: Glide64mk2<br />
**RSP: RSP-HLE<br />
**These are Mupen64Plus's default plugins. Glide64mk2 is based on Glide64 Final, and is named so as to differentiate it from the original, now obsolete fork of Glide64 that Mupen64Plus used at its inception. It is not up to GLideN64's level, but it does well enough for many games and is quite fast. Use this combination if you have a lower end PC that can't handle the General Use setup. If your device STILL can't handle this setup, try the Rice video plugin, but expect many missing effects, glitches and incompatibilities.<br />
*'''Accuracy'''<br />
**Video: Angrylion Plus or ParaLLEl-RDP<br />
**RSP: CXD4-ssse3 or ParaLLEl-RSP<br />
**Any combination of these should result in very high accuracy. Technically, the most accurate setup is Angrylion combined with CXD4, but the difference between these and the ParaLLEl plugins is almost negligible, while being a lot slower. Be sure to set the CPU core to Pure Interpreter for even greater accuracy, along with plummeting framerates.<br />
<br />
Note: In some cases the cfg file may not appear, in which case you may do this:<br />
*Open terminal in emulator folder on in its respective directory<br />
*''mupen64plus --configdir'' /directory/where/you/want/it/to/be<br />
<br />
===Libretro===<br />
There are two N64 libretro emulator cores for use on libretro frontends such as [[RetroArch]]: Mupen64Plus-Next and ParaLLEl-N64. The former is up-to-date and is recommended for most use cases, while the latter is no longer updated and is only around for performance reasons. They also have access to the following plugins:<br />
*Shared by both cores<br />
**Video: ParaLLEl-RDP , Angrylion<br />
**RSP: ParaLLEl-RSP, HLE, CXD4<br />
*Exclusive to Mupen64Plus-Next<br />
**GLideN64<br />
*Exclusive to ParaLLEl-N64<br />
**glN64, Rice, Glide64<br />
Due to these differences, it is advisable to use Mupen64Plus-Next for general use, and ParaLLEl-N64 for performance.<br />
*'''General Use (LLE)'''<br />
**Core: Mupen64Plus-Next<br />
**Video: ParaLLEl-RDP<br />
**RSP: ParaLLEl-RSP<br />
**By default ParaLLEl-RDP will output at native resolution with all the VI filters on, making it look exactly like Angrylion and the real N64 console. Upscaling must therefore be enabled in the core options. You can also alternatively render at a high resolution and downsample to a lower one if you want to improve 3D without making it stick out from 2D elements too much.<br />
*'''General Use (HLE)'''<br />
**Core: Mupen64Plus-Next<br />
**Video: GLideN64<br />
**RSP: HLE<br />
**While GLideN64 also works with the ParaLLEl and CXD4 RSP plugins, using them will cause GLideN64 to switch to its LLE mode, which is currently glitchier and slower than the HLE mode, for few compatibility or accuracy benefits, if any. As such, it is recommended to stick with the HLE RSP for GLideN64.<br />
*'''Best Performance'''<br />
**Core: ParaLLEl-N64<br />
**Video: Glide64<br />
**RSP: HLE<br />
**For slow, low-end devices and old PCs only. If further speed is desired or needed, you may try glN64 or Rice, but using them comes at a steep cost in compatibility and accuracy, and many low-end devices in use today ought to be able to handle Glide64 just fine (well, with the exception of certain underpowered "retro gaming" handhelds).<br />
*'''Accuracy'''<br />
**Core: Mupen64Plus-Next<br />
**Video: Angrylion<br />
**RSP: CXD4<br />
**Just like the developers intended! If you want to go all out, set the CPU core to Pure Interpreter, turn off multi-threading and set thread sync level to High in Angrylion's options for the real 30 VI/s experience. Closest you'll get to real hardware until a complete cycle-accurate N64 emulator surfaces.<br />
<br />
[[Category:Recommendations]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Recommended_N64_plugins&diff=48522Recommended N64 plugins2022-07-17T21:03:51Z<p>GPDP1: Rewrote portions of Rice Video section, added a few other tidbits elsewhere</p>
<hr />
<div>The N64 emulation scene had previously been described as a broken mess, the very definition of plugin hell. With recent developments in the scene, however, the situation has markedly improved, and it is no longer considered necessary to have multiple emulators and plugins on hand to get most games to work. This page will outline the best plugins currently available for the benefit of both the casual and enthusiast looking to get their N64 emulation fix.<br />
<br />
==The Plugin Specs==<br />
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.<br />
<br />
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.<br />
<br />
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. Unsurprisingly, this situation often led to a lot of confusion from users, who often wondered why there were so many plugins, and which ones were the best to use, only to find out it often depended on the game, and even then, some games would refuse to work as intended no matter what was tried. Hence the label "plugin hell" was coined, and stuck as a description of the travails of trying to emulate N64 games well into the 2010's.<br />
<br />
However, as time went on, things began to change, though 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.<br />
<br />
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 changes and 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) video plugin there is but was initially only available for the zilmar spec, was ported to Mupen64Plus and integrated into 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.<br />
<br />
All that said, the issue is that there are now three plugin standards to account for:<br />
<br />
*The zilmar spec - Utilized by Project64 and most other legacy emulators; only Project64 still uses it today.*<br />
<br />
*The Mupen64Plus spec - Utilized by Mupen64Plus and most of its forks.<br />
<br />
*Libretro - Not really a spec per se, as the plugins are integrated directly into the libretro core, so there's no DLL files to download or add.<br />
<br />
As of right now, not all plugins are readily available on all three. Consult the tables below for reference:<br />
<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Latest Version<br />
! scope="col"|Project64<br />
! scope="col"|Mupen64Plus<br />
! scope="col"|Libretro<br />
! scope="col"|HLE<br />
! scope="col"|LLE<br />
! scope="col"|Widescreen Hack<br />
! scope="col"|Custom Texture Packs<br />
! scope="col"|Recommended<br />
|-<br />
!colspan="13"|Video Plugins<br />
|-<br />
|ParaLLEl-RDP<br />
|[https://github.com/Themaister/parallel-rdp git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|GLideN64<br />
|[https://github.com/gonetz/GLideN64/releases/tag/github-actions github-actions]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Angrylion RDP Plus<br />
|[https://github.com/ata4/angrylion-rdp-plus/releases/tag/v1.6 1.6]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|Glide64**<br />
|Final<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|Jabo's Direct3D8<br />
|1.7.0.57-ver5<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Rice Video<br />
|0.4.4<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|glN64<br />
|0.4.1<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|z64gl<br />
|R17<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Angrylion (Official)<br />
|r114<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|}<br />
<br />
<nowiki>*</nowiki>It should be noted that Project64 after version 2.x made some changes to the zilmar plugin spec, and while it remains backwards compatible with the older version of the spec (meaning most older plugins will still work with Project64), plugins targeting the newer version will not work on older versions of Project64 or other zilmar spec-based emulators.<br />
<br />
<nowiki>**</nowiki>Funnily enough, Glide64 actually DOES have LLE code (much of it apparently comes from z64gl) and can technically run in LLE mode by using it alongside an LLE RSP plugin such as CXD4. However, it is not a complete implementation, and actually trying to run it in such a mode results in massive visual glitches, making it unusable. Practically speaking, then, Glide64 cannot be considered a true LLE plugin, and will not be designated as such, nor was it ever meant to be.<br />
<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Latest Version<br />
! scope="col"|Project64<br />
! scope="col"|Mupen64Plus<br />
! scope="col"|Libretro<br />
! scope="col"|HLE Compatible*<br />
! scope="col"|LLE Compatible*<br />
! scope="col"|Recommended<br />
|-<br />
!colspan="13"|RSP Plugins<br />
|-<br />
|Zilmar's RSP<br />
|1.7<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Mupen64Plus HLE RSP<br />
|[https://github.com/mupen64plus/mupen64plus-rsp-hle git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|Static Interpreter/CXD4<br />
|[https://github.com/cxd4/rsp git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|ParaLLEl-RSP<br />
|[https://github.com/Themaister/parallel-rsp git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Mupen64 HLE RSP<br />
|0.5.1<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|z64<br />
|r17<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|}<br />
<br />
<nowiki>*</nowiki>These terms signify whether an RSP plugin can work alongside HLE and/or LLE audio and video plugins. As for the type of emulation employed by the RSP plugins themselves, all but the Mupen64/plus HLE RSP plugins are LLE in nature. The LLE RSP plugins that can work with HLE plugins do so by passing the N64 display and audio lists onto the plugins themselves.<br />
<br />
==Video==<br />
===Currently Recommended Plugins===<br />
The following are the current best video plugins for use on modern PCs and devices.<br />
[[File:SuperMario64-Comparison.png|thumb|right|Jabo's Direct3D8 (left) compared with angrylion's RDP with OpenGL (right), while playing ''Super Mario 64''.]]<br />
====[https://github.com/Themaister/parallel-rdp ParaLLEl-RDP]====<br />
An LLE video plugin inspired by and referenced against Angrylion's RDP plugin, 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 several forks of Mupen64Plus and Project64, such as [[m64p]] and [https://www.64dd.org/downloads.html this build] of Project64. This is currently considered the best video plugin by most measures. It is almost 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 can also render at a high resolution and downsample back down to a lower one, should one wish to improve the 3D graphics without making them stick out from the often low-res 2D elements. Due to its LLE nature, it does not support widescreen hacks or high-res textures - try GLideN64 if you seek to use such features.<br />
<br />
System requirements for ParaLLEl-RDP are higher than for the other plugins. It requires a GPU with Vulkan support and up-to-date drivers (most Nvidia and AMD GPUs made after 2012 should be covered, though Intel graphics requires Skylake or newer), and upscaling increases the GPU requirements even further, far more than GLideN64. It must also be used in conjunction with an LLE RSP plugin, preferably its sister plugin ParaLLEl-RSP, as it features a recompiler for added speed. At native resolution, however, a modest PC with Vulkan support can handle it without much issue, even on integrated graphics.<br />
<br />
====[https://github.com/gonetz/GLideN64/ GLideN64]====<br />
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 z64gl and, 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 emulation of every game, gamma correction, flat and prim shading, VI emulation, and LLE graphics support. 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]], MSAA 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]].<br />
<br />
GLideN64 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.<br />
<br />
====[https://github.com/ata4/angrylion-rdp-plus/releases Angrylion RDP Plus]====<br />
This is a fork of Angrylion's RDP that supports multithreading. It 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, as does using it alongside an RSP plugin with a recompiler such as ParaLLEl-RSP, but some games are still not full speed even on a Core i7-8700K. It also allows you to disable VI filters for slightly better performance. This fork has at least one accuracy regression compared to the official version of Angrylion. 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.<br />
<br />
====Glide64====<br />
The former best general-use plugin. Versions of this are included in Project64, mainline Mupen64Plus, and the ParaLLEl-N64 libretro core. While it is no longer updated and is far less accurate and compatible than the newer offerings, it still has a few use cases, such as better support for older ROM hacks. It works relatively well for many (most?) games, has support for hi-res textures, and it is also faster than the newer plugins, which makes it suitable for slower devices such as the older Raspberry Pis. Otherwise, to ensure the highest possible compatibility, stick to either ParaLLEl-RDP or GLideN64.<br />
<br />
Note that the Project64 version of Glide64 has been renamed to Project64 Video and has undergone some changes and rewrites since it was initially forked, and thus may contain regressions compared to the last official standalone release of the plugin by Gonetz. Since this fork only works with current versions of Project64, should you wish to use this plugin on an older zilmar-spec emulator like 1964 or the original Mupen64, or if you want to avoid potential regressions with the Project64 version, use [https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/glidehqplusglitch64/Glide64_Final.zip Glide64 Final] instead.<br />
<br />
===Deprecated Plugins===<br />
The following video plugins are old and deprecated, and should not be used or considered unless you have a VERY old or underpowered device that cannot handle the recommended plugins, or there's a very specific use case not covered by modern implementations.<br />
<br />
*Jabo's Direct3D8 - Comes with Project64, and was once its default video plugin. Very speedy, has built-in AA and AF options, and includes a [[Widescreen_Hack|widescreen hack]]. The version included with the most recent versions of Project64 (1.7.0.57-ver5) is somewhat buggy and has regressions, however. [http://www.jabosoft.com/articles/114 Jabo's 1.6.1 patch] is better, though version 1.7 can run in LLE mode, which can help with a few games. Sadly, it will likely never see another update again, and though it is still included in Project64 to this day, it is no longer the default, and should not be used unless you have a very old PC that cannot handle Glide64 or GLideN64.<br />
*[http://www.emutalk.net/threads/54166-Rice-Video-Community-version Rice Video] - A very fast, highly configurable video plugin primarily based around the Direct3D API. It was once famous for being the first plugin that allowed the user to load [[Texture_Packs|custom hi-res textures]], which made 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, all aiming to fix issues or add features (one fork even featured early shader support), and forks of it are included in mainline Mupen64Plus and in the ParaLLEl-N64 libretro core. However, even during its heyday it lagged behind Glide64 and even Jabo in both compatibility and accuracy, and once Glide64 gained the ability to load custom textures, there remained little reason to use it beyond its speed. A "Community Version" popped up that aimed at improving it and fixing its issues, but it ended up introducing many regressions compared to older versions and the effort was eventually abandoned. 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) or are trying to emulate on a very old and/or severely underpowered PC or handheld device. If you are absolutely resolved to try it out, seek out the original versions by Rice, primarily 6.1.0 or 6.1.1b, and stick to the Direct3D renderer, as the OpenGL backend included in some versions is buggy and incomplete outside of the Mupen64Plus fork.<br />
*[http://www.emutalk.net/threads/40640-Z64-a-LLE-graphics-plugin z64gl] - A hardware-rendered, low-level plugin developed by ziggy, derived from MAME's N64 driver. A fork is maintained by the Mupen64Plus team, though not included in their official releases. It was once notable for being one of the only plugins that could play games without an HLE microcode implementation such as Rogue Squadron. However, it was rather glitchy, had higher system requirements than the HLE plugins, needed an LLE RSP plugin to work (such as the bundled z64 RSP or Project64's RSP plugin set to LLE graphics), and configuration required editing the config file directly. A [https://github.com/purplemarshmallow/z64/tree/angrylion-integration fork] cropped up that aimed at improving it, but it did not get very far. Nowadays, it's obsolete, as GLideN64 can now play every game through HLE (thus subverting z64gl's only selling point), and its LLE has been surpassed by Angrylion-derived plugins and even GLideN64's LLE mode.<br />
*[https://sourceforge.net/p/angrylions-stuff/code/HEAD/tree/ Official Angrylion RDP] - A software-rendered, hardware-accurate plugin, developed by angrylion (though derived from MAME, much like z64gl). This is the most accurate N64 video plugin in existence, emulating almost* every facet of the N64's RDP precisely and thus making it capable of playing almost every single game in the N64 library with no issues, fixing even notorious cases such as the ''Pokémon Snap'' red dot and the ''Body Harvest'' bridge. This, however, comes at the cost of insane CPU requirements while making games look like, well, N64 games running on real hardware, which means native resolution, no widescreen, no hi-res textures - just the N64 in its full, vaseline-covered glory. Since this particular version is single-threaded, uses DirectDraw and is Windows only, it is recommended to use Angrylion RDP Plus or ParaLLEl-RDP instead, which offer much more reasonable performance. Only try it out if you have a tricked-out rig and want to test your CPU's mettle, or if you can compile it from source and need it for testing/debugging purposes, as the latest updates are always made to this version first.<br />
*[http://www.emutalk.net/threads/55481-angrylion-s-Per-Pixel-RDP-with-OpenGL HatCat/angrylion's Pixel-Accurate N64 Plugin] - This is a fork of Angrylion's RDP, done by HatCat. It has some optimizations not present in the official code, but is outdated and lacking some accuracy improvements and optimizations written by Angrylion. It has the option to disable the VI filters (which gives a speed boost), as well as the ability to set custom resolutions. Also, this version uses OpenGL 1.x instead of Direct Draw and supports Linux. Obsoleted by newer forks such as Angrylion RDP Plus.<br />
<br />
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:<br />
<br />
<gallery widths="300" mode="packed"><br />
Mario Tennis Rice.png|Mario Tennis running on ParaLLEl-N64 using Rice. Missing various effects, heavily glitched court.<br />
Mario Tennis Glide64.png|Mario Tennis running on ParaLLEl-N64 using Glide64. Missing various effects and shadows, some glitches.<br />
Mario Tennis glN64.png|Mario Tennis running on ParaLLEl-N64 using glN64. Missing various effects; shadows are present, but glitched.<br />
Mario Tennis GLideN64 HLE.png|Mario Tennis running on Mupen64Plus-Next using GLideN64 in HLE mode with 16xMSAA. Minor text cutoff on bottom of scoreboard.<br />
Mario Tennis GLideN64 LLE.png|Mario Tennis running on Mupen64Plus-Next using GLideN64 in LLE mode with 16xMSAA. Minor text cutoff on bottom of scoreboard. Has slight polygon jitter not present in HLE.<br />
Mario Tennis ParaLLEl 1x.png|Mario Tennis running on Mupen64Plus-Next using ParaLLEl-RDP at native resolution. Identical to Angrylion, and thus a pixel-perfect representation of real hardware.<br />
Mario Tennis ParaLLEl 4x Downsampled.png|Mario Tennis running on Mupen64Plus-Next using ParaLLEl-RDP rendering at 4x resolution, then downsampled back to native resolution.<br />
Mario Tennis ParaLLEl 4x.png|Mario Tennis running on Mupen64Plus-Next using ParaLLEl-RDP rendering at 4x resolution. Has very slight polygon jitter, though less than GLideN64 in LLE.<br />
</gallery><br />
<br />
<nowiki>*</nowiki> There is at least [https://sourceforge.net/p/angrylions-stuff/tickets/10/ one known, relatively minor graphical glitch in Pokemon Snap] (go figure) using Angrylion that requires currently-unimplemented cycle-accurate behavior to fix without resorting to hacks.<br />
<br />
==Audio==<br />
This section will only cover the zilmar spec plugins, as Mupen64Plus does not have any alternative audio plugins besides the default, and neither do the libretro forks.<br />
<br />
*Project64 Audio - The default audio plugin for Project64, apparently loosely based off of code from Mupen64Plus's HLE RSP. Very barebones, with no options to speak off.<br />
*Jabo's DirectSound - Comes with Project64. It works fine for the most part, but some games may not play nice with it. It is a low-level plugin, so it needs an accompanying LLE RSP plugin. Will probably never be updated again.<br />
*[http://www.emutalk.net/threads/27610-Audio-v0-56-WIP2-Download-Feedback Azimer's HLE Audio] - This popular HLE audio plugin boasts high compatibility. Version 0.56WIP2 is old as hell, but it is the tried and true standard to which audio plugins are compared against. Recently, [https://github.com/Azimer/AziAudio Azimer open sourced his plugin], and there were plans to integrate it into Project64, though this has yet to happen. While the latest development versions have a few issues, it now works in LLE, and has integrated code from Mupen64Plus's HLE RSP plugin, allowing it to work with the Factor 5 and BOSS games even in HLE.<br />
*[http://forum.pj64-emu.com/showthread.php?t=3644 Shunyuan's HLE Audio] - An audio plugin, apparently based on 1964Audio and HatCat's RSP plugin. Can run in both LLE and HLE modes despite the name, though the HLE mode just makes it run an outdated, baked-in version of HatCat's RSP, which makes it not a true HLE plugin. Has been abandoned after charges of just taking others' code without revealing a source. If games run at a weird speed using this plugin, go to the ROM's Game Settings, and disable Fixed Audio Timing and Sync using Audio. Though it worked surprisingly well despite its Frankenstein nature, modern development versions of Project64 no longer work with it, apparently due to it depending on a bug that has now been fixed. As such, it is probably better to use Azimer's plugin instead.<br />
<br />
==Input==<br />
*Project64 Input - Comes with Project64 as of the latest versions. Very simple input plugin which looks suspiciously a lot like Jabo's, but at least has XInput support, which is nice.<br />
*[https://sourceforge.net/projects/nragev20/ NRage Input] - Also comes with Project64 as of version 2.2. Hands down the best input plugin as it is more feature complete than Jabo's DirectInput. Has a ton of options and great controller compatibility, including XInput support for use with Xbox 360 controllers. It can't emulate the microphone that is required by ''Hey You, Pikachu'' or the printer required for the ''Pokémon Snap Station''. It has the ability to emulate Controller Pak (''Mario Kart 64'''s ghost saves), Rumble Pak (''Star Fox 64''), and Transfer Pak (''Pokémon Stadium'' series) functionality fairly well. Version 2.3 of Project64 introduced a version of the plug-in that can emulate the N64's mouse accessory designed for the 64DD to coincide with Project64's newest ability to emulate the 64DD accessory. Surprisingly, ''Mario Artist: Paint Studio'' can use the Japanese ''Game Boy Camera'' (called ''Pocket Camera'') in Transfer Pak mode, but the camera function doesn't work as it displays static, although importing captured images still works technically.<br />
*Jabo's DirectInput - Used to come with Project64, but now removed in favor of NRage Input. It isn't too bad, 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 usual, do not expect any updates.<br />
*[https://www.raphnet-tech.com/products/raphnetraw/index.php/ Raphnetraw] - This open source plugin allows streamlined use of N64 controller(s) via raphnet [https://www.raphnet-tech.com/products/n64_usb_adapter_gen3/index.php N64-to-USB v3+ adapters]. It supports rumble and is available for Project64 and mupen64plus. Also contains various DLLs for special port arrangements [https://www.raphnet.net/programmation/mupen64plus-input-raphnetraw/index_en.php#4 (link)].<br />
<br />
==RSP==<br />
===Recommended Plugins===<br />
*Zilmar's RSP - Comes with Project64. Reasonably accurate, quite fast in Recompiler mode (enabled by default), and will work fine for the 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.<br />
*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. 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 a pure LLE audio plugin and requires LLE RSP emulation.<br />
*[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 one of the most accurate RSP plugins, though zilmar's RSP in Recompiler mode as well as ParaLLEl-RSP both trump it in speed. It can take advantage of SSSE3 for greater performance, though it also comes in SSE2 and non-SSE variations in case your PC does not support those instruction sets. In both the zilmar and Mupen64Plus versions (though not in libretro, it seems), it is capable of working with both HLE and LLE audio and video plugins via the following settings:<br />
**Simulate RSP graphics from external plugin - Check if using an HLE graphics plugin, uncheck if using LLE<br />
**Simulate RSP audio from external plugin - Check if using an HLE audio plugin, uncheck if using LLE<br />
**Force semaphore locking - Check to fix issues with Mario no Photopie. Only works with Project64 2.x and beyond.<br />
*ParaLLEl-RSP - A fast and accurate RSP written by [https://github.com/Themaister/parallel-rsp Themaister], though it borrows heavily from both CXD4 and CEN64's RSP code. It is about as accurate and compatible as CXD4, while being much faster owing to its inclusion of a dynamic recompiler. 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). Note that it only works with LLE video and audio plugins, though it is highly recommended if using such.<br />
<br />
===Deprecated Plugins===<br />
*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 and many other compatibility fixes were later added to the Mupen64Plus version, which has now been ported to the zilmar spec after years of exclusivity on the Mupen64Plus side of things. As such, this version is officially obsolete.<br />
*z64 RSP plugin pack - Largely deprecated by the Static Interpreter/CXD4 RSP plugin. This set of RSP plugins comes with the z64 video plugin, each with their own purpose:<br />
**Ziggy-z64RSP - This RSP is based on the MAME/MESS RSP code. It is slower but more accurate.<br />
**Ziggy-PJ64 - Based on the Project64 1.4 RSP, this plugin is much faster.<br />
**angrylion - This RSP is a simple Interpreter, and is required for a few games like World Driver Championship to work correctly with z64gl.<br />
<br />
==Recommended N64 Setups==<br />
<br />
===Project64 and Others===<br />
Project64 comes bundled with the following plugins:<br />
*Video: Jabo's Direct3D8, Project64 Video (Glide64 under another name), GLideN64<br />
*Audio: Jabo's DirectSound, Project64 Audio<br />
*Input: NRage for Project64, Project64 Input<br />
*RSP: zilmar's RSP<br />
Should you wish to use other plugins, they must be downloaded from a third party source and dropped into their respective plugin folder categories in the Project64 directory. Video plugins go under Plugin/GFX, audio plugins under Plugin/Audio, etc.<br />
<br />
*'''General Use'''<br />
**GLideN64<br />
**Azimer's Audio NEW (set to LLE)<br />
**Static Interpreter RSP or Zilmar's RSP<br />
**Either of the RSP plugins should be fine for most games. The Static Interpreter RSP is slightly more accurate, whereas zilmar's is much faster. Should you wish to use GLideN64 in LLE mode (or any LLE video plugin for that matter), if using zilmar's RSP, simply uncheck "Graphics HLE" in the Plugin configuration screen. If using the Static Interpreter RSP, you'll have to run the spconfig.exe that comes with that plugin, and tell it to NOT "simulate RSP graphics from external plugin" (in other words, type "0"). ParaLLEl-RSP only works in LLE, so GLideN64's HLE mode will be unavailable with that plugin.<br />
*'''Best Performance'''<br />
**Project64 Video or Glide64 Final<br />
**Azimer's HLE Audio<br />
**Zilmar's RSP or Mupen64Plus HLE RSP<br />
**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. Recommended for the older zilmar-spec emulators as well (replace Project64 Video with Glide64 Final for those, though you may want to do that even with Project64 should you run into a regression). 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.<br />
*'''Accuracy'''<br />
**Angrylion RDP Plus<br />
**Azimer's Audio NEW<br />
**Static RSP Interpreter<br />
**If you have a decent quad-core CPU, you can run many N64 games with pixel-perfect graphics at full speed, thanks to the new multithreaded version of angrylion's software plugin. The new Azimer's plugin (still WIP) works good in LLE. Since there's almost no visual difference, you may as well use PJ64's RSP or ParaLLEl-RSP to get better performance, and/or move to ParaLLEl-RDP outright for even greater speed and upscaling options to boot (though it goes without saying upscaling would no longer be accurate). Conversely, if you want even greater accuracy, disable "Hide advanced settings" under Configuration, then enable "Always use interpreter core" under Advanced, and under Angrylion's options, disable multi-threading and set compatibility to "Slow". Performance WILL crash, but hey, it'll be accurate!<br />
<br />
===Mupen64Plus===<br />
The official releases of Mupen64Plus only come bundled with a handful of video and RSP plugins, namely Glide64mk2, Rice, and the HLE RSP. The developers also maintain forks of the CXD4 RSP and the z64 video and RSP plugins, but they are not included in the official release bundles for some reason. Should you wish to use those plugins or third party ones such as GLideN64 or the ParaLLEl plugins, you must build them yourself or get them from outside sources. Due to this fact, the mediocre nature of the "official" video plugins, and the overall lack of user-friendliness, it may be better to use a fork such as [[m64p]] or [[RMG]], though note that m64p only comes and works with the ParaLLEl plugins, so RMG is a better choice if you wish to use something else, as that comes with more plugins and allows you to use whichever ones you want.<br />
*'''General Use'''<br />
**Video: GLideN64 or ParaLLEl-RDP<br />
**RSP: RSP-HLE (for GLideN64) or ParaLLEl-RSP (for ParaLLEl-RDP)<br />
**Either one of these combinations will enable you to play the vast majority of N64 games while having reasonable system requirements. GLideN64 is faster and has more enhancement options, but ParaLLEl-RDP is much more accurate to the real console. You can also use the CXD4 RSP with GLideN64 if you want, but be sure to set it to pass display lists to the graphics plugin in mupen64plus.cfg, else GLideN64 will switch to its LLE mode, which is not generally recommended to use.<br />
*'''Best Performance'''<br />
**Video: Glide64mk2<br />
**RSP: RSP-HLE<br />
**These are Mupen64Plus's default plugins. Glide64mk2 is based on Glide64 Final, and is named so as to differentiate it from the original, now obsolete fork of Glide64 that Mupen64Plus used at its inception. It is not up to GLideN64's level, but it does well enough for many games and is quite fast. Use this combination if you have a lower end PC that can't handle the General Use setup. If your device STILL can't handle this setup, try the Rice video plugin, but expect many missing effects, glitches and incompatibilities.<br />
*'''Accuracy'''<br />
**Video: Angrylion Plus or ParaLLEl-RDP<br />
**RSP: CXD4-ssse3 or ParaLLEl-RSP<br />
**Any combination of these should result in very high accuracy. Technically, the most accurate setup is Angrylion combined with CXD4, but the difference between these and the ParaLLEl plugins is almost negligible, while being a lot slower. Be sure to set the CPU core to Pure Interpreter for even greater accuracy, along with plummeting framerates.<br />
<br />
Note: In some cases the cfg file may not appear, in which case you may do this:<br />
*Open terminal in emulator folder on in its respective directory<br />
*''mupen64plus --configdir'' /directory/where/you/want/it/to/be<br />
<br />
===Libretro===<br />
There are two N64 libretro emulator cores for use on libretro frontends such as [[RetroArch]]: Mupen64Plus-Next and ParaLLEl-N64. The former is up-to-date and is recommended for most use cases, while the latter is no longer updated and is only around for performance reasons. They also have access to the following plugins:<br />
*Shared by both cores<br />
**Video: ParaLLEl-RDP , Angrylion<br />
**RSP: ParaLLEl-RSP, HLE, CXD4<br />
*Exclusive to Mupen64Plus-Next<br />
**GLideN64<br />
*Exclusive to ParaLLEl-N64<br />
**glN64, Rice, Glide64<br />
Due to these differences, it is advisable to use Mupen64Plus-Next for general use, and ParaLLEl-N64 for performance.<br />
*'''General Use (LLE)'''<br />
**Core: Mupen64Plus-Next<br />
**Video: ParaLLEl-RDP<br />
**RSP: ParaLLEl-RSP<br />
**By default ParaLLEl-RDP will output at native resolution with all the VI filters on, making it look exactly like Angrylion and the real N64 console. Upscaling must therefore be enabled in the core options. You can also alternatively render at a high resolution and downsample to a lower one if you want to improve 3D without making it stick out from 2D elements too much.<br />
*'''General Use (HLE)'''<br />
**Core: Mupen64Plus-Next<br />
**Video: GLideN64<br />
**RSP: HLE<br />
**While GLideN64 also works with the ParaLLEl and CXD4 RSP plugins, using them will cause GLideN64 to switch to its LLE mode, which is currently glitchier and slower than the HLE mode, for few compatibility or accuracy benefits, if any. As such, it is recommended to stick with the HLE RSP for GLideN64.<br />
*'''Best Performance'''<br />
**Core: ParaLLEl-N64<br />
**Video: Glide64<br />
**RSP: HLE<br />
**For slow, low-end devices and old PCs only. If further speed is desired or needed, you may try glN64 or Rice, but using them comes at a steep cost in compatibility and accuracy, and many low-end devices in use today ought to be able to handle Glide64 just fine (well, with the exception of certain underpowered "retro gaming" handhelds).<br />
*'''Accuracy'''<br />
**Core: Mupen64Plus-Next<br />
**Video: Angrylion<br />
**RSP: CXD4<br />
**Just like the developers intended! If you want to go all out, set the CPU core to Pure Interpreter, turn off multi-threading and set thread sync level to High in Angrylion's options for the real 30 VI/s experience. Closest you'll get to real hardware until a complete cycle-accurate N64 emulator surfaces.<br />
<br />
[[Category:Recommendations]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Recommended_N64_plugins&diff=48517Recommended N64 plugins2022-07-17T09:03:42Z<p>GPDP1: more on Project64 Video and Glide64 Final</p>
<hr />
<div>The N64 emulation scene had previously been described as a broken mess, the very definition of plugin hell. With recent developments in the scene, however, the situation has markedly improved, and it is no longer considered necessary to have multiple emulators and plugins on hand to get most games to work. This page will outline the best plugins currently available for the benefit of both the casual and enthusiast looking to get their N64 emulation fix.<br />
<br />
==The Plugin Specs==<br />
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.<br />
<br />
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.<br />
<br />
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. Unsurprisingly, this situation often led to a lot of confusion from users, who often wondered why there were so many plugins, and which ones were the best to use, only to find out it often depended on the game, and even then, some games would refuse to work as intended no matter what was tried. Hence the label "plugin hell" was coined, and stuck as a description of the travails of trying to emulate N64 games well into the 2010's.<br />
<br />
However, as time went on, things began to change, though 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.<br />
<br />
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 changes and 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) video plugin there is but was initially only available for the zilmar spec, was ported to Mupen64Plus and integrated into 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.<br />
<br />
All that said, the issue is that there are now three plugin standards to account for:<br />
<br />
*The zilmar spec - Utilized by Project64 and most other legacy emulators; only Project64 still uses it today.*<br />
<br />
*The Mupen64Plus spec - Utilized by Mupen64Plus and most of its forks.<br />
<br />
*Libretro - Not really a spec per se, as the plugins are integrated directly into the libretro core, so there's no DLL files to download or add.<br />
<br />
As of right now, not all plugins are readily available on all three. Consult the tables below for reference:<br />
<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Latest Version<br />
! scope="col"|Project64<br />
! scope="col"|Mupen64Plus<br />
! scope="col"|Libretro<br />
! scope="col"|HLE<br />
! scope="col"|LLE<br />
! scope="col"|Widescreen Hack<br />
! scope="col"|Custom Texture Packs<br />
! scope="col"|Recommended<br />
|-<br />
!colspan="13"|Video Plugins<br />
|-<br />
|ParaLLEl-RDP<br />
|[https://github.com/Themaister/parallel-rdp git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|GLideN64<br />
|[https://github.com/gonetz/GLideN64/releases/tag/github-actions github-actions]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Angrylion RDP Plus<br />
|[https://github.com/ata4/angrylion-rdp-plus/releases/tag/v1.6 1.6]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|Glide64**<br />
|Final<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|Jabo's Direct3D8<br />
|1.7.0.57-ver5<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Rice Video<br />
|0.4.4<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|glN64<br />
|0.4.1<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|z64gl<br />
|R17<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Angrylion (Official)<br />
|r114<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|}<br />
<br />
<nowiki>*</nowiki>It should be noted that Project64 after version 2.x made some changes to the zilmar plugin spec, and while it remains backwards compatible with the older version of the spec (meaning most older plugins will still work with Project64), plugins targeting the newer version will not work on older versions of Project64 or other zilmar spec-based emulators.<br />
<br />
<nowiki>**</nowiki>Funnily enough, Glide64 actually DOES have LLE code (much of it apparently comes from z64gl) and can technically run in LLE mode by using it alongside an LLE RSP plugin such as CXD4. However, it is not a complete implementation, and actually trying to run it in such a mode results in massive visual glitches, making it unusable. Practically speaking, then, Glide64 cannot be considered a true LLE plugin, and will not be designated as such, nor was it ever meant to be.<br />
<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Latest Version<br />
! scope="col"|Project64<br />
! scope="col"|Mupen64Plus<br />
! scope="col"|Libretro<br />
! scope="col"|HLE Compatible*<br />
! scope="col"|LLE Compatible*<br />
! scope="col"|Recommended<br />
|-<br />
!colspan="13"|RSP Plugins<br />
|-<br />
|Zilmar's RSP<br />
|1.7<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Mupen64Plus HLE RSP<br />
|[https://github.com/mupen64plus/mupen64plus-rsp-hle git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|Static Interpreter/CXD4<br />
|[https://github.com/cxd4/rsp git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|ParaLLEl-RSP<br />
|[https://github.com/Themaister/parallel-rsp git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Mupen64 HLE RSP<br />
|0.5.1<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|z64<br />
|r17<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|}<br />
<br />
<nowiki>*</nowiki>These terms signify whether an RSP plugin can work alongside HLE and/or LLE audio and video plugins. As for the type of emulation employed by the RSP plugins themselves, all but the Mupen64/plus HLE RSP plugins are LLE in nature. The LLE RSP plugins that can work with HLE plugins do so by passing the N64 display and audio lists onto the plugins themselves.<br />
<br />
==Video==<br />
===Currently Recommended Plugins===<br />
The following are the current best video plugins for use on modern PCs and devices.<br />
[[File:SuperMario64-Comparison.png|thumb|right|Jabo's Direct3D8 (left) compared with angrylion's RDP with OpenGL (right), while playing ''Super Mario 64''.]]<br />
====[https://github.com/Themaister/parallel-rdp ParaLLEl-RDP]====<br />
An LLE video plugin inspired by and referenced against Angrylion's RDP plugin, 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 several forks of Mupen64Plus and Project64, such as [[m64p]] and [https://www.64dd.org/downloads.html this build] of Project64. This is currently considered the best video plugin by most measures. It is almost 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 can also render at a high resolution and downsample back down to a lower one, should one wish to improve the 3D graphics without making them stick out from the often low-res 2D elements. Due to its LLE nature, it does not support widescreen hacks or high-res textures - try GLideN64 if you seek to use such features.<br />
<br />
System requirements for ParaLLEl-RDP are higher than for the other plugins. It requires a GPU with Vulkan support and up-to-date drivers (most Nvidia and AMD GPUs made after 2012 should be covered, though Intel graphics requires Skylake or newer), and upscaling increases the GPU requirements even further, far more than GLideN64. It must also be used in conjunction with an LLE RSP plugin, preferably its sister plugin ParaLLEl-RSP, as it features a recompiler for added speed. At native resolution, however, a modest PC with Vulkan support can handle it without much issue, even on integrated graphics.<br />
<br />
====[https://github.com/gonetz/GLideN64/ GLideN64]====<br />
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 z64gl and, 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 emulation of every game, gamma correction, flat and prim shading, VI emulation, and LLE graphics support. 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]], MSAA 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]].<br />
<br />
GLideN64 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.<br />
<br />
====[https://github.com/ata4/angrylion-rdp-plus/releases Angrylion RDP Plus]====<br />
This is a fork of Angrylion's RDP that supports multithreading. It 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, as does using it alongside an RSP plugin with a recompiler such as ParaLLEl-RSP, but some games are still not full speed even on a Core i7-8700K. It also allows you to disable VI filters for slightly better performance. This fork has at least one accuracy regression compared to the official version of Angrylion. 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.<br />
<br />
====Glide64====<br />
The former best general-use plugin. Versions of this are included in Project64, mainline Mupen64Plus, and the ParaLLEl-N64 libretro core. While it is no longer updated and is far less accurate and compatible than the newer offerings, it still has a few use cases, such as better support for older ROM hacks. It works relatively well for many (most?) games, has support for hi-res textures, and it is also faster than the newer plugins, which makes it suitable for slower devices such as the older Raspberry Pis. Otherwise, to ensure the highest possible compatibility, stick to either ParaLLEl-RDP or GLideN64.<br />
<br />
Note that the Project64 version of Glide64 has been renamed to Project64 Video and has undergone some changes and rewrites since it was initially forked, and thus may contain regressions compared to the last official standalone release of the plugin by Gonetz. Since this fork only works with current versions of Project64, should you wish to use this plugin on an older zilmar-spec emulator like 1964 or the original Mupen64, or if you want to avoid potential regressions with the Project64 version, use [https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/glidehqplusglitch64/Glide64_Final.zip Glide64 Final] instead.<br />
<br />
===Deprecated Plugins===<br />
The following video plugins are old and deprecated, and should not be used or considered unless you have a VERY old or underpowered device that cannot handle the recommended plugins, or there's a very specific use case not covered by modern implementations.<br />
<br />
*Jabo's Direct3D8 - Comes with Project64, and was once its default video plugin. Very speedy, has built-in AA and AF options, and includes a [[Widescreen_Hack|widescreen hack]]. The version included with the most recent versions of Project64 (1.7.0.57-ver5) is somewhat buggy and has regressions, however. [http://www.jabosoft.com/articles/114 Jabo's 1.6.1 patch] is better, though version 1.7 can run in LLE mode, which can help with a few games. Sadly, it will likely never see another update again, and though it is still included in Project64 to this day, it is no longer the default, and should not be used unless you have a very old PC that cannot handle Glide64 or GLideN64.<br />
*[http://www.emutalk.net/threads/54166-Rice-Video-Community-version Rice Video] - A very 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, all aiming to fix issues or add features, and an OpenGL version of it is included in mainline Mupen64Plus and in the ParaLLEl-N64 libretro core. It eventually lost favor with the wider community, as even during its heyday it was not a very compatible plugin, and once the much-superior Glide64 also gained the ability to load custom textures, there was little reason to use it beyond its speed. The so-called "Community 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. If you are absolutely resolved to try it out, seek out the original versions by Rice, primarily 6.1.0 or 6.1.1b.<br />
*[http://www.emutalk.net/threads/40640-Z64-a-LLE-graphics-plugin z64gl] - A hardware-rendered, low-level plugin developed by ziggy, derived from MAME's N64 driver. It was once notable for being one of the only plugins that could play games without an HLE microcode implementation such as Rogue Squadron. However, it was rather glitchy, had higher system requirements than the HLE plugins, needed an LLE RSP plugin to work (such as the bundled z64 RSP or Project64's RSP plugin set to LLE graphics), and configuration required editing the config file directly. A [https://github.com/purplemarshmallow/z64/tree/angrylion-integration fork] cropped up that aimed at improving it, but it did not go very far. Nowadays, it's obsolete, as GLideN64 can now play every game through HLE (thus subverting z64gl's only selling point), and its LLE has been surpassed by Angrylion-derived plugins and even GLideN64's LLE mode.<br />
*[https://sourceforge.net/p/angrylions-stuff/code/HEAD/tree/ Official Angrylion RDP] - A software-rendered, hardware-accurate plugin, developed by angrylion (though derived from MAME, much like z64gl). This is the most accurate N64 video plugin in existence, emulating almost* every facet of the N64's RDP precisely and thus making it capable of playing almost every single game in the N64 library with no issues, fixing even notorious cases such as the ''Pokémon Snap'' red dot and the ''Body Harvest'' bridge. This, however, comes at the cost of insane CPU requirements while making games look like, well, N64 games running on real hardware, which means native resolution, no widescreen, no hi-res textures - just the N64 in its full, vaseline-covered glory. Since this particular version is single-threaded, uses DirectDraw and is Windows only, it is recommended to use Angrylion RDP Plus or ParaLLEl-RDP instead, which offer much more reasonable performance. Only try it out if you have a tricked-out rig and want to test your CPU's mettle, or if you can compile it from source and need it for testing/debugging purposes, as the latest updates are always made to this version first.<br />
*[http://www.emutalk.net/threads/55481-angrylion-s-Per-Pixel-RDP-with-OpenGL HatCat/angrylion's Pixel-Accurate N64 Plugin] - This is a fork of Angrylion's RDP, done by HatCat. It has some optimizations not present in the official code, but is outdated and lacking some accuracy improvements and optimizations written by Angrylion. It has the option to disable the VI filters (which gives a speed boost), as well as the ability to set custom resolutions. Also, this version uses OpenGL 1.x instead of Direct Draw and supports Linux. Obsoleted by newer forks such as Angrylion RDP Plus.<br />
<br />
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:<br />
<br />
<gallery widths="300" mode="packed"><br />
Mario Tennis Rice.png|Mario Tennis running on ParaLLEl-N64 using Rice. Missing various effects, heavily glitched court.<br />
Mario Tennis Glide64.png|Mario Tennis running on ParaLLEl-N64 using Glide64. Missing various effects and shadows, some glitches.<br />
Mario Tennis glN64.png|Mario Tennis running on ParaLLEl-N64 using glN64. Missing various effects; shadows are present, but glitched.<br />
Mario Tennis GLideN64 HLE.png|Mario Tennis running on Mupen64Plus-Next using GLideN64 in HLE mode with 16xMSAA. Minor text cutoff on bottom of scoreboard.<br />
Mario Tennis GLideN64 LLE.png|Mario Tennis running on Mupen64Plus-Next using GLideN64 in LLE mode with 16xMSAA. Minor text cutoff on bottom of scoreboard. Has slight polygon jitter not present in HLE.<br />
Mario Tennis ParaLLEl 1x.png|Mario Tennis running on Mupen64Plus-Next using ParaLLEl-RDP at native resolution. Identical to Angrylion, and thus a pixel-perfect representation of real hardware.<br />
Mario Tennis ParaLLEl 4x Downsampled.png|Mario Tennis running on Mupen64Plus-Next using ParaLLEl-RDP rendering at 4x resolution, then downsampled back to native resolution.<br />
Mario Tennis ParaLLEl 4x.png|Mario Tennis running on Mupen64Plus-Next using ParaLLEl-RDP rendering at 4x resolution. Has very slight polygon jitter, though less than GLideN64 in LLE.<br />
</gallery><br />
<br />
<nowiki>*</nowiki> There is at least one known, relatively minor graphical glitch in Pokemon Snap (go figure) using Angrylion that requires currently-unimplemented cycle-accurate behavior to fix without resorting to hacks.<br />
<br />
==Audio==<br />
This section will only cover the zilmar spec plugins, as Mupen64Plus does not have any alternative audio plugins besides the default, and neither do the libretro forks.<br />
<br />
*Project64 Audio - The default audio plugin for Project64, apparently loosely based off of code from Mupen64Plus's HLE RSP. Very barebones, with no options to speak off.<br />
*Jabo's DirectSound - Comes with Project64. It works fine for the most part, but some games may not play nice with it. It is a low-level plugin, so it needs an accompanying LLE RSP plugin. Will probably never be updated again.<br />
*[http://www.emutalk.net/threads/27610-Audio-v0-56-WIP2-Download-Feedback Azimer's HLE Audio] - This popular HLE audio plugin boasts high compatibility. Version 0.56WIP2 is old as hell, but it is the tried and true standard to which audio plugins are compared against. Recently, [https://github.com/Azimer/AziAudio Azimer open sourced his plugin], and there were plans to integrate it into Project64, though this has yet to happen. While the latest development versions have a few issues, it now works in LLE, and has integrated code from Mupen64Plus's HLE RSP plugin, allowing it to work with the Factor 5 and BOSS games even in HLE.<br />
*[http://forum.pj64-emu.com/showthread.php?t=3644 Shunyuan's HLE Audio] - An audio plugin, apparently based on 1964Audio and HatCat's RSP plugin. Can run in both LLE and HLE modes despite the name, though the HLE mode just makes it run an outdated, baked-in version of HatCat's RSP, which makes it not a true HLE plugin. Has been abandoned after charges of just taking others' code without revealing a source. If games run at a weird speed using this plugin, go to the ROM's Game Settings, and disable Fixed Audio Timing and Sync using Audio. Though it worked surprisingly well despite its Frankenstein nature, modern development versions of Project64 no longer work with it, apparently due to it depending on a bug that has now been fixed. As such, it is probably better to use Azimer's plugin instead.<br />
<br />
==Input==<br />
*Project64 Input - Comes with Project64 as of the latest versions. Very simple input plugin which looks suspiciously a lot like Jabo's, but at least has XInput support, which is nice.<br />
*[https://sourceforge.net/projects/nragev20/ NRage Input] - Also comes with Project64 as of version 2.2. Hands down the best input plugin as it is more feature complete than Jabo's DirectInput. Has a ton of options and great controller compatibility, including XInput support for use with Xbox 360 controllers. It can't emulate the microphone that is required by ''Hey You, Pikachu'' or the printer required for the ''Pokémon Snap Station''. It has the ability to emulate Controller Pak (''Mario Kart 64'''s ghost saves), Rumble Pak (''Star Fox 64''), and Transfer Pak (''Pokémon Stadium'' series) functionality fairly well. Version 2.3 of Project64 introduced a version of the plug-in that can emulate the N64's mouse accessory designed for the 64DD to coincide with Project64's newest ability to emulate the 64DD accessory. Surprisingly, ''Mario Artist: Paint Studio'' can use the Japanese ''Game Boy Camera'' (called ''Pocket Camera'') in Transfer Pak mode, but the camera function doesn't work as it displays static, although importing captured images still works technically.<br />
*Jabo's DirectInput - Used to come with Project64, but now removed in favor of NRage Input. It isn't too bad, 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 usual, do not expect any updates.<br />
*[https://www.raphnet-tech.com/products/raphnetraw/index.php/ Raphnetraw] - This open source plugin allows streamlined use of N64 controller(s) via raphnet [https://www.raphnet-tech.com/products/n64_usb_adapter_gen3/index.php N64-to-USB v3+ adapters]. It supports rumble and is available for Project64 and mupen64plus. Also contains various DLLs for special port arrangements [https://www.raphnet.net/programmation/mupen64plus-input-raphnetraw/index_en.php#4 (link)].<br />
<br />
==RSP==<br />
===Recommended Plugins===<br />
*Zilmar's RSP - Comes with Project64. Reasonably accurate, quite fast in Recompiler mode (enabled by default), and will work fine for the 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.<br />
*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. 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 a pure LLE audio plugin and requires LLE RSP emulation.<br />
*[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 one of the most accurate RSP plugins, though zilmar's RSP in Recompiler mode as well as ParaLLEl-RSP both trump it in speed. It can take advantage of SSSE3 for greater performance, though it also comes in SSE2 and non-SSE variations in case your PC does not support those instruction sets. In both the zilmar and Mupen64Plus versions (though not in libretro, it seems), it is capable of working with both HLE and LLE audio and video plugins via the following settings:<br />
**Simulate RSP graphics from external plugin - Check if using an HLE graphics plugin, uncheck if using LLE<br />
**Simulate RSP audio from external plugin - Check if using an HLE audio plugin, uncheck if using LLE<br />
**Force semaphore locking - Check to fix issues with Mario no Photopie. Only works with Project64 2.x and beyond.<br />
*ParaLLEl-RSP - A fast and accurate RSP written by [https://github.com/Themaister/parallel-rsp Themaister], though it borrows heavily from both CXD4 and CEN64's RSP code. It is about as accurate and compatible as CXD4, while being much faster owing to its inclusion of a dynamic recompiler. 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). Note that it only works with LLE video and audio plugins, though it is highly recommended if using such.<br />
<br />
===Deprecated Plugins===<br />
*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 and many other compatibility fixes were later added to the Mupen64Plus version, which has now been ported to the zilmar spec after years of exclusivity on the Mupen64Plus side of things. As such, this version is officially obsolete.<br />
*z64 RSP plugin pack - Largely deprecated by the Static Interpreter/CXD4 RSP plugin. This set of RSP plugins comes with the z64 video plugin, each with their own purpose:<br />
**Ziggy-z64RSP - This RSP is based on the MAME/MESS RSP code. It is slower but more accurate.<br />
**Ziggy-PJ64 - Based on the Project64 1.4 RSP, this plugin is much faster.<br />
**angrylion - This RSP is a simple Interpreter, and is required for a few games like World Driver Championship to work correctly with z64gl.<br />
<br />
==Recommended N64 Setups==<br />
<br />
===Project64 and Others===<br />
Project64 comes bundled with the following plugins:<br />
*Video: Jabo's Direct3D8, Project64 Video (Glide64 under another name), GLideN64<br />
*Audio: Jabo's DirectSound, Project64 Audio<br />
*Input: NRage for Project64, Project64 Input<br />
*RSP: zilmar's RSP<br />
Should you wish to use other plugins, they must be downloaded from a third party source and dropped into their respective plugin folder categories in the Project64 directory. Video plugins go under Plugin/GFX, audio plugins under Plugin/Audio, etc.<br />
<br />
*'''General Use'''<br />
**GLideN64<br />
**Azimer's Audio NEW (set to LLE)<br />
**Static Interpreter RSP or Zilmar's RSP<br />
**Either of the RSP plugins should be fine for most games. The Static Interpreter RSP is slightly more accurate, whereas zilmar's is much faster. Should you wish to use GLideN64 in LLE mode (or any LLE video plugin for that matter), if using zilmar's RSP, simply uncheck "Graphics HLE" in the Plugin configuration screen. If using the Static Interpreter RSP, you'll have to run the spconfig.exe that comes with that plugin, and tell it to NOT "simulate RSP graphics from external plugin" (in other words, type "0"). ParaLLEl-RSP only works in LLE, so GLideN64's HLE mode will be unavailable with that plugin.<br />
*'''Best Performance'''<br />
**Project64 Video or Glide64 Final<br />
**Azimer's HLE Audio<br />
**Zilmar's RSP or Mupen64Plus HLE RSP<br />
**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. Recommended for the older zilmar-spec emulators as well (replace Project64 Video with Glide64 Final for those, though you may want to do that even with Project64 should you run into a regression). 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.<br />
*'''Accuracy'''<br />
**Angrylion RDP Plus<br />
**Azimer's Audio NEW<br />
**Static RSP Interpreter<br />
**If you have a decent quad-core CPU, you can run many N64 games with pixel-perfect graphics at full speed, thanks to the new multithreaded version of angrylion's software plugin. The new Azimer's plugin (still WIP) works good in LLE. Since there's almost no visual difference, you may as well use PJ64's RSP or ParaLLEl-RSP to get better performance, and/or move to ParaLLEl-RDP outright for even greater speed and upscaling options to boot (though it goes without saying upscaling would no longer be accurate). Conversely, if you want even greater accuracy, disable "Hide advanced settings" under Configuration, then enable "Always use interpreter core" under Advanced, and under Angrylion's options, disable multi-threading and set compatibility to "Slow". Performance WILL crash, but hey, it'll be accurate!<br />
<br />
===Mupen64Plus===<br />
The official releases of Mupen64Plus only come bundled with a handful of video and RSP plugins, namely Glide64mk2, Rice, and the HLE RSP. The developers also maintain forks of the CXD4 RSP and the z64 video and RSP plugins, but they are not included in the official release bundles for some reason. Should you wish to use those plugins or third party ones such as GLideN64 or the ParaLLEl plugins, you must build them yourself or get them from outside sources. Due to this fact, the mediocre nature of the "official" video plugins, and the overall lack of user-friendliness, it may be better to use a fork such as [[m64p]] or [[RMG]], though note that m64p only comes and works with the ParaLLEl plugins, so RMG is a better choice if you wish to use something else, as that comes with more plugins and allows you to use whichever ones you want.<br />
*'''General Use'''<br />
**Video: GLideN64 or ParaLLEl-RDP<br />
**RSP: RSP-HLE (for GLideN64) or ParaLLEl-RSP (for ParaLLEl-RDP)<br />
**Either one of these combinations will enable you to play the vast majority of N64 games while having reasonable system requirements. GLideN64 is faster and has more enhancement options, but ParaLLEl-RDP is much more accurate to the real console. You can also use the CXD4 RSP with GLideN64 if you want, but be sure to set it to pass display lists to the graphics plugin in mupen64plus.cfg, else GLideN64 will switch to its LLE mode, which is not generally recommended to use.<br />
*'''Best Performance'''<br />
**Video: Glide64mk2<br />
**RSP: RSP-HLE<br />
**These are Mupen64Plus's default plugins. Glide64mk2 is based on Glide64 Final, and is named so as to differentiate it from the original, now obsolete fork of Glide64 that Mupen64Plus used at its inception. It is not up to GLideN64's level, but it does well enough for many games and is quite fast. Use this combination if you have a lower end PC that can't handle the General Use setup. If your device STILL can't handle this setup, try the Rice video plugin, but expect many missing effects, glitches and incompatibilities.<br />
*'''Accuracy'''<br />
**Video: Angrylion Plus or ParaLLEl-RDP<br />
**RSP: CXD4-ssse3 or ParaLLEl-RSP<br />
**Any combination of these should result in very high accuracy. Technically, the most accurate setup is Angrylion combined with CXD4, but the difference between these and the ParaLLEl plugins is almost negligible, while being a lot slower. Be sure to set the CPU core to Pure Interpreter for even greater accuracy, along with plummeting framerates.<br />
<br />
Note: In some cases the cfg file may not appear, in which case you may do this:<br />
*Open terminal in emulator folder on in its respective directory<br />
*''mupen64plus --configdir'' /directory/where/you/want/it/to/be<br />
<br />
===Libretro===<br />
There are two N64 libretro emulator cores for use on libretro frontends such as [[RetroArch]]: Mupen64Plus-Next and ParaLLEl-N64. The former is up-to-date and is recommended for most use cases, while the latter is no longer updated and is only around for performance reasons. They also have access to the following plugins:<br />
*Shared by both cores<br />
**Video: ParaLLEl-RDP , Angrylion<br />
**RSP: ParaLLEl-RSP, HLE, CXD4<br />
*Exclusive to Mupen64Plus-Next<br />
**GLideN64<br />
*Exclusive to ParaLLEl-N64<br />
**glN64, Rice, Glide64<br />
Due to these differences, it is advisable to use Mupen64Plus-Next for general use, and ParaLLEl-N64 for performance.<br />
*'''General Use (LLE)'''<br />
**Core: Mupen64Plus-Next<br />
**Video: ParaLLEl-RDP<br />
**RSP: ParaLLEl-RSP<br />
**By default ParaLLEl-RDP will output at native resolution with all the VI filters on, making it look exactly like Angrylion and the real N64 console. Upscaling must therefore be enabled in the core options. You can also alternatively render at a high resolution and downsample to a lower one if you want to improve 3D without making it stick out from 2D elements too much.<br />
*'''General Use (HLE)'''<br />
**Core: Mupen64Plus-Next<br />
**Video: GLideN64<br />
**RSP: HLE<br />
**While GLideN64 also works with the ParaLLEl and CXD4 RSP plugins, using them will cause GLideN64 to switch to its LLE mode, which is currently glitchier and slower than the HLE mode, for few compatibility or accuracy benefits, if any. As such, it is recommended to stick with the HLE RSP for GLideN64.<br />
*'''Best Performance'''<br />
**Core: ParaLLEl-N64<br />
**Video: Glide64<br />
**RSP: HLE<br />
**For slow, low-end devices and old PCs only. If further speed is desired or needed, you may try glN64 or Rice, but using them comes at a steep cost in compatibility and accuracy, and many low-end devices in use today ought to be able to handle Glide64 just fine (well, with the exception of certain underpowered "retro gaming" handhelds).<br />
*'''Accuracy'''<br />
**Core: Mupen64Plus-Next<br />
**Video: Angrylion<br />
**RSP: CXD4<br />
**Just like the developers intended! If you want to go all out, set the CPU core to Pure Interpreter, turn off multi-threading and set thread sync level to High in Angrylion's options for the real 30 VI/s experience. Closest you'll get to real hardware until a complete cycle-accurate N64 emulator surfaces.<br />
<br />
[[Category:Recommendations]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=Recommended_N64_plugins&diff=48516Recommended N64 plugins2022-07-17T08:43:19Z<p>GPDP1: Added notice about potential regressions in Project64 Video</p>
<hr />
<div>The N64 emulation scene had previously been described as a broken mess, the very definition of plugin hell. With recent developments in the scene, however, the situation has markedly improved, and it is no longer considered necessary to have multiple emulators and plugins on hand to get most games to work. This page will outline the best plugins currently available for the benefit of both the casual and enthusiast looking to get their N64 emulation fix.<br />
<br />
==The Plugin Specs==<br />
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.<br />
<br />
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.<br />
<br />
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. Unsurprisingly, this situation often led to a lot of confusion from users, who often wondered why there were so many plugins, and which ones were the best to use, only to find out it often depended on the game, and even then, some games would refuse to work as intended no matter what was tried. Hence the label "plugin hell" was coined, and stuck as a description of the travails of trying to emulate N64 games well into the 2010's.<br />
<br />
However, as time went on, things began to change, though 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.<br />
<br />
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 changes and 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) video plugin there is but was initially only available for the zilmar spec, was ported to Mupen64Plus and integrated into 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.<br />
<br />
All that said, the issue is that there are now three plugin standards to account for:<br />
<br />
*The zilmar spec - Utilized by Project64 and most other legacy emulators; only Project64 still uses it today.*<br />
<br />
*The Mupen64Plus spec - Utilized by Mupen64Plus and most of its forks.<br />
<br />
*Libretro - Not really a spec per se, as the plugins are integrated directly into the libretro core, so there's no DLL files to download or add.<br />
<br />
As of right now, not all plugins are readily available on all three. Consult the tables below for reference:<br />
<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Latest Version<br />
! scope="col"|Project64<br />
! scope="col"|Mupen64Plus<br />
! scope="col"|Libretro<br />
! scope="col"|HLE<br />
! scope="col"|LLE<br />
! scope="col"|Widescreen Hack<br />
! scope="col"|Custom Texture Packs<br />
! scope="col"|Recommended<br />
|-<br />
!colspan="13"|Video Plugins<br />
|-<br />
|ParaLLEl-RDP<br />
|[https://github.com/Themaister/parallel-rdp git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|GLideN64<br />
|[https://github.com/gonetz/GLideN64/releases/tag/github-actions github-actions]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Angrylion RDP Plus<br />
|[https://github.com/ata4/angrylion-rdp-plus/releases/tag/v1.6 1.6]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|Glide64**<br />
|Final<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{~}}<br />
|-<br />
|Jabo's Direct3D8<br />
|1.7.0.57-ver5<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Rice Video<br />
|0.4.4<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|-<br />
|glN64<br />
|0.4.1<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|z64gl<br />
|R17<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|Angrylion (Official)<br />
|r114<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✗}}<br />
|}<br />
<br />
<nowiki>*</nowiki>It should be noted that Project64 after version 2.x made some changes to the zilmar plugin spec, and while it remains backwards compatible with the older version of the spec (meaning most older plugins will still work with Project64), plugins targeting the newer version will not work on older versions of Project64 or other zilmar spec-based emulators.<br />
<br />
<nowiki>**</nowiki>Funnily enough, Glide64 actually DOES have LLE code (much of it apparently comes from z64gl) and can technically run in LLE mode by using it alongside an LLE RSP plugin such as CXD4. However, it is not a complete implementation, and actually trying to run it in such a mode results in massive visual glitches, making it unusable. Practically speaking, then, Glide64 cannot be considered a true LLE plugin, and will not be designated as such, nor was it ever meant to be.<br />
<br />
{| class="wikitable" style="text-align:center;"<br />
! scope="col"|Name<br />
! scope="col"|Latest Version<br />
! scope="col"|Project64<br />
! scope="col"|Mupen64Plus<br />
! scope="col"|Libretro<br />
! scope="col"|HLE Compatible*<br />
! scope="col"|LLE Compatible*<br />
! scope="col"|Recommended<br />
|-<br />
!colspan="13"|RSP Plugins<br />
|-<br />
|Zilmar's RSP<br />
|1.7<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Mupen64Plus HLE RSP<br />
|[https://github.com/mupen64plus/mupen64plus-rsp-hle git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|-<br />
|Static Interpreter/CXD4<br />
|[https://github.com/cxd4/rsp git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|ParaLLEl-RSP<br />
|[https://github.com/Themaister/parallel-rsp git]<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✓}}<br />
|-<br />
|Mupen64 HLE RSP<br />
|0.5.1<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|-<br />
|z64<br />
|r17<br />
|{{✓}}<br />
|{{✓}}<br />
|{{✗}}<br />
|{{✗}}<br />
|{{✓}}<br />
|{{✗}}<br />
|}<br />
<br />
<nowiki>*</nowiki>These terms signify whether an RSP plugin can work alongside HLE and/or LLE audio and video plugins. As for the type of emulation employed by the RSP plugins themselves, all but the Mupen64/plus HLE RSP plugins are LLE in nature. The LLE RSP plugins that can work with HLE plugins do so by passing the N64 display and audio lists onto the plugins themselves.<br />
<br />
==Video==<br />
===Currently Recommended Plugins===<br />
The following are the current best video plugins for use on modern PCs and devices.<br />
[[File:SuperMario64-Comparison.png|thumb|right|Jabo's Direct3D8 (left) compared with angrylion's RDP with OpenGL (right), while playing ''Super Mario 64''.]]<br />
====[https://github.com/Themaister/parallel-rdp ParaLLEl-RDP]====<br />
An LLE video plugin inspired by and referenced against Angrylion's RDP plugin, 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 several forks of Mupen64Plus and Project64, such as [[m64p]] and [https://www.64dd.org/downloads.html this build] of Project64. This is currently considered the best video plugin by most measures. It is almost 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 can also render at a high resolution and downsample back down to a lower one, should one wish to improve the 3D graphics without making them stick out from the often low-res 2D elements. Due to its LLE nature, it does not support widescreen hacks or high-res textures - try GLideN64 if you seek to use such features.<br />
<br />
System requirements for ParaLLEl-RDP are higher than for the other plugins. It requires a GPU with Vulkan support and up-to-date drivers (most Nvidia and AMD GPUs made after 2012 should be covered, though Intel graphics requires Skylake or newer), and upscaling increases the GPU requirements even further, far more than GLideN64. It must also be used in conjunction with an LLE RSP plugin, preferably its sister plugin ParaLLEl-RSP, as it features a recompiler for added speed. At native resolution, however, a modest PC with Vulkan support can handle it without much issue, even on integrated graphics.<br />
<br />
====[https://github.com/gonetz/GLideN64/ GLideN64]====<br />
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 z64gl and, 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 emulation of every game, gamma correction, flat and prim shading, VI emulation, and LLE graphics support. 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]], MSAA 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]].<br />
<br />
GLideN64 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.<br />
<br />
====[https://github.com/ata4/angrylion-rdp-plus/releases Angrylion RDP Plus]====<br />
This is a fork of Angrylion's RDP that supports multithreading. It 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, as does using it alongside an RSP plugin with a recompiler such as ParaLLEl-RSP, but some games are still not full speed even on a Core i7-8700K. It also allows you to disable VI filters for slightly better performance. This fork has at least one accuracy regression compared to the official version of Angrylion. 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.<br />
<br />
====Glide64====<br />
The former best general-use plugin. Versions of this are included in Project64, mainline Mupen64Plus, and the ParaLLEl-N64 libretro core. While it is no longer updated and is far less accurate and compatible than the newer offerings, it still has a few use cases, such as better support for older ROM hacks. It works relatively well for many (most?) games, has support for hi-res textures, and it is also faster than the newer plugins, which makes it suitable for slower devices such as the older Raspberry Pis. Otherwise, to ensure the highest possible compatibility, stick to either ParaLLEl-RDP or GLideN64.<br />
<br />
Note that the Project64 version of Glide64 has been renamed to Project64 Video and has undergone some changes and rewrites since it was initially forked, and thus may contain regressions compared to the last official standalone release of the plugin by Gonetz. Since this fork only works with current versions of Project64, should you wish to use this plugin on an older zilmar-spec emulator like 1964 or the original Mupen64, or if you want to avoid potential regressions with the Project64 version, use [https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/glidehqplusglitch64/Glide64_Final.zip Glide64 Final] instead.<br />
<br />
===Deprecated Plugins===<br />
The following video plugins are old and deprecated, and should not be used or considered unless you have a VERY old or underpowered device that cannot handle the recommended plugins, or there's a very specific use case not covered by modern implementations.<br />
<br />
*Jabo's Direct3D8 - Comes with Project64, and was once its default video plugin. Very speedy, has built-in AA and AF options, and includes a [[Widescreen_Hack|widescreen hack]]. The version included with the most recent versions of Project64 (1.7.0.57-ver5) is somewhat buggy and has regressions, however. [http://www.jabosoft.com/articles/114 Jabo's 1.6.1 patch] is better, though version 1.7 can run in LLE mode, which can help with a few games. Sadly, it will likely never see another update again, and though it is still included in Project64 to this day, it is no longer the default, and should not be used unless you have a very old PC that cannot handle Glide64 or GLideN64.<br />
*[http://www.emutalk.net/threads/54166-Rice-Video-Community-version Rice Video] - A very 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, all aiming to fix issues or add features, and an OpenGL version of it is included in mainline Mupen64Plus and in the ParaLLEl-N64 libretro core. It eventually lost favor with the wider community, as even during its heyday it was not a very compatible plugin, and once the much-superior Glide64 also gained the ability to load custom textures, there was little reason to use it beyond its speed. The so-called "Community 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. If you are absolutely resolved to try it out, seek out the original versions by Rice, primarily 6.1.0 or 6.1.1b.<br />
*[http://www.emutalk.net/threads/40640-Z64-a-LLE-graphics-plugin z64gl] - A hardware-rendered, low-level plugin developed by ziggy, derived from MAME's N64 driver. It was once notable for being one of the only plugins that could play games without an HLE microcode implementation such as Rogue Squadron. However, it was rather glitchy, had higher system requirements than the HLE plugins, needed an LLE RSP plugin to work (such as the bundled z64 RSP or Project64's RSP plugin set to LLE graphics), and configuration required editing the config file directly. A [https://github.com/purplemarshmallow/z64/tree/angrylion-integration fork] cropped up that aimed at improving it, but it did not go very far. Nowadays, it's obsolete, as GLideN64 can now play every game through HLE (thus subverting z64gl's only selling point), and its LLE has been surpassed by Angrylion-derived plugins and even GLideN64's LLE mode.<br />
*[https://sourceforge.net/p/angrylions-stuff/code/HEAD/tree/ Official Angrylion RDP] - A software-rendered, hardware-accurate plugin, developed by angrylion (though derived from MAME, much like z64gl). This is the most accurate N64 video plugin in existence, emulating almost* every facet of the N64's RDP precisely and thus making it capable of playing almost every single game in the N64 library with no issues, fixing even notorious cases such as the ''Pokémon Snap'' red dot and the ''Body Harvest'' bridge. This, however, comes at the cost of insane CPU requirements while making games look like, well, N64 games running on real hardware, which means native resolution, no widescreen, no hi-res textures - just the N64 in its full, vaseline-covered glory. Since this particular version is single-threaded, uses DirectDraw and is Windows only, it is recommended to use Angrylion RDP Plus or ParaLLEl-RDP instead, which offer much more reasonable performance. Only try it out if you have a tricked-out rig and want to test your CPU's mettle, or if you can compile it from source and need it for testing/debugging purposes, as the latest updates are always made to this version first.<br />
*[http://www.emutalk.net/threads/55481-angrylion-s-Per-Pixel-RDP-with-OpenGL HatCat/angrylion's Pixel-Accurate N64 Plugin] - This is a fork of Angrylion's RDP, done by HatCat. It has some optimizations not present in the official code, but is outdated and lacking some accuracy improvements and optimizations written by Angrylion. It has the option to disable the VI filters (which gives a speed boost), as well as the ability to set custom resolutions. Also, this version uses OpenGL 1.x instead of Direct Draw and supports Linux. Obsoleted by newer forks such as Angrylion RDP Plus.<br />
<br />
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:<br />
<br />
<gallery widths="300" mode="packed"><br />
Mario Tennis Rice.png|Mario Tennis running on ParaLLEl-N64 using Rice. Missing various effects, heavily glitched court.<br />
Mario Tennis Glide64.png|Mario Tennis running on ParaLLEl-N64 using Glide64. Missing various effects and shadows, some glitches.<br />
Mario Tennis glN64.png|Mario Tennis running on ParaLLEl-N64 using glN64. Missing various effects; shadows are present, but glitched.<br />
Mario Tennis GLideN64 HLE.png|Mario Tennis running on Mupen64Plus-Next using GLideN64 in HLE mode with 16xMSAA. Minor text cutoff on bottom of scoreboard.<br />
Mario Tennis GLideN64 LLE.png|Mario Tennis running on Mupen64Plus-Next using GLideN64 in LLE mode with 16xMSAA. Minor text cutoff on bottom of scoreboard. Has slight polygon jitter not present in HLE.<br />
Mario Tennis ParaLLEl 1x.png|Mario Tennis running on Mupen64Plus-Next using ParaLLEl-RDP at native resolution. Identical to Angrylion, and thus a pixel-perfect representation of real hardware.<br />
Mario Tennis ParaLLEl 4x Downsampled.png|Mario Tennis running on Mupen64Plus-Next using ParaLLEl-RDP rendering at 4x resolution, then downsampled back to native resolution.<br />
Mario Tennis ParaLLEl 4x.png|Mario Tennis running on Mupen64Plus-Next using ParaLLEl-RDP rendering at 4x resolution. Has very slight polygon jitter, though less than GLideN64 in LLE.<br />
</gallery><br />
<br />
<nowiki>*</nowiki> There is at least one known, relatively minor graphical glitch in Pokemon Snap (go figure) using Angrylion that requires currently-unimplemented cycle-accurate behavior to fix without resorting to hacks.<br />
<br />
==Audio==<br />
This section will only cover the zilmar spec plugins, as Mupen64Plus does not have any alternative audio plugins besides the default, and neither do the libretro forks.<br />
<br />
*Project64 Audio - The default audio plugin for Project64, apparently loosely based off of code from Mupen64Plus's HLE RSP. Very barebones, with no options to speak off.<br />
*Jabo's DirectSound - Comes with Project64. It works fine for the most part, but some games may not play nice with it. It is a low-level plugin, so it needs an accompanying LLE RSP plugin. Will probably never be updated again.<br />
*[http://www.emutalk.net/threads/27610-Audio-v0-56-WIP2-Download-Feedback Azimer's HLE Audio] - This popular HLE audio plugin boasts high compatibility. Version 0.56WIP2 is old as hell, but it is the tried and true standard to which audio plugins are compared against. Recently, [https://github.com/Azimer/AziAudio Azimer open sourced his plugin], and there were plans to integrate it into Project64, though this has yet to happen. While the latest development versions have a few issues, it now works in LLE, and has integrated code from Mupen64Plus's HLE RSP plugin, allowing it to work with the Factor 5 and BOSS games even in HLE.<br />
*[http://forum.pj64-emu.com/showthread.php?t=3644 Shunyuan's HLE Audio] - An audio plugin, apparently based on 1964Audio and HatCat's RSP plugin. Can run in both LLE and HLE modes despite the name, though the HLE mode just makes it run an outdated, baked-in version of HatCat's RSP, which makes it not a true HLE plugin. Has been abandoned after charges of just taking others' code without revealing a source. If games run at a weird speed using this plugin, go to the ROM's Game Settings, and disable Fixed Audio Timing and Sync using Audio. Though it worked surprisingly well despite its Frankenstein nature, modern development versions of Project64 no longer work with it, apparently due to it depending on a bug that has now been fixed. As such, it is probably better to use Azimer's plugin instead.<br />
<br />
==Input==<br />
*Project64 Input - Comes with Project64 as of the latest versions. Very simple input plugin which looks suspiciously a lot like Jabo's, but at least has XInput support, which is nice.<br />
*[https://sourceforge.net/projects/nragev20/ NRage Input] - Also comes with Project64 as of version 2.2. Hands down the best input plugin as it is more feature complete than Jabo's DirectInput. Has a ton of options and great controller compatibility, including XInput support for use with Xbox 360 controllers. It can't emulate the microphone that is required by ''Hey You, Pikachu'' or the printer required for the ''Pokémon Snap Station''. It has the ability to emulate Controller Pak (''Mario Kart 64'''s ghost saves), Rumble Pak (''Star Fox 64''), and Transfer Pak (''Pokémon Stadium'' series) functionality fairly well. Version 2.3 of Project64 introduced a version of the plug-in that can emulate the N64's mouse accessory designed for the 64DD to coincide with Project64's newest ability to emulate the 64DD accessory. Surprisingly, ''Mario Artist: Paint Studio'' can use the Japanese ''Game Boy Camera'' (called ''Pocket Camera'') in Transfer Pak mode, but the camera function doesn't work as it displays static, although importing captured images still works technically.<br />
*Jabo's DirectInput - Used to come with Project64, but now removed in favor of NRage Input. It isn't too bad, 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 usual, do not expect any updates.<br />
*[https://www.raphnet-tech.com/products/raphnetraw/index.php/ Raphnetraw] - This open source plugin allows streamlined use of N64 controller(s) via raphnet [https://www.raphnet-tech.com/products/n64_usb_adapter_gen3/index.php N64-to-USB v3+ adapters]. It supports rumble and is available for Project64 and mupen64plus. Also contains various DLLs for special port arrangements [https://www.raphnet.net/programmation/mupen64plus-input-raphnetraw/index_en.php#4 (link)].<br />
<br />
==RSP==<br />
===Recommended Plugins===<br />
*Zilmar's RSP - Comes with Project64. Reasonably accurate, quite fast in Recompiler mode (enabled by default), and will work fine for the 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.<br />
*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. 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 a pure LLE audio plugin and requires LLE RSP emulation.<br />
*[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 one of the most accurate RSP plugins, though zilmar's RSP in Recompiler mode as well as ParaLLEl-RSP both trump it in speed. It can take advantage of SSSE3 for greater performance, though it also comes in SSE2 and non-SSE variations in case your PC does not support those instruction sets. In both the zilmar and Mupen64Plus versions (though not in libretro, it seems), it is capable of working with both HLE and LLE audio and video plugins via the following settings:<br />
**Simulate RSP graphics from external plugin - Check if using an HLE graphics plugin, uncheck if using LLE<br />
**Simulate RSP audio from external plugin - Check if using an HLE audio plugin, uncheck if using LLE<br />
**Force semaphore locking - Check to fix issues with Mario no Photopie. Only works with Project64 2.x and beyond.<br />
*ParaLLEl-RSP - A fast and accurate RSP written by [https://github.com/Themaister/parallel-rsp Themaister], though it borrows heavily from both CXD4 and CEN64's RSP code. It is about as accurate and compatible as CXD4, while being much faster owing to its inclusion of a dynamic recompiler. 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). Note that it only works with LLE video and audio plugins, though it is highly recommended if using such.<br />
<br />
===Deprecated Plugins===<br />
*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 and many other compatibility fixes were later added to the Mupen64Plus version, which has now been ported to the zilmar spec after years of exclusivity on the Mupen64Plus side of things. As such, this version is officially obsolete.<br />
*z64 RSP plugin pack - Largely deprecated by the Static Interpreter/CXD4 RSP plugin. This set of RSP plugins comes with the z64 video plugin, each with their own purpose:<br />
**Ziggy-z64RSP - This RSP is based on the MAME/MESS RSP code. It is slower but more accurate.<br />
**Ziggy-PJ64 - Based on the Project64 1.4 RSP, this plugin is much faster.<br />
**angrylion - This RSP is a simple Interpreter, and is required for a few games like World Driver Championship to work correctly with z64gl.<br />
<br />
==Recommended N64 Setups==<br />
<br />
===Project64 and Others===<br />
Project64 comes bundled with the following plugins:<br />
*Video: Jabo's Direct3D8, Project64 Video (Glide64 under another name), GLideN64<br />
*Audio: Jabo's DirectSound, Project64 Audio<br />
*Input: NRage for Project64, Project64 Input<br />
*RSP: zilmar's RSP<br />
Should you wish to use other plugins, they must be downloaded from a third party source and dropped into their respective plugin folder categories in the Project64 directory. Video plugins go under Plugin/GFX, audio plugins under Plugin/Audio, etc.<br />
<br />
*'''General Use'''<br />
**GLideN64<br />
**Azimer's Audio NEW (set to LLE)<br />
**Static Interpreter RSP or Zilmar's RSP<br />
**Either of the RSP plugins should be fine for most games. The Static Interpreter RSP is slightly more accurate, whereas zilmar's is much faster. Should you wish to use GLideN64 in LLE mode (or any LLE video plugin for that matter), if using zilmar's RSP, simply uncheck "Graphics HLE" in the Plugin configuration screen. If using the Static Interpreter RSP, you'll have to run the spconfig.exe that comes with that plugin, and tell it to NOT "simulate RSP graphics from external plugin" (in other words, type "0"). ParaLLEl-RSP only works in LLE, so GLideN64's HLE mode will be unavailable with that plugin.<br />
*'''Best Performance'''<br />
**Project64 Video<br />
**Azimer's HLE Audio<br />
**Zilmar's RSP or Mupen64Plus HLE RSP<br />
**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.<br />
*'''Accuracy'''<br />
**Angrylion RDP Plus<br />
**Azimer's Audio NEW<br />
**Static RSP Interpreter<br />
**If you have a decent quad-core CPU, you can run many N64 games with pixel-perfect graphics at full speed, thanks to the new multithreaded version of angrylion's software plugin. The new Azimer's plugin (still WIP) works good in LLE. Since there's almost no visual difference, you may as well use PJ64's RSP or ParaLLEl-RSP to get better performance, and/or move to ParaLLEl-RDP outright for even greater speed and upscaling options to boot (though it goes without saying upscaling would no longer be accurate). Conversely, if you want even greater accuracy, disable "Hide advanced settings" under Configuration, then enable "Always use interpreter core" under Advanced, and under Angrylion's options, disable multi-threading and set compatibility to "Slow". Performance WILL crash, but hey, it'll be accurate!<br />
<br />
===Mupen64Plus===<br />
The official releases of Mupen64Plus only come bundled with a handful of video and RSP plugins, namely Glide64mk2, Rice, and the HLE RSP. The developers also maintain forks of the CXD4 RSP and the z64 video and RSP plugins, but they are not included in the official release bundles for some reason. Should you wish to use those plugins or third party ones such as GLideN64 or the ParaLLEl plugins, you must build them yourself or get them from outside sources. Due to this fact, the mediocre nature of the "official" video plugins, and the overall lack of user-friendliness, it may be better to use a fork such as [[m64p]] or [[RMG]], though note that m64p only comes and works with the ParaLLEl plugins, so RMG is a better choice if you wish to use something else, as that comes with more plugins and allows you to use whichever ones you want.<br />
*'''General Use'''<br />
**Video: GLideN64 or ParaLLEl-RDP<br />
**RSP: RSP-HLE (for GLideN64) or ParaLLEl-RSP (for ParaLLEl-RDP)<br />
**Either one of these combinations will enable you to play the vast majority of N64 games while having reasonable system requirements. GLideN64 is faster and has more enhancement options, but ParaLLEl-RDP is much more accurate to the real console. You can also use the CXD4 RSP with GLideN64 if you want, but be sure to set it to pass display lists to the graphics plugin in mupen64plus.cfg, else GLideN64 will switch to its LLE mode, which is not generally recommended to use.<br />
*'''Best Performance'''<br />
**Video: Glide64mk2<br />
**RSP: RSP-HLE<br />
**These are Mupen64Plus's default plugins. Glide64mk2 is based on Glide64 Final, and is named so as to differentiate it from the original, now obsolete fork of Glide64 that Mupen64Plus used at its inception. It is not up to GLideN64's level, but it does well enough for many games and is quite fast. Use this combination if you have a lower end PC that can't handle the General Use setup. If your device STILL can't handle this setup, try the Rice video plugin, but expect many missing effects, glitches and incompatibilities.<br />
*'''Accuracy'''<br />
**Video: Angrylion Plus or ParaLLEl-RDP<br />
**RSP: CXD4-ssse3 or ParaLLEl-RSP<br />
**Any combination of these should result in very high accuracy. Technically, the most accurate setup is Angrylion combined with CXD4, but the difference between these and the ParaLLEl plugins is almost negligible, while being a lot slower. Be sure to set the CPU core to Pure Interpreter for even greater accuracy, along with plummeting framerates.<br />
<br />
Note: In some cases the cfg file may not appear, in which case you may do this:<br />
*Open terminal in emulator folder on in its respective directory<br />
*''mupen64plus --configdir'' /directory/where/you/want/it/to/be<br />
<br />
===Libretro===<br />
There are two N64 libretro emulator cores for use on libretro frontends such as [[RetroArch]]: Mupen64Plus-Next and ParaLLEl-N64. The former is up-to-date and is recommended for most use cases, while the latter is no longer updated and is only around for performance reasons. They also have access to the following plugins:<br />
*Shared by both cores<br />
**Video: ParaLLEl-RDP , Angrylion<br />
**RSP: ParaLLEl-RSP, HLE, CXD4<br />
*Exclusive to Mupen64Plus-Next<br />
**GLideN64<br />
*Exclusive to ParaLLEl-N64<br />
**glN64, Rice, Glide64<br />
Due to these differences, it is advisable to use Mupen64Plus-Next for general use, and ParaLLEl-N64 for performance.<br />
*'''General Use (LLE)'''<br />
**Core: Mupen64Plus-Next<br />
**Video: ParaLLEl-RDP<br />
**RSP: ParaLLEl-RSP<br />
**By default ParaLLEl-RDP will output at native resolution with all the VI filters on, making it look exactly like Angrylion and the real N64 console. Upscaling must therefore be enabled in the core options. You can also alternatively render at a high resolution and downsample to a lower one if you want to improve 3D without making it stick out from 2D elements too much.<br />
*'''General Use (HLE)'''<br />
**Core: Mupen64Plus-Next<br />
**Video: GLideN64<br />
**RSP: HLE<br />
**While GLideN64 also works with the ParaLLEl and CXD4 RSP plugins, using them will cause GLideN64 to switch to its LLE mode, which is currently glitchier and slower than the HLE mode, for few compatibility or accuracy benefits, if any. As such, it is recommended to stick with the HLE RSP for GLideN64.<br />
*'''Best Performance'''<br />
**Core: ParaLLEl-N64<br />
**Video: Glide64<br />
**RSP: HLE<br />
**For slow, low-end devices and old PCs only. If further speed is desired or needed, you may try glN64 or Rice, but using them comes at a steep cost in compatibility and accuracy, and many low-end devices in use today ought to be able to handle Glide64 just fine (well, with the exception of certain underpowered "retro gaming" handhelds).<br />
*'''Accuracy'''<br />
**Core: Mupen64Plus-Next<br />
**Video: Angrylion<br />
**RSP: CXD4<br />
**Just like the developers intended! If you want to go all out, set the CPU core to Pure Interpreter, turn off multi-threading and set thread sync level to High in Angrylion's options for the real 30 VI/s experience. Closest you'll get to real hardware until a complete cycle-accurate N64 emulator surfaces.<br />
<br />
[[Category:Recommendations]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=CRT_shaders&diff=48442CRT shaders2022-07-14T09:24:11Z<p>GPDP1: Merged guest-dr-venom into guest-advanced. Decided there's no reason for it to have its own section when it's essentially just an earlier version of the same shader</p>
<hr />
<div>[[File:Retroarch_2013-07-22_17-21-17-60.png|thumb|298px|CRT-Geom-Flat, with default settings]]<br />
CRT shaders are one of the most popular categories of shaders. While there had been many attempts to include some kind of CRT-esque filters in older emulators - usually involving little more than overlaying dark gray or black lines, colloquially referred to as scanlines, over the image - modern CRT shaders are much more complex and configurable.<br />
<br />
Many of these replicate aperture grille CRTs (exemplified primarily by Sony TVs and monitors, though other manufacturers released their own versions of the technology later on), which have sharp images and strong scanlines. If you find that these shaders don't look a damn thing like your old TV, it's probably because you owned a slot mask-style CRT, which typically had less noticeable scanlines, or simply had a smaller set, which tended to be less sharp. The easiest way to tell the difference is to feel the curve of the screen; aperture grilles only curve horizontally if at all. Alternatively, look at the left and right sides of the glass against the frame - if the sides are curved, it's a slot mask; if they're straight, it's an aperture grille. Old TVs usually had slot masks, whereas monitors usually had shadow masks. While slot masks and shadow masks can be emulated to a certain degree even at 1080p, much higher resolutions like 4K or higher are better suited to the task. Aperture grilles are much easier to emulate, and can be satisfactorily replicated at 1080p, though it goes without saying even better results can be achieved with higher resolution.<br />
<br />
It is advisable to use integer scaling when using CRT shaders. This means either using windowed mode (x2,x3,x4) or setting an integer scaling option in the video options. The reason is that non-integer scaled scanlines will result in uneven lines with artifacts, though some shaders use oversampling to try to avoid this. If the resulting letterboxing annoys you and you still want to fill up as much of your screen's real estate as possible, you can also try integer scale overscaling, which scales the image up by another integer to fill the vertical image space while still preserving integer scaling, at the expense of some of the image on the top and bottom being cut off. As an example, at 1080p, turning on overscaling would scale a typical SNES game running at 256x224 to 5x scale i.e. 1280x1120, cutting off twenty pixels from both the top and bottom of the image to reach 1080p. Before you fret, know that at 1080p and 4K the loss from overscaling is usually negligible and well within the area that would've been expected to be cut off on a real CRT anyway due to overscan, and developers almost always took this into account and made sure not to put any crucial game information there, so on many if not most older games, overscaling is completely safe.<br />
<br />
==Download==<br />
All official releases of RetroArch come bundled with a full set of slang and GLSL shaders, including CRT shaders, pulled from their shader repositories on Github, which are regularly maintained and updated. The simplest way to keep up to date with shader development is through RetroArch's built-in updater, though if you are only interested in the CRT shaders, you can alternatively grab them from the following repos:<br />
<br />
[https://github.com/libretro/slang-shaders/tree/master/crt slang shaders] - For use with devices that support Vulkan, OpenGL 3.x, GLES3, and/or D3D10/11/12. This is the most current, regularly maintained repository.<br />
<br />
[https://github.com/libretro/glsl-shaders/tree/master/crt GLSL shaders] - For use with devices that only support up to OpenGL 2.x or GLES2. Largely deprecated, though still sporadically maintained.<br />
<br />
[https://github.com/libretro/common-shaders/tree/master/crt Cg shaders] - For use on platforms that only support Cg or HLSL runtimes, such as the PS3. Deprecated.<br />
<br />
==Types==<br />
===CRT-Geom===<br />
[[File:Retroarch_2013-07-22_17-21-17-60.png|thumb|298px|CRT-Geom-Flat, with default settings]]<br />
{{Main|CRT Geom}}<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-geom.slang crt-geom.slang]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-cgwg-fast.slang crt-cgwg-fast.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/geom-deluxe crt-geom-deluxe]<br />
<br />
A very versatile and modifiable shader that simulates an aperture grille display (with the mask enabled). One of the first popular CRT shaders. The deluxe version adds more features, including more mask types. Visit the main article for more details.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
----<br />
===CRT-Caligari===<br />
[[File:crt-caligari-sm.png|thumb|298px|CRT-Caligari, with default settings at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-caligari.slang crt-caligari.slang]<br />
<br />
An older CRT shader similar to CRT-Geom that uses different methods to achieve its effects.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
----<br />
===CRT-Easymode===<br />
[[File:crt-easymode.png|thumb|298px|CRT-Easymode, with default settings at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-easymode.slang crt-easymode.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-easymode-halation crt-easymode-halation]<br />
<br />
A fast, relatively simple CRT shader with easy-to-understand settings. Similar to CRT-Geom in its effects.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
----<br />
===CRT-Hyllian===<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/hyllian crt-hyllian]<br />
*[https://forums.libretro.com/t/crt-hyllian-and-its-variants/38137 Hyllian's shader development thread]<br />
<br />
Aims only for picture quality, so it avoids things that degrade the image just for accuracy. It, however, uses far less power to run than most other CRT shaders, so it is possible to run this on lower end systems. <br />
<br />
Recently, after a long period of inactivity, Hyllian has restarted shader development anew, releasing all-new versions of this shader under heavy inspiration from CRT-Guest-Advanced and others. They can be acquired at his thread on the libretro forums, linked above.<br />
<br />
<br />
----<br />
===CRT-Lottes===<br />
[[File:crt-lottes-multipass.png|thumb|298px|CRT-Lottes-Multipass, with default settings at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-lottes.slang crt-lottes.slang]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-lottes-fast.slang crt-lottes-fast.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-lottes-multipass crt-lottes-multipass]<br />
<br />
A newer CRT shader that uses a horizontal shadow mask pattern with blooming. The horizontal pattern works quite well at 1080p, though it isn't entirely accurate to a true vertical slot mask pattern. The multipass version adds scanline bloom and a few other features.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
----<br />
===GTU===<br />
[[File:GTU.png|thumb|298px|GTU, with default settings at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/gtu-v050 GTUv050 slang]<br />
*[https://github.com/hizzlekizzle/quark-shaders/tree/master/GTU.shader GTUv040 Quark]<br />
*[https://github.com/libretro/slang-shaders/tree/master/nes_raw_palette/shaders/gtu-famicom GTU-Famicom slang]<br />
*[https://github.com/hunterk/interpolation-shaders/raw/master/GTUv050test.tar.gz GTUv50 Test program]<br />
<br />
A CRT shader that focuses more on simulating blur and blending effects and color levels of CRT screens rather than the physical attributes like phosphors and curvature. Highly configurable, can be really sharp, or really blurry or anywhere in between, with optional scanlines and contrast and gamma settings. Settings are stored in a separate "config.h" file for easy editing. GTU-Famicom is a variant that takes an image from an NES with "raw" colors and processes it to output an NTSC image much like an actual NES PPU.<br />
<br />
The test program is a program that can adjust various attributes, such as horizontal and vertical blur, scanlines, etc. It is useful for testing settings to use with the shader, and also to understand how CRT shaders work in general.<br />
<br />
<br />
<br />
<br />
<br />
<br />
----<br />
===ZFast_CRT===<br />
[[File:crt-zfast.png|thumb|298px|ZFast_CRT, with aperture grille mask enabled at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/zfast_crt zfast_crt]<br />
<br />
An extremely fast CRT shader made to run at full speed on extremely low-end hardware like the Raspberri Pi 3. Probably the fastest shader on this list.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
----<br />
===CRT-Royale===<br />
{{Main|CRT-Royale}}<br />
[[File:crt-royale.png|thumb|298px|CRT-Royale, with default settings at 1080p (view original for full details)]]<br />
<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-royale CRT-Royale]<br />
*[https://github.com/libretro/slang-shaders/blob/master/presets/crt-royale-kurozumi.slangp CRT-Royale-Kurozumi]<br />
<br />
A highly advanced multi-pass CRT shader that simulates almost every aspect of the CRT screen. There are tons of parameters to configure, such as phosphor type (aperture grille, slot mask, and EDP shadow mask) and size (i.e. dot pitch), convergence offsets, scanline blooming and many others. Higher resolution is better for this shader, especially with EDP shadow mask phosphor layout and with smaller phosphor dot pitch values. This shader is really complicated compared to most other CRT shaders, reading the README and the documentation in the user-settings.h is a must.<br />
<br />
CRT-Royale-Kurozumi is a preconfigured CRT-Royale made to look like a professional CRT monitor, specifically Sony's PVM/BVM line of monitors.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
----<br />
===CRT-Guest-Advanced===<br />
[[File:crt-guest-dr-venom.png|thumb|298px|CRT-Guest-Dr-Venom, with default settings at 1080p. The newer Advanced shader's default settings look identical (view original for full details)]]<br />
*[https://forums.libretro.com/t/new-crt-shader-from-guest-crt-guest-advanced-updates/25444 Guest's shader development thread]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/guest/crt-gdv-new crt-guest-dr-venom]<br />
<br />
This is quite possibly the most advanced, feature-rich CRT shader of all. It has just as many if not more parameters to configure than CRT-Royale while being more optimized, and if greater speed is desired, there are several faster versions available, as well as variants that add other neat features such as NTSC emulation and better support for games that render at 480p or higher. It is also still in active development and continues to regularly gain features and optimizations. Take heed, however: it is also one of the only shaders without a central public Github repo, as its developer has opted for release bundles linked to in the libretro forums instead. While RetroArch does host a version of it in their shader repos, it is highly outdated, so it is recommended to update it using the latest release from the developer's dedicated libretro forum thread, linked above.<br />
<br />
CRT-Guest-Dr-Venom is the precursor to CRT-Guest-Advanced. While it is now considered outdated and not as feature-filled as Guest's newest shaders, it is much faster, more so than even the fastest Advanced preset, and it still has plenty of things to tweak to deliver a pleasing image. It therefore fills a middle-of-the-road niche among CRT shaders, delivering a nice balance of features and performance.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
----<br />
===Sony Megatron===<br />
[[File:sony-megatron.png|thumb|298px|Sony Megatron, using the reference preset in SDR mode with the "1000 TVL" aperture grille mask (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/tree/master/hdr Sony Megatron]<br />
*[https://forums.libretro.com/t/sony-megatron-colour-video-monitor/36109 Sony Megatron development and discussion thread]<br />
<br />
This shader is quite unique among CRT shaders, and shaders in general. It is currently the only shader that takes advantage of HDR support for greater color depth and brightness, allowing for highly accurate CRT emulation on HDR-capable displays, though it is also usable on regular SDR displays through a parameter change. Unlike other CRT shaders, its inner workings are actually fairly simple and it doesn't have many bells and whistles, focusing mainly on drawing scanlines and accurate phosphor masks as well as color correction, which coincidentally also makes it one of the fastest shaders featured on this page. As it is primarily meant for use on bright HDR-capable displays, it draws phosphor masks at full strength with no attempt at mitigating the resulting loss in brightness through parameters such as bloom, glow or mask strength typically seen in other CRT shaders, instead counting on the display to make up for it. On an SDR display, it is highly recommended to use it with the backlight turned up all the way, as otherwise the image will likely be too dim to view comfortably. There are presets emulating various CRT models and types, including several PVM models, certain arcade displays, and even PC monitors.<br />
<br />
==Future==<br />
<br />
===Phosphor Mask Emulation===<br />
At the frontier of CRT shader development has been phosphor mask emulation. As stated previously, there are three overarching mask types: aperture grilles, shadow masks and slot masks. Aperture grilles were used primarily by Sony TVs, professional displays and PC monitors (with a few other brands such as Mitsubishi releasing their own version after Sony's Trinitron patent expired in the late 90's), shadow masks by the majority of PC CRT monitors from the late 80's onwards, and slot masks by just about every non-Sony consumer-level CRT TV, the vast majority of arcade monitors, and very early home computer/PC monitors. A key part of CRT emulation, then, depends on accurately replicating the look of these masks.<br />
<br />
However, even within each of these mask types, there is a lot of variance, as some CRTs were much sharper and were able to resolve a lot more detail than others. This is encapsulated in a specification known as TVL, or television lines, defined as the number of vertical white lines a mask can resolve along the horizontal dimension in a stretch equal to the height of the tube's viewable area (this means TVL is calculated by measuring the screen's height, then counting the number of resolved lines across a horizontal span equal to that height, not across the entire length of the screen). A higher TVL count is the result of higher phosphor density and results in a sharper, more detailed image, as well as more prominent scanlines in low-res content. Most consumer-level CRTs had a relatively low TVL count, whereas professional monitors such as Sony's PVM and BVM series had much higher TVL. In PC monitors, the usual specification to determine sharpness was instead dot pitch, or the distance between two phosphors of the same color. The lower the dot pitch, the sharper the monitor and the more detail it could resolve.<br />
<br />
Taking into account the three mask types and the variance in TVL and dot pitch, then, along with many other variables, it is no wonder no two CRTs looked alike.<br />
<br />
==External Links==<br />
*[http://filthypants.blogspot.com/2015/04/more-crt-shaders.html More CRT Shaders (filthypants.blogspot.com)] - hunterk's comparison of current CRT shaders. <br />
<br />
[[Category:FAQs]]<br />
[[Category:Shaders/Filters]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=CRT_shaders&diff=48324CRT shaders2022-07-12T03:59:09Z<p>GPDP1: Added Sony Megatron screenshot, and updated the Royale shot for consistency with the others</p>
<hr />
<div>[[File:Retroarch_2013-07-22_17-21-17-60.png|thumb|298px|CRT-Geom-Flat, with default settings]]<br />
CRT shaders are one of the most popular categories of shaders. While there had been many attempts to include some kind of CRT-esque filters in older emulators - usually involving little more than overlaying dark gray or black lines, colloquially referred to as scanlines, over the image - modern CRT shaders are much more complex and configurable.<br />
<br />
Many of these replicate aperture grille CRTs (exemplified primarily by Sony TVs and monitors, though other manufacturers released their own versions of the technology later on), which have sharp images and strong scanlines. If you find that these shaders don't look a damn thing like your old TV, it's probably because you owned a slot mask-style CRT, which typically had less noticeable scanlines, or simply had a smaller set, which tended to be less sharp. The easiest way to tell the difference is to feel the curve of the screen; aperture grilles only curve horizontally if at all. Alternatively, look at the left and right sides of the glass against the frame - if the sides are curved, it's a slot mask; if they're straight, it's an aperture grille. Old TVs usually had slot masks, whereas monitors usually had shadow masks. While slot masks and shadow masks can be emulated to a certain degree even at 1080p, much higher resolutions like 4K or higher are better suited to the task. Aperture grilles are much easier to emulate, and can be satisfactorily replicated at 1080p, though it goes without saying even better results can be achieved with higher resolution.<br />
<br />
It is advisable to use integer scaling when using CRT shaders. This means either using windowed mode (x2,x3,x4) or setting an integer scaling option in the video options. The reason is that non-integer scaled scanlines will result in uneven lines with artifacts, though some shaders use oversampling to try to avoid this. If the resulting letterboxing annoys you and you still want to fill up as much of your screen's real estate as possible, you can also try integer scale overscaling, which scales the image up by another integer to fill the vertical image space while still preserving integer scaling, at the expense of some of the image on the top and bottom being cut off. As an example, at 1080p, turning on overscaling would scale a typical SNES game running at 256x224 to 5x scale i.e. 1280x1120, cutting off twenty pixels from both the top and bottom of the image to reach 1080p. Before you fret, know that at 1080p and 4K the loss from overscaling is usually negligible and well within the area that would've been expected to be cut off on a real CRT anyway due to overscan, and developers almost always took this into account and made sure not to put any crucial game information there, so on many if not most older games, overscaling is completely safe.<br />
<br />
==Download==<br />
All official releases of RetroArch come bundled with a full set of slang and GLSL shaders, including CRT shaders, pulled from their shader repositories on Github, which are regularly maintained and updated. The simplest way to keep up to date with shader development is through RetroArch's built-in updater, though if you are only interested in the CRT shaders, you can alternatively grab them from the following repos:<br />
<br />
[https://github.com/libretro/slang-shaders/tree/master/crt slang shaders] - For use with devices that support Vulkan, OpenGL 3.x, GLES3, and/or D3D10/11/12. This is the most current, regularly maintained repository.<br />
<br />
[https://github.com/libretro/glsl-shaders/tree/master/crt GLSL shaders] - For use with devices that only support up to OpenGL 2.x or GLES2. Largely deprecated, though still sporadically maintained.<br />
<br />
[https://github.com/libretro/common-shaders/tree/master/crt Cg shaders] - For use on platforms that only support Cg or HLSL runtimes, such as the PS3. Deprecated.<br />
<br />
==Types==<br />
===CRT-Geom===<br />
{{Main|CRT Geom}}<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-geom.slang crt-geom.slang]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-cgwg-fast.slang crt-cgwg-fast.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/geom-deluxe crt-geom-deluxe]<br />
<br />
A very versatile and modifiable shader that simulates an aperture grille display (with the mask enabled). One of the first popular CRT shaders. The deluxe version adds more features, including more mask types. Visit the main article for more details.<br />
<br />
===CRT-Caligari===<br />
[[File:crt-caligari-sm.png|thumb|298px|CRT-Caligari, with default settings at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-caligari.slang crt-caligari.slang]<br />
<br />
An older CRT shader similar to CRT-Geom that uses different methods to achieve its effects.<br />
<br />
<br />
===CRT-Easymode===<br />
[[File:crt-easymode.png|thumb|298px|CRT-Easymode, with default settings at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-easymode.slang crt-easymode.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-easymode-halation crt-easymode-halation]<br />
<br />
A fast, relatively simple CRT shader with easy-to-understand settings. Similar to CRT-Geom in its effects.<br />
<br />
===CRT-Hyllian===<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/hyllian crt-hyllian]<br />
*[https://forums.libretro.com/t/crt-hyllian-and-its-variants/38137 Hyllian's shader development thread]<br />
<br />
Aims only for picture quality, so it avoids things that degrade the image just for accuracy. It, however, uses far less power to run than most other CRT shaders, so it is possible to run this on lower end systems. <br />
<br />
Recently, after a long period of inactivity, Hyllian has restarted shader development anew, releasing all-new versions of this shader under heavy inspiration from CRT-Guest-Advanced and others. They can be acquired at his thread on the libretro forums, linked above.<br />
<br />
===CRT-Lottes===<br />
[[File:crt-lottes-multipass.png|thumb|298px|CRT-Lottes-Multipass, with default settings at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-lottes.slang crt-lottes.slang]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-lottes-fast.slang crt-lottes-fast.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-lottes-multipass crt-lottes-multipass]<br />
<br />
A newer CRT shader that uses a horizontal shadow mask pattern with blooming. The horizontal pattern works quite well at 1080p, though it isn't entirely accurate to a true vertical slot mask pattern. The multipass version adds scanline bloom and a few other features.<br />
<br />
===GTU===<br />
[[File:GTU.png|thumb|298px|GTU, with default settings at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/gtu-v050 GTUv050 slang]<br />
*[https://github.com/hizzlekizzle/quark-shaders/tree/master/GTU.shader GTUv040 Quark]<br />
*[https://github.com/libretro/slang-shaders/tree/master/nes_raw_palette/shaders/gtu-famicom GTU-Famicom slang]<br />
*[https://github.com/hunterk/interpolation-shaders/raw/master/GTUv050test.tar.gz GTUv50 Test program]<br />
<br />
A CRT shader that focuses more on simulating blur and blending effects and color levels of CRT screens rather than the physical attributes like phosphors and curvature. Highly configurable, can be really sharp, or really blurry or anywhere in between, with optional scanlines and contrast and gamma settings. Settings are stored in a separate "config.h" file for easy editing. GTU-Famicom is a variant that takes an image from an NES with "raw" colors and processes it to output an NTSC image much like an actual NES PPU.<br />
<br />
The test program is a program that can adjust various attributes, such as horizontal and vertical blur, scanlines, etc. It is useful for testing settings to use with the shader, and also to understand how CRT shaders work in general.<br />
<br />
===ZFast_CRT===<br />
[[File:crt-zfast.png|thumb|298px|ZFast_CRT, with aperture grille mask enabled at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/zfast_crt zfast_crt]<br />
<br />
An extremely fast CRT shader made to run at full speed on extremely low-end hardware like the Raspberri Pi 3. Probably the fastest shader on this list.<br />
<br />
===CRT-Royale===<br />
{{Main|CRT-Royale}}<br />
[[File:crt-royale.png|thumb|298px|CRT-Royale, with default settings at 1080p (view original for full details)]]<br />
<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-royale CRT-Royale]<br />
*[https://github.com/libretro/slang-shaders/blob/master/presets/crt-royale-kurozumi.slangp CRT-Royale-Kurozumi]<br />
<br />
A highly advanced multi-pass CRT shader that simulates almost every aspect of the CRT screen. There are tons of parameters to configure, such as phosphor type (aperture grille, slot mask, and EDP shadow mask) and size (i.e. dot pitch), convergence offsets, scanline blooming and many others. Higher resolution is better for this shader, especially with EDP shadow mask phosphor layout and with smaller phosphor dot pitch values. This shader is really complicated compared to most other CRT shaders, reading the README and the documentation in the user-settings.h is a must.<br />
<br />
CRT-Royale-Kurozumi is a preconfigured CRT-Royale made to look like a professional CRT monitor, specifically Sony's PVM/BVM line of monitors.<br />
<br />
===CRT-Guest-Advanced===<br />
*[https://forums.libretro.com/t/new-crt-shader-from-guest-crt-guest-advanced-updates/25444 Guest's shader development thread]<br />
<br />
This is quite possibly the most advanced, feature-rich CRT shader of all. It has just as many if not more parameters to configure than CRT-Royale while being more optimized, and if greater speed is desired, there are several faster versions available, as well as variants that add other neat features such as NTSC emulation and better support for games that render at 480p or higher. It is also still in active development and continues to regularly gain features and optimizations. Take heed, however: it is also one of the only shaders without a central public Github repo, as its developer has opted for release bundles linked to in the libretro forums instead. While RetroArch does host a version of it in their shader repos, it is highly outdated, so it is recommended to update it using the latest release from the developer's dedicated libretro forum thread, linked above.<br />
<br />
===CRT-Guest-Dr-Venom===<br />
[[File:crt-guest-dr-venom.png|thumb|298px|CRT-Guest-Dr-Venom, with default settings at 1080p. The newer Advanced shader's default settings look identical (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/guest/crt-gdv-new crt-guest-dr-venom]<br />
<br />
The precursor to CRT-Guest-Advanced. While it is now considered outdated and not as feature-filled as Guest's newest shaders, it is much faster, more so than even the fastest Advanced preset, and it still has plenty of things to tweak to deliver a pleasing image. It therefore fills a middle-of-the-road niche among CRT shaders, delivering a nice balance of features and performance.<br />
<br />
===Sony Megatron===<br />
[[File:sony-megatron.png|thumb|298px|Sony Megatron, using the reference preset in SDR mode with the "1000 TVL" aperture grille mask (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/tree/master/hdr Sony Megatron]<br />
*[https://forums.libretro.com/t/sony-megatron-colour-video-monitor/36109 Sony Megatron development and discussion thread]<br />
<br />
This shader is quite unique among CRT shaders, and shaders in general. It is currently the only shader that takes advantage of HDR support for greater color depth and brightness, allowing for highly accurate CRT emulation on HDR-capable displays, though it is also usable on regular SDR displays through a parameter change. Unlike other CRT shaders, its inner workings are actually fairly simple and it doesn't have many bells and whistles, focusing mainly on drawing scanlines and accurate phosphor masks as well as color correction, which coincidentally also makes it one of the fastest shaders featured on this page. As it is primarily meant for use on bright HDR-capable displays, it draws phosphor masks at full strength with no attempt at mitigating the resulting loss in brightness through parameters such as bloom, glow or mask strength typically seen in other CRT shaders, instead counting on the display to make up for it. On an SDR display, it is highly recommended to use it with the backlight turned up all the way, as otherwise the image will likely be too dim to view comfortably. There are presets emulating various CRT models and types, including several PVM models, certain arcade displays, and even PC monitors.<br />
<br />
==Future==<br />
<br />
===Phosphor Mask Emulation===<br />
At the frontier of CRT shader development has been phosphor mask emulation. As stated previously, there are three overarching mask types: aperture grilles, shadow masks and slot masks. Aperture grilles were used primarily by Sony TVs, professional displays and PC monitors (with a few other brands such as Mitsubishi releasing their own version after Sony's Trinitron patent expired in the late 90's), shadow masks by the majority of PC CRT monitors from the late 80's onwards, and slot masks by just about every non-Sony consumer-level CRT TV, the vast majority of arcade monitors, and very early home computer/PC monitors. A key part of CRT emulation, then, depends on accurately replicating the look of these masks.<br />
<br />
However, even within each of these mask types, there is a lot of variance, as some CRTs were much sharper and were able to resolve a lot more detail than others. This is encapsulated in a specification known as TVL, or television lines, defined as the number of vertical white lines a mask can resolve along the horizontal dimension in a stretch equal to the height of the tube's viewable area (this means TVL is calculated by measuring the screen's height, then counting the number of resolved lines across a horizontal span equal to that height, not across the entire length of the screen). A higher TVL count is the result of higher phosphor density and results in a sharper, more detailed image, as well as more prominent scanlines in low-res content. Most consumer-level CRTs had a relatively low TVL count, whereas professional monitors such as Sony's PVM and BVM series had much higher TVL. In PC monitors, the usual specification to determine sharpness was instead dot pitch, or the distance between two phosphors of the same color. The lower the dot pitch, the sharper the monitor and the more detail it could resolve.<br />
<br />
Taking into account the three mask types and the variance in TVL and dot pitch, then, along with many other variables, it is no wonder no two CRTs looked alike.<br />
<br />
==External Links==<br />
*[http://filthypants.blogspot.com/2015/04/more-crt-shaders.html More CRT Shaders (filthypants.blogspot.com)] - hunterk's comparison of current CRT shaders. <br />
<br />
[[Category:FAQs]]<br />
[[Category:Shaders/Filters]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=File:Sony-megatron.png&diff=48323File:Sony-megatron.png2022-07-12T03:52:59Z<p>GPDP1: </p>
<hr />
<div></div>GPDP1https://emulation.gametechwiki.com/index.php?title=File:Crt-royale.png&diff=48322File:Crt-royale.png2022-07-12T03:52:24Z<p>GPDP1: </p>
<hr />
<div></div>GPDP1https://emulation.gametechwiki.com/index.php?title=CRT_shaders&diff=48321CRT shaders2022-07-12T03:30:07Z<p>GPDP1: Added a bunch of screenshots showing off various CRT shaders with mostly default settings</p>
<hr />
<div>[[File:Retroarch_2013-07-22_17-21-17-60.png|thumb|298px|CRT-Geom-Flat, with default settings]]<br />
CRT shaders are one of the most popular categories of shaders. While there had been many attempts to include some kind of CRT-esque filters in older emulators - usually involving little more than overlaying dark gray or black lines, colloquially referred to as scanlines, over the image - modern CRT shaders are much more complex and configurable.<br />
<br />
Many of these replicate aperture grille CRTs (exemplified primarily by Sony TVs and monitors, though other manufacturers released their own versions of the technology later on), which have sharp images and strong scanlines. If you find that these shaders don't look a damn thing like your old TV, it's probably because you owned a slot mask-style CRT, which typically had less noticeable scanlines, or simply had a smaller set, which tended to be less sharp. The easiest way to tell the difference is to feel the curve of the screen; aperture grilles only curve horizontally if at all. Alternatively, look at the left and right sides of the glass against the frame - if the sides are curved, it's a slot mask; if they're straight, it's an aperture grille. Old TVs usually had slot masks, whereas monitors usually had shadow masks. While slot masks and shadow masks can be emulated to a certain degree even at 1080p, much higher resolutions like 4K or higher are better suited to the task. Aperture grilles are much easier to emulate, and can be satisfactorily replicated at 1080p, though it goes without saying even better results can be achieved with higher resolution.<br />
<br />
It is advisable to use integer scaling when using CRT shaders. This means either using windowed mode (x2,x3,x4) or setting an integer scaling option in the video options. The reason is that non-integer scaled scanlines will result in uneven lines with artifacts, though some shaders use oversampling to try to avoid this. If the resulting letterboxing annoys you and you still want to fill up as much of your screen's real estate as possible, you can also try integer scale overscaling, which scales the image up by another integer to fill the vertical image space while still preserving integer scaling, at the expense of some of the image on the top and bottom being cut off. As an example, at 1080p, turning on overscaling would scale a typical SNES game running at 256x224 to 5x scale i.e. 1280x1120, cutting off twenty pixels from both the top and bottom of the image to reach 1080p. Before you fret, know that at 1080p and 4K the loss from overscaling is usually negligible and well within the area that would've been expected to be cut off on a real CRT anyway due to overscan, and developers almost always took this into account and made sure not to put any crucial game information there, so on many if not most older games, overscaling is completely safe.<br />
<br />
==Download==<br />
All official releases of RetroArch come bundled with a full set of slang and GLSL shaders, including CRT shaders, pulled from their shader repositories on Github, which are regularly maintained and updated. The simplest way to keep up to date with shader development is through RetroArch's built-in updater, though if you are only interested in the CRT shaders, you can alternatively grab them from the following repos:<br />
<br />
[https://github.com/libretro/slang-shaders/tree/master/crt slang shaders] - For use with devices that support Vulkan, OpenGL 3.x, GLES3, and/or D3D10/11/12. This is the most current, regularly maintained repository.<br />
<br />
[https://github.com/libretro/glsl-shaders/tree/master/crt GLSL shaders] - For use with devices that only support up to OpenGL 2.x or GLES2. Largely deprecated, though still sporadically maintained.<br />
<br />
[https://github.com/libretro/common-shaders/tree/master/crt Cg shaders] - For use on platforms that only support Cg or HLSL runtimes, such as the PS3. Deprecated.<br />
<br />
==Types==<br />
===CRT-Geom===<br />
{{Main|CRT Geom}}<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-geom.slang crt-geom.slang]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-cgwg-fast.slang crt-cgwg-fast.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/geom-deluxe crt-geom-deluxe]<br />
<br />
A very versatile and modifiable shader that simulates an aperture grille display (with the mask enabled). One of the first popular CRT shaders. The deluxe version adds more features, including more mask types. Visit the main article for more details.<br />
<br />
===CRT-Caligari===<br />
[[File:crt-caligari-sm.png|thumb|298px|CRT-Caligari, with default settings at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-caligari.slang crt-caligari.slang]<br />
<br />
An older CRT shader similar to CRT-Geom that uses different methods to achieve its effects.<br />
<br />
<br />
===CRT-Easymode===<br />
[[File:crt-easymode.png|thumb|298px|CRT-Easymode, with default settings at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-easymode.slang crt-easymode.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-easymode-halation crt-easymode-halation]<br />
<br />
A fast, relatively simple CRT shader with easy-to-understand settings. Similar to CRT-Geom in its effects.<br />
<br />
===CRT-Hyllian===<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/hyllian crt-hyllian]<br />
*[https://forums.libretro.com/t/crt-hyllian-and-its-variants/38137 Hyllian's shader development thread]<br />
<br />
Aims only for picture quality, so it avoids things that degrade the image just for accuracy. It, however, uses far less power to run than most other CRT shaders, so it is possible to run this on lower end systems. <br />
<br />
Recently, after a long period of inactivity, Hyllian has restarted shader development anew, releasing all-new versions of this shader under heavy inspiration from CRT-Guest-Advanced and others. They can be acquired at his thread on the libretro forums, linked above.<br />
<br />
===CRT-Lottes===<br />
[[File:crt-lottes-multipass.png|thumb|298px|CRT-Lottes-Multipass, with default settings at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-lottes.slang crt-lottes.slang]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-lottes-fast.slang crt-lottes-fast.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-lottes-multipass crt-lottes-multipass]<br />
<br />
A newer CRT shader that uses a horizontal shadow mask pattern with blooming. The horizontal pattern works quite well at 1080p, though it isn't entirely accurate to a true vertical slot mask pattern. The multipass version adds scanline bloom and a few other features.<br />
<br />
===GTU===<br />
[[File:GTU.png|thumb|298px|GTU, with default settings at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/gtu-v050 GTUv050 slang]<br />
*[https://github.com/hizzlekizzle/quark-shaders/tree/master/GTU.shader GTUv040 Quark]<br />
*[https://github.com/libretro/slang-shaders/tree/master/nes_raw_palette/shaders/gtu-famicom GTU-Famicom slang]<br />
*[https://github.com/hunterk/interpolation-shaders/raw/master/GTUv050test.tar.gz GTUv50 Test program]<br />
<br />
A CRT shader that focuses more on simulating blur and blending effects and color levels of CRT screens rather than the physical attributes like phosphors and curvature. Highly configurable, can be really sharp, or really blurry or anywhere in between, with optional scanlines and contrast and gamma settings. Settings are stored in a separate "config.h" file for easy editing. GTU-Famicom is a variant that takes an image from an NES with "raw" colors and processes it to output an NTSC image much like an actual NES PPU.<br />
<br />
The test program is a program that can adjust various attributes, such as horizontal and vertical blur, scanlines, etc. It is useful for testing settings to use with the shader, and also to understand how CRT shaders work in general.<br />
<br />
===ZFast_CRT===<br />
[[File:crt-zfast.png|thumb|298px|ZFast_CRT, with aperture grille mask enabled at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/zfast_crt zfast_crt]<br />
<br />
An extremely fast CRT shader made to run at full speed on extremely low-end hardware like the Raspberri Pi 3. Probably the fastest shader on this list.<br />
<br />
===CRT-Royale===<br />
{{Main|CRT-Royale}}<br />
[[File:CRT-Royale.png|thumb|298px|CRT-Royale, with default settings at 1080p (view original for full details)]]<br />
<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-royale CRT-Royale]<br />
*[https://github.com/libretro/slang-shaders/blob/master/presets/crt-royale-kurozumi.slangp CRT-Royale-Kurozumi]<br />
<br />
A highly advanced multi-pass CRT shader that simulates almost every aspect of the CRT screen. There are tons of parameters to configure, such as phosphor type (aperture grille, slot mask, and EDP shadow mask) and size (i.e. dot pitch), convergence offsets, scanline blooming and many others. Higher resolution is better for this shader, especially with EDP shadow mask phosphor layout and with smaller phosphor dot pitch values. This shader is really complicated compared to most other CRT shaders, reading the README and the documentation in the user-settings.h is a must.<br />
<br />
CRT-Royale-Kurozumi is a preconfigured CRT-Royale made to look like a professional CRT monitor, specifically Sony's PVM/BVM line of monitors.<br />
<br />
===CRT-Guest-Advanced===<br />
*[https://forums.libretro.com/t/new-crt-shader-from-guest-crt-guest-advanced-updates/25444 Guest's shader development thread]<br />
<br />
This is quite possibly the most advanced, feature-rich CRT shader of all. It has just as many if not more parameters to configure than CRT-Royale while being more optimized, and if greater speed is desired, there are several faster versions available, as well as variants that add other neat features such as NTSC emulation and better support for games that render at 480p or higher. It is also still in active development and continues to regularly gain features and optimizations. Take heed, however: it is also one of the only shaders without a central public Github repo, as its developer has opted for release bundles linked to in the libretro forums instead. While RetroArch does host a version of it in their shader repos, it is highly outdated, so it is recommended to update it using the latest release from the developer's dedicated libretro forum thread, linked above.<br />
<br />
===CRT-Guest-Dr-Venom===<br />
[[File:crt-guest-dr-venom.png|thumb|298px|CRT-Guest-Dr-Venom, with default settings at 1080p (view original for full details)]]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/guest/crt-gdv-new crt-guest-dr-venom]<br />
<br />
The precursor to CRT-Guest-Advanced. While it is now considered outdated and not as feature-filled as Guest's newest shaders, it is much faster, more so than even the fastest Advanced preset, and it still has plenty of things to tweak to deliver a pleasing image. It therefore fills a middle-of-the-road niche among CRT shaders, delivering a nice balance of features and performance.<br />
<br />
===Sony Megatron===<br />
*[https://github.com/libretro/slang-shaders/tree/master/hdr Sony Megatron]<br />
*[https://forums.libretro.com/t/sony-megatron-colour-video-monitor/36109 Sony Megatron development and discussion thread]<br />
<br />
This shader is quite unique among CRT shaders, and shaders in general. It is currently the only shader that takes advantage of HDR support for greater color depth and brightness, allowing for highly accurate CRT emulation on HDR-capable displays, though it is also usable on regular SDR displays through a parameter change. Unlike other CRT shaders, its inner workings are actually fairly simple and it doesn't have many bells and whistles, focusing mainly on drawing scanlines and accurate phosphor masks as well as color correction, which coincidentally also makes it one of the fastest shaders featured on this page. As it is primarily meant for use on bright HDR-capable displays, it draws phosphor masks at full strength with no attempt at mitigating the resulting loss in brightness through parameters such as bloom, glow or mask strength typically seen in other CRT shaders, instead counting on the display to make up for it. On an SDR display, it is highly recommended to use it with the backlight turned up all the way, as otherwise the image will likely be too dim to view comfortably. There are presets emulating various CRT models and types, including several PVM models, certain arcade displays, and even PC monitors.<br />
<br />
==Future==<br />
<br />
===Phosphor Mask Emulation===<br />
At the frontier of CRT shader development has been phosphor mask emulation. As stated previously, there are three overarching mask types: aperture grilles, shadow masks and slot masks. Aperture grilles were used primarily by Sony TVs, professional displays and PC monitors (with a few other brands such as Mitsubishi releasing their own version after Sony's Trinitron patent expired in the late 90's), shadow masks by the majority of PC CRT monitors from the late 80's onwards, and slot masks by just about every non-Sony consumer-level CRT TV, the vast majority of arcade monitors, and very early home computer/PC monitors. A key part of CRT emulation, then, depends on accurately replicating the look of these masks.<br />
<br />
However, even within each of these mask types, there is a lot of variance, as some CRTs were much sharper and were able to resolve a lot more detail than others. This is encapsulated in a specification known as TVL, or television lines, defined as the number of vertical white lines a mask can resolve along the horizontal dimension in a stretch equal to the height of the tube's viewable area (this means TVL is calculated by measuring the screen's height, then counting the number of resolved lines across a horizontal span equal to that height, not across the entire length of the screen). A higher TVL count is the result of higher phosphor density and results in a sharper, more detailed image, as well as more prominent scanlines in low-res content. Most consumer-level CRTs had a relatively low TVL count, whereas professional monitors such as Sony's PVM and BVM series had much higher TVL. In PC monitors, the usual specification to determine sharpness was instead dot pitch, or the distance between two phosphors of the same color. The lower the dot pitch, the sharper the monitor and the more detail it could resolve.<br />
<br />
Taking into account the three mask types and the variance in TVL and dot pitch, then, along with many other variables, it is no wonder no two CRTs looked alike.<br />
<br />
==External Links==<br />
*[http://filthypants.blogspot.com/2015/04/more-crt-shaders.html More CRT Shaders (filthypants.blogspot.com)] - hunterk's comparison of current CRT shaders. <br />
<br />
[[Category:FAQs]]<br />
[[Category:Shaders/Filters]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=File:Crt-zfast.png&diff=48320File:Crt-zfast.png2022-07-12T03:19:31Z<p>GPDP1: </p>
<hr />
<div></div>GPDP1https://emulation.gametechwiki.com/index.php?title=File:Crt-lottes-multipass.png&diff=48319File:Crt-lottes-multipass.png2022-07-12T03:19:15Z<p>GPDP1: </p>
<hr />
<div></div>GPDP1https://emulation.gametechwiki.com/index.php?title=File:Crt-guest-dr-venom.png&diff=48318File:Crt-guest-dr-venom.png2022-07-12T03:18:58Z<p>GPDP1: </p>
<hr />
<div></div>GPDP1https://emulation.gametechwiki.com/index.php?title=File:GTU.png&diff=48317File:GTU.png2022-07-12T03:18:39Z<p>GPDP1: </p>
<hr />
<div></div>GPDP1https://emulation.gametechwiki.com/index.php?title=File:Crt-easymode.png&diff=48316File:Crt-easymode.png2022-07-12T03:18:09Z<p>GPDP1: </p>
<hr />
<div></div>GPDP1https://emulation.gametechwiki.com/index.php?title=File:Crt-caligari-sm.png&diff=48315File:Crt-caligari-sm.png2022-07-12T03:17:35Z<p>GPDP1: </p>
<hr />
<div></div>GPDP1https://emulation.gametechwiki.com/index.php?title=CRT_shaders&diff=48314CRT shaders2022-07-12T00:55:10Z<p>GPDP1: /* Sony Megatron */</p>
<hr />
<div>[[File:Retroarch_2013-07-22_17-21-17-60.png|thumb|298px|CRT-Geom-Flat, with default settings]]<br />
CRT shaders are one of the most popular categories of shaders. While there had been many attempts to include some kind of CRT-esque filters in older emulators - usually involving little more than overlaying dark gray or black lines, colloquially referred to as scanlines, over the image - modern CRT shaders are much more complex and configurable.<br />
<br />
Many of these replicate aperture grille CRTs (exemplified primarily by Sony TVs and monitors, though other manufacturers released their own versions of the technology later on), which have sharp images and strong scanlines. If you find that these shaders don't look a damn thing like your old TV, it's probably because you owned a slot mask-style CRT, which typically had less noticeable scanlines, or simply had a smaller set, which tended to be less sharp. The easiest way to tell the difference is to feel the curve of the screen; aperture grilles only curve horizontally if at all. Alternatively, look at the left and right sides of the glass against the frame - if the sides are curved, it's a slot mask; if they're straight, it's an aperture grille. Old TVs usually had slot masks, whereas monitors usually had shadow masks. While slot masks and shadow masks can be emulated to a certain degree even at 1080p, much higher resolutions like 4K or higher are better suited to the task. Aperture grilles are much easier to emulate, and can be satisfactorily replicated at 1080p, though it goes without saying even better results can be achieved with higher resolution.<br />
<br />
It is advisable to use integer scaling when using CRT shaders. This means either using windowed mode (x2,x3,x4) or setting an integer scaling option in the video options. The reason is that non-integer scaled scanlines will result in uneven lines with artifacts, though some shaders use oversampling to try to avoid this. If the resulting letterboxing annoys you and you still want to fill up as much of your screen's real estate as possible, you can also try integer scale overscaling, which scales the image up by another integer to fill the vertical image space while still preserving integer scaling, at the expense of some of the image on the top and bottom being cut off. As an example, at 1080p, turning on overscaling would scale a typical SNES game running at 256x224 to 5x scale i.e. 1280x1120, cutting off twenty pixels from both the top and bottom of the image to reach 1080p. Before you fret, know that at 1080p and 4K the loss from overscaling is usually negligible and well within the area that would've been expected to be cut off on a real CRT anyway due to overscan, and developers almost always took this into account and made sure not to put any crucial game information there, so on many if not most older games, overscaling is completely safe.<br />
<br />
==Download==<br />
All official releases of RetroArch come bundled with a full set of slang and GLSL shaders, including CRT shaders, pulled from their shader repositories on Github, which are regularly maintained and updated. The simplest way to keep up to date with shader development is through RetroArch's built-in updater, though if you are only interested in the CRT shaders, you can alternatively grab them from the following repos:<br />
<br />
[https://github.com/libretro/slang-shaders/tree/master/crt slang shaders] - For use with devices that support Vulkan, OpenGL 3.x, GLES3, and/or D3D10/11/12. This is the most current, regularly maintained repository.<br />
<br />
[https://github.com/libretro/glsl-shaders/tree/master/crt GLSL shaders] - For use with devices that only support up to OpenGL 2.x or GLES2. Largely deprecated, though still sporadically maintained.<br />
<br />
[https://github.com/libretro/common-shaders/tree/master/crt Cg shaders] - For use on platforms that only support Cg or HLSL runtimes, such as the PS3. Deprecated.<br />
<br />
==Types==<br />
===CRT-Geom===<br />
{{Main|CRT Geom}}<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-geom.slang crt-geom.slang]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-cgwg-fast.slang crt-cgwg-fast.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/geom-deluxe crt-geom-deluxe]<br />
<br />
A very versatile and modifiable shader that simulates an aperture grille display (with the mask enabled). One of the first popular CRT shaders. The deluxe version adds more features, including more mask types. Visit the main article for more details.<br />
<br />
===CRT-Caligari===<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-caligari.slang crt-caligari.slang]<br />
<br />
An older CRT shader similar to CRT-Geom that uses different methods to achieve its effects.<br />
<br />
===CRT-Easymode===<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-easymode.slang crt-easymode.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-easymode-halation crt-easymode-halation]<br />
<br />
A fast, relatively simple CRT shader with easy-to-understand settings. Similar to CRT-Geom in its effects.<br />
<br />
===CRT-Hyllian===<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/hyllian crt-hyllian]<br />
*[https://forums.libretro.com/t/crt-hyllian-and-its-variants/38137 Hyllian's shader development thread]<br />
<br />
Aims only for picture quality, so it avoids things that degrade the image just for accuracy. It, however, uses far less power to run than most other CRT shaders, so it is possible to run this on lower end systems. <br />
<br />
Recently, after a long period of inactivity, Hyllian has restarted shader development anew, releasing all-new versions of this shader under heavy inspiration from CRT-Guest-Advanced and others. They can be acquired at his thread on the libretro forums, linked above.<br />
<br />
===CRT-Lottes===<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-lottes.slang crt-lottes.slang]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-lottes-fast.slang crt-lottes-fast.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-lottes-multipass crt-lottes-multipass]<br />
<br />
A newer CRT shader that uses a horizontal shadow mask pattern with blooming. The horizontal pattern works quite well at 1080p, though it isn't entirely accurate to a true vertical slot mask pattern. The multipass version adds scanline bloom and a few other features.<br />
<br />
===GTU===<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/gtu-v050 GTUv050 slang]<br />
*[https://github.com/hizzlekizzle/quark-shaders/tree/master/GTU.shader GTUv040 Quark]<br />
*[https://github.com/libretro/slang-shaders/tree/master/nes_raw_palette/shaders/gtu-famicom GTU-Famicom slang]<br />
*[https://github.com/hunterk/interpolation-shaders/raw/master/GTUv050test.tar.gz GTUv50 Test program]<br />
<br />
A CRT shader that focuses more on simulating blur and blending effects and color levels of CRT screens rather than the physical attributes like phosphors and curvature. Highly configurable, can be really sharp, or really blurry or anywhere in between, with optional scanlines and contrast and gamma settings. Settings are stored in a separate "config.h" file for easy editing. GTU-Famicom is a variant that takes an image from an NES with "raw" colors and processes it to output an NTSC image much like an actual NES PPU.<br />
<br />
The test program is a program that can adjust various attributes, such as horizontal and vertical blur, scanlines, etc. It is useful for testing settings to use with the shader, and also to understand how CRT shaders work in general.<br />
<br />
===ZFast_CRT===<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/zfast_crt zfast_crt]<br />
<br />
An extremely fast CRT shader made to run at full speed on extremely low-end hardware like the Raspberri Pi 3. Probably the fastest shader on this list.<br />
<br />
===CRT-Royale===<br />
{{Main|CRT-Royale}}<br />
[[File:CRT-Royale.png|thumb|298px|CRT-Royale, with default settings at 1080p (view original for full details)]]<br />
<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-royale CRT-Royale]<br />
*[https://github.com/libretro/slang-shaders/blob/master/presets/crt-royale-kurozumi.slangp CRT-Royale-Kurozumi]<br />
<br />
A highly advanced multi-pass CRT shader that simulates almost every aspect of the CRT screen. There are tons of parameters to configure, such as phosphor type (aperture grille, slot mask, and EDP shadow mask) and size (i.e. dot pitch), convergence offsets, scanline blooming and many others. Higher resolution is better for this shader, especially with EDP shadow mask phosphor layout and with smaller phosphor dot pitch values. This shader is really complicated compared to most other CRT shaders, reading the README and the documentation in the user-settings.h is a must.<br />
<br />
CRT-Royale-Kurozumi is a preconfigured CRT-Royale made to look like a professional CRT monitor, specifically Sony's PVM/BVM line of monitors.<br />
<br />
===CRT-Guest-Advanced===<br />
*[https://forums.libretro.com/t/new-crt-shader-from-guest-crt-guest-advanced-updates/25444 Guest's shader development thread]<br />
<br />
This is quite possibly the most advanced, feature-rich CRT shader of all. It has just as many if not more parameters to configure than CRT-Royale while being more optimized, and if greater speed is desired, there are several faster versions available, as well as variants that add other neat features such as NTSC emulation and better support for games that render at 480p or higher. It is also still in active development and continues to regularly gain features and optimizations. Take heed, however: it is also one of the only shaders without a central public Github repo, as its developer has opted for release bundles linked to in the libretro forums instead. While RetroArch does host a version of it in their shader repos, it is highly outdated, so it is recommended to update it using the latest release from the developer's dedicated libretro forum thread, linked above.<br />
<br />
===CRT-Guest-Dr-Venom===<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/guest/crt-gdv-new crt-guest-dr-venom]<br />
<br />
The precursor to CRT-Guest-Advanced. While it is now considered outdated and not as feature-filled as Guest's newest shaders, it is much faster, more so than even the fastest Advanced preset, and it still has plenty of things to tweak to deliver a pleasing image. It therefore fills a middle-of-the-road niche among CRT shaders, delivering a nice balance of features and performance.<br />
<br />
===Sony Megatron===<br />
*[https://github.com/libretro/slang-shaders/tree/master/hdr Sony Megatron]<br />
*[https://forums.libretro.com/t/sony-megatron-colour-video-monitor/36109 Sony Megatron development and discussion thread]<br />
<br />
This shader is quite unique among CRT shaders, and shaders in general. It is currently the only shader that takes advantage of HDR support for greater color depth and brightness, allowing for highly accurate CRT emulation on HDR-capable displays, though it is also usable on regular SDR displays through a parameter change. Unlike other CRT shaders, its inner workings are actually fairly simple and it doesn't have many bells and whistles, focusing mainly on drawing scanlines and accurate phosphor masks as well as color correction, which coincidentally also makes it one of the fastest shaders featured on this page. As it is primarily meant for use on bright HDR-capable displays, it draws phosphor masks at full strength with no attempt at mitigating the resulting loss in brightness through parameters such as bloom, glow or mask strength typically seen in other CRT shaders, instead counting on the display to make up for it. On an SDR display, it is highly recommended to use it with the backlight turned up all the way, as otherwise the image will likely be too dim to view comfortably. There are presets emulating various CRT models and types, including several PVM models, certain arcade displays, and even PC monitors.<br />
<br />
==Future==<br />
<br />
===Phosphor Mask Emulation===<br />
At the frontier of CRT shader development has been phosphor mask emulation. As stated previously, there are three overarching mask types: aperture grilles, shadow masks and slot masks. Aperture grilles were used primarily by Sony TVs, professional displays and PC monitors (with a few other brands such as Mitsubishi releasing their own version after Sony's Trinitron patent expired in the late 90's), shadow masks by the majority of PC CRT monitors from the late 80's onwards, and slot masks by just about every non-Sony consumer-level CRT TV, the vast majority of arcade monitors, and very early home computer/PC monitors. A key part of CRT emulation, then, depends on accurately replicating the look of these masks.<br />
<br />
However, even within each of these mask types, there is a lot of variance, as some CRTs were much sharper and were able to resolve a lot more detail than others. This is encapsulated in a specification known as TVL, or television lines, defined as the number of vertical white lines a mask can resolve along the horizontal dimension in a stretch equal to the height of the tube's viewable area (this means TVL is calculated by measuring the screen's height, then counting the number of resolved lines across a horizontal span equal to that height, not across the entire length of the screen). A higher TVL count is the result of higher phosphor density and results in a sharper, more detailed image, as well as more prominent scanlines in low-res content. Most consumer-level CRTs had a relatively low TVL count, whereas professional monitors such as Sony's PVM and BVM series had much higher TVL. In PC monitors, the usual specification to determine sharpness was instead dot pitch, or the distance between two phosphors of the same color. The lower the dot pitch, the sharper the monitor and the more detail it could resolve.<br />
<br />
Taking into account the three mask types and the variance in TVL and dot pitch, then, along with many other variables, it is no wonder no two CRTs looked alike.<br />
<br />
==External Links==<br />
*[http://filthypants.blogspot.com/2015/04/more-crt-shaders.html More CRT Shaders (filthypants.blogspot.com)] - hunterk's comparison of current CRT shaders. <br />
<br />
[[Category:FAQs]]<br />
[[Category:Shaders/Filters]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=CRT_shaders&diff=48313CRT shaders2022-07-12T00:51:13Z<p>GPDP1: /* ZFast_CRT */</p>
<hr />
<div>[[File:Retroarch_2013-07-22_17-21-17-60.png|thumb|298px|CRT-Geom-Flat, with default settings]]<br />
CRT shaders are one of the most popular categories of shaders. While there had been many attempts to include some kind of CRT-esque filters in older emulators - usually involving little more than overlaying dark gray or black lines, colloquially referred to as scanlines, over the image - modern CRT shaders are much more complex and configurable.<br />
<br />
Many of these replicate aperture grille CRTs (exemplified primarily by Sony TVs and monitors, though other manufacturers released their own versions of the technology later on), which have sharp images and strong scanlines. If you find that these shaders don't look a damn thing like your old TV, it's probably because you owned a slot mask-style CRT, which typically had less noticeable scanlines, or simply had a smaller set, which tended to be less sharp. The easiest way to tell the difference is to feel the curve of the screen; aperture grilles only curve horizontally if at all. Alternatively, look at the left and right sides of the glass against the frame - if the sides are curved, it's a slot mask; if they're straight, it's an aperture grille. Old TVs usually had slot masks, whereas monitors usually had shadow masks. While slot masks and shadow masks can be emulated to a certain degree even at 1080p, much higher resolutions like 4K or higher are better suited to the task. Aperture grilles are much easier to emulate, and can be satisfactorily replicated at 1080p, though it goes without saying even better results can be achieved with higher resolution.<br />
<br />
It is advisable to use integer scaling when using CRT shaders. This means either using windowed mode (x2,x3,x4) or setting an integer scaling option in the video options. The reason is that non-integer scaled scanlines will result in uneven lines with artifacts, though some shaders use oversampling to try to avoid this. If the resulting letterboxing annoys you and you still want to fill up as much of your screen's real estate as possible, you can also try integer scale overscaling, which scales the image up by another integer to fill the vertical image space while still preserving integer scaling, at the expense of some of the image on the top and bottom being cut off. As an example, at 1080p, turning on overscaling would scale a typical SNES game running at 256x224 to 5x scale i.e. 1280x1120, cutting off twenty pixels from both the top and bottom of the image to reach 1080p. Before you fret, know that at 1080p and 4K the loss from overscaling is usually negligible and well within the area that would've been expected to be cut off on a real CRT anyway due to overscan, and developers almost always took this into account and made sure not to put any crucial game information there, so on many if not most older games, overscaling is completely safe.<br />
<br />
==Download==<br />
All official releases of RetroArch come bundled with a full set of slang and GLSL shaders, including CRT shaders, pulled from their shader repositories on Github, which are regularly maintained and updated. The simplest way to keep up to date with shader development is through RetroArch's built-in updater, though if you are only interested in the CRT shaders, you can alternatively grab them from the following repos:<br />
<br />
[https://github.com/libretro/slang-shaders/tree/master/crt slang shaders] - For use with devices that support Vulkan, OpenGL 3.x, GLES3, and/or D3D10/11/12. This is the most current, regularly maintained repository.<br />
<br />
[https://github.com/libretro/glsl-shaders/tree/master/crt GLSL shaders] - For use with devices that only support up to OpenGL 2.x or GLES2. Largely deprecated, though still sporadically maintained.<br />
<br />
[https://github.com/libretro/common-shaders/tree/master/crt Cg shaders] - For use on platforms that only support Cg or HLSL runtimes, such as the PS3. Deprecated.<br />
<br />
==Types==<br />
===CRT-Geom===<br />
{{Main|CRT Geom}}<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-geom.slang crt-geom.slang]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-cgwg-fast.slang crt-cgwg-fast.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/geom-deluxe crt-geom-deluxe]<br />
<br />
A very versatile and modifiable shader that simulates an aperture grille display (with the mask enabled). One of the first popular CRT shaders. The deluxe version adds more features, including more mask types. Visit the main article for more details.<br />
<br />
===CRT-Caligari===<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-caligari.slang crt-caligari.slang]<br />
<br />
An older CRT shader similar to CRT-Geom that uses different methods to achieve its effects.<br />
<br />
===CRT-Easymode===<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-easymode.slang crt-easymode.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-easymode-halation crt-easymode-halation]<br />
<br />
A fast, relatively simple CRT shader with easy-to-understand settings. Similar to CRT-Geom in its effects.<br />
<br />
===CRT-Hyllian===<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/hyllian crt-hyllian]<br />
*[https://forums.libretro.com/t/crt-hyllian-and-its-variants/38137 Hyllian's shader development thread]<br />
<br />
Aims only for picture quality, so it avoids things that degrade the image just for accuracy. It, however, uses far less power to run than most other CRT shaders, so it is possible to run this on lower end systems. <br />
<br />
Recently, after a long period of inactivity, Hyllian has restarted shader development anew, releasing all-new versions of this shader under heavy inspiration from CRT-Guest-Advanced and others. They can be acquired at his thread on the libretro forums, linked above.<br />
<br />
===CRT-Lottes===<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-lottes.slang crt-lottes.slang]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-lottes-fast.slang crt-lottes-fast.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-lottes-multipass crt-lottes-multipass]<br />
<br />
A newer CRT shader that uses a horizontal shadow mask pattern with blooming. The horizontal pattern works quite well at 1080p, though it isn't entirely accurate to a true vertical slot mask pattern. The multipass version adds scanline bloom and a few other features.<br />
<br />
===GTU===<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/gtu-v050 GTUv050 slang]<br />
*[https://github.com/hizzlekizzle/quark-shaders/tree/master/GTU.shader GTUv040 Quark]<br />
*[https://github.com/libretro/slang-shaders/tree/master/nes_raw_palette/shaders/gtu-famicom GTU-Famicom slang]<br />
*[https://github.com/hunterk/interpolation-shaders/raw/master/GTUv050test.tar.gz GTUv50 Test program]<br />
<br />
A CRT shader that focuses more on simulating blur and blending effects and color levels of CRT screens rather than the physical attributes like phosphors and curvature. Highly configurable, can be really sharp, or really blurry or anywhere in between, with optional scanlines and contrast and gamma settings. Settings are stored in a separate "config.h" file for easy editing. GTU-Famicom is a variant that takes an image from an NES with "raw" colors and processes it to output an NTSC image much like an actual NES PPU.<br />
<br />
The test program is a program that can adjust various attributes, such as horizontal and vertical blur, scanlines, etc. It is useful for testing settings to use with the shader, and also to understand how CRT shaders work in general.<br />
<br />
===ZFast_CRT===<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/zfast_crt zfast_crt]<br />
<br />
An extremely fast CRT shader made to run at full speed on extremely low-end hardware like the Raspberri Pi 3. Probably the fastest shader on this list.<br />
<br />
===CRT-Royale===<br />
{{Main|CRT-Royale}}<br />
[[File:CRT-Royale.png|thumb|298px|CRT-Royale, with default settings at 1080p (view original for full details)]]<br />
<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-royale CRT-Royale]<br />
*[https://github.com/libretro/slang-shaders/blob/master/presets/crt-royale-kurozumi.slangp CRT-Royale-Kurozumi]<br />
<br />
A highly advanced multi-pass CRT shader that simulates almost every aspect of the CRT screen. There are tons of parameters to configure, such as phosphor type (aperture grille, slot mask, and EDP shadow mask) and size (i.e. dot pitch), convergence offsets, scanline blooming and many others. Higher resolution is better for this shader, especially with EDP shadow mask phosphor layout and with smaller phosphor dot pitch values. This shader is really complicated compared to most other CRT shaders, reading the README and the documentation in the user-settings.h is a must.<br />
<br />
CRT-Royale-Kurozumi is a preconfigured CRT-Royale made to look like a professional CRT monitor, specifically Sony's PVM/BVM line of monitors.<br />
<br />
===CRT-Guest-Advanced===<br />
*[https://forums.libretro.com/t/new-crt-shader-from-guest-crt-guest-advanced-updates/25444 Guest's shader development thread]<br />
<br />
This is quite possibly the most advanced, feature-rich CRT shader of all. It has just as many if not more parameters to configure than CRT-Royale while being more optimized, and if greater speed is desired, there are several faster versions available, as well as variants that add other neat features such as NTSC emulation and better support for games that render at 480p or higher. It is also still in active development and continues to regularly gain features and optimizations. Take heed, however: it is also one of the only shaders without a central public Github repo, as its developer has opted for release bundles linked to in the libretro forums instead. While RetroArch does host a version of it in their shader repos, it is highly outdated, so it is recommended to update it using the latest release from the developer's dedicated libretro forum thread, linked above.<br />
<br />
===CRT-Guest-Dr-Venom===<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/guest/crt-gdv-new crt-guest-dr-venom]<br />
<br />
The precursor to CRT-Guest-Advanced. While it is now considered outdated and not as feature-filled as Guest's newest shaders, it is much faster, more so than even the fastest Advanced preset, and it still has plenty of things to tweak to deliver a pleasing image. It therefore fills a middle-of-the-road niche among CRT shaders, delivering a nice balance of features and performance.<br />
<br />
===Sony Megatron===<br />
*[https://github.com/libretro/slang-shaders/tree/master/hdr Sony Megatron]<br />
*[https://forums.libretro.com/t/sony-megatron-colour-video-monitor/36109/957 Sony Megatron development and discussion thread]<br />
<br />
This shader is quite unique among CRT shaders, and shaders in general. It is currently the only shader that takes advantage of HDR support for greater color depth and brightness, allowing for highly accurate CRT emulation on HDR-capable displays, though it is also usable on regular SDR displays through a parameter change. Unlike other CRT shaders, its inner workings are actually fairly simple and it doesn't have many bells and whistles, focusing mainly on drawing scanlines and accurate phosphor masks as well as color correction, which coincidentally also makes it one of the fastest shaders featured on this page. As it is primarily meant for use on bright HDR-capable displays, it draws phosphor masks at full strength with no attempt at mitigating the resulting loss in brightness through parameters such as bloom, glow or mask strength typically seen in other CRT shaders, instead counting on the display to make up for it. On an SDR display, it is highly recommended to use it with the backlight turned up all the way, as otherwise the image will likely be too dim to view comfortably. There are presets emulating various CRT models and types, including several PVM models, certain arcade displays, and even PC monitors.<br />
<br />
==Future==<br />
<br />
===Phosphor Mask Emulation===<br />
At the frontier of CRT shader development has been phosphor mask emulation. As stated previously, there are three overarching mask types: aperture grilles, shadow masks and slot masks. Aperture grilles were used primarily by Sony TVs, professional displays and PC monitors (with a few other brands such as Mitsubishi releasing their own version after Sony's Trinitron patent expired in the late 90's), shadow masks by the majority of PC CRT monitors from the late 80's onwards, and slot masks by just about every non-Sony consumer-level CRT TV, the vast majority of arcade monitors, and very early home computer/PC monitors. A key part of CRT emulation, then, depends on accurately replicating the look of these masks.<br />
<br />
However, even within each of these mask types, there is a lot of variance, as some CRTs were much sharper and were able to resolve a lot more detail than others. This is encapsulated in a specification known as TVL, or television lines, defined as the number of vertical white lines a mask can resolve along the horizontal dimension in a stretch equal to the height of the tube's viewable area (this means TVL is calculated by measuring the screen's height, then counting the number of resolved lines across a horizontal span equal to that height, not across the entire length of the screen). A higher TVL count is the result of higher phosphor density and results in a sharper, more detailed image, as well as more prominent scanlines in low-res content. Most consumer-level CRTs had a relatively low TVL count, whereas professional monitors such as Sony's PVM and BVM series had much higher TVL. In PC monitors, the usual specification to determine sharpness was instead dot pitch, or the distance between two phosphors of the same color. The lower the dot pitch, the sharper the monitor and the more detail it could resolve.<br />
<br />
Taking into account the three mask types and the variance in TVL and dot pitch, then, along with many other variables, it is no wonder no two CRTs looked alike.<br />
<br />
==External Links==<br />
*[http://filthypants.blogspot.com/2015/04/more-crt-shaders.html More CRT Shaders (filthypants.blogspot.com)] - hunterk's comparison of current CRT shaders. <br />
<br />
[[Category:FAQs]]<br />
[[Category:Shaders/Filters]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=CRT_shaders&diff=48312CRT shaders2022-07-12T00:50:47Z<p>GPDP1: Complete overhaul of Types section - updated various links to reflect the migration to slang shaders, added new information, and shifted some things around</p>
<hr />
<div>[[File:Retroarch_2013-07-22_17-21-17-60.png|thumb|298px|CRT-Geom-Flat, with default settings]]<br />
CRT shaders are one of the most popular categories of shaders. While there had been many attempts to include some kind of CRT-esque filters in older emulators - usually involving little more than overlaying dark gray or black lines, colloquially referred to as scanlines, over the image - modern CRT shaders are much more complex and configurable.<br />
<br />
Many of these replicate aperture grille CRTs (exemplified primarily by Sony TVs and monitors, though other manufacturers released their own versions of the technology later on), which have sharp images and strong scanlines. If you find that these shaders don't look a damn thing like your old TV, it's probably because you owned a slot mask-style CRT, which typically had less noticeable scanlines, or simply had a smaller set, which tended to be less sharp. The easiest way to tell the difference is to feel the curve of the screen; aperture grilles only curve horizontally if at all. Alternatively, look at the left and right sides of the glass against the frame - if the sides are curved, it's a slot mask; if they're straight, it's an aperture grille. Old TVs usually had slot masks, whereas monitors usually had shadow masks. While slot masks and shadow masks can be emulated to a certain degree even at 1080p, much higher resolutions like 4K or higher are better suited to the task. Aperture grilles are much easier to emulate, and can be satisfactorily replicated at 1080p, though it goes without saying even better results can be achieved with higher resolution.<br />
<br />
It is advisable to use integer scaling when using CRT shaders. This means either using windowed mode (x2,x3,x4) or setting an integer scaling option in the video options. The reason is that non-integer scaled scanlines will result in uneven lines with artifacts, though some shaders use oversampling to try to avoid this. If the resulting letterboxing annoys you and you still want to fill up as much of your screen's real estate as possible, you can also try integer scale overscaling, which scales the image up by another integer to fill the vertical image space while still preserving integer scaling, at the expense of some of the image on the top and bottom being cut off. As an example, at 1080p, turning on overscaling would scale a typical SNES game running at 256x224 to 5x scale i.e. 1280x1120, cutting off twenty pixels from both the top and bottom of the image to reach 1080p. Before you fret, know that at 1080p and 4K the loss from overscaling is usually negligible and well within the area that would've been expected to be cut off on a real CRT anyway due to overscan, and developers almost always took this into account and made sure not to put any crucial game information there, so on many if not most older games, overscaling is completely safe.<br />
<br />
==Download==<br />
All official releases of RetroArch come bundled with a full set of slang and GLSL shaders, including CRT shaders, pulled from their shader repositories on Github, which are regularly maintained and updated. The simplest way to keep up to date with shader development is through RetroArch's built-in updater, though if you are only interested in the CRT shaders, you can alternatively grab them from the following repos:<br />
<br />
[https://github.com/libretro/slang-shaders/tree/master/crt slang shaders] - For use with devices that support Vulkan, OpenGL 3.x, GLES3, and/or D3D10/11/12. This is the most current, regularly maintained repository.<br />
<br />
[https://github.com/libretro/glsl-shaders/tree/master/crt GLSL shaders] - For use with devices that only support up to OpenGL 2.x or GLES2. Largely deprecated, though still sporadically maintained.<br />
<br />
[https://github.com/libretro/common-shaders/tree/master/crt Cg shaders] - For use on platforms that only support Cg or HLSL runtimes, such as the PS3. Deprecated.<br />
<br />
==Types==<br />
===CRT-Geom===<br />
{{Main|CRT Geom}}<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-geom.slang crt-geom.slang]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-cgwg-fast.slang crt-cgwg-fast.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/geom-deluxe crt-geom-deluxe]<br />
<br />
A very versatile and modifiable shader that simulates an aperture grille display (with the mask enabled). One of the first popular CRT shaders. The deluxe version adds more features, including more mask types. Visit the main article for more details.<br />
<br />
===CRT-Caligari===<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-caligari.slang crt-caligari.slang]<br />
<br />
An older CRT shader similar to CRT-Geom that uses different methods to achieve its effects.<br />
<br />
===CRT-Easymode===<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-easymode.slang crt-easymode.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-easymode-halation crt-easymode-halation]<br />
<br />
A fast, relatively simple CRT shader with easy-to-understand settings. Similar to CRT-Geom in its effects.<br />
<br />
===CRT-Hyllian===<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/hyllian crt-hyllian]<br />
*[https://forums.libretro.com/t/crt-hyllian-and-its-variants/38137 Hyllian's shader development thread]<br />
<br />
Aims only for picture quality, so it avoids things that degrade the image just for accuracy. It, however, uses far less power to run than most other CRT shaders, so it is possible to run this on lower end systems. <br />
<br />
Recently, after a long period of inactivity, Hyllian has restarted shader development anew, releasing all-new versions of this shader under heavy inspiration from CRT-Guest-Advanced and others. They can be acquired at his thread on the libretro forums, linked above.<br />
<br />
===CRT-Lottes===<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-lottes.slang crt-lottes.slang]<br />
*[https://github.com/libretro/slang-shaders/blob/master/crt/shaders/crt-lottes-fast.slang crt-lottes-fast.slang]<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-lottes-multipass crt-lottes-multipass]<br />
<br />
A newer CRT shader that uses a horizontal shadow mask pattern with blooming. The horizontal pattern works quite well at 1080p, though it isn't entirely accurate to a true vertical slot mask pattern. The multipass version adds scanline bloom and a few other features.<br />
<br />
===GTU===<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/gtu-v050 GTUv050 slang]<br />
*[https://github.com/hizzlekizzle/quark-shaders/tree/master/GTU.shader GTUv040 Quark]<br />
*[https://github.com/libretro/slang-shaders/tree/master/nes_raw_palette/shaders/gtu-famicom GTU-Famicom slang]<br />
*[https://github.com/hunterk/interpolation-shaders/raw/master/GTUv050test.tar.gz GTUv50 Test program]<br />
<br />
A CRT shader that focuses more on simulating blur and blending effects and color levels of CRT screens rather than the physical attributes like phosphors and curvature. Highly configurable, can be really sharp, or really blurry or anywhere in between, with optional scanlines and contrast and gamma settings. Settings are stored in a separate "config.h" file for easy editing. GTU-Famicom is a variant that takes an image from an NES with "raw" colors and processes it to output an NTSC image much like an actual NES PPU.<br />
<br />
The test program is a program that can adjust various attributes, such as horizontal and vertical blur, scanlines, etc. It is useful for testing settings to use with the shader, and also to understand how CRT shaders work in general.<br />
<br />
===ZFast_CRT===<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/zfast_crt]<br />
<br />
An extremely fast CRT shader made to run at full speed on extremely low-end hardware like the Raspberri Pi 3. Probably the fastest shader on this list.<br />
<br />
===CRT-Royale===<br />
{{Main|CRT-Royale}}<br />
[[File:CRT-Royale.png|thumb|298px|CRT-Royale, with default settings at 1080p (view original for full details)]]<br />
<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/crt-royale CRT-Royale]<br />
*[https://github.com/libretro/slang-shaders/blob/master/presets/crt-royale-kurozumi.slangp CRT-Royale-Kurozumi]<br />
<br />
A highly advanced multi-pass CRT shader that simulates almost every aspect of the CRT screen. There are tons of parameters to configure, such as phosphor type (aperture grille, slot mask, and EDP shadow mask) and size (i.e. dot pitch), convergence offsets, scanline blooming and many others. Higher resolution is better for this shader, especially with EDP shadow mask phosphor layout and with smaller phosphor dot pitch values. This shader is really complicated compared to most other CRT shaders, reading the README and the documentation in the user-settings.h is a must.<br />
<br />
CRT-Royale-Kurozumi is a preconfigured CRT-Royale made to look like a professional CRT monitor, specifically Sony's PVM/BVM line of monitors.<br />
<br />
===CRT-Guest-Advanced===<br />
*[https://forums.libretro.com/t/new-crt-shader-from-guest-crt-guest-advanced-updates/25444 Guest's shader development thread]<br />
<br />
This is quite possibly the most advanced, feature-rich CRT shader of all. It has just as many if not more parameters to configure than CRT-Royale while being more optimized, and if greater speed is desired, there are several faster versions available, as well as variants that add other neat features such as NTSC emulation and better support for games that render at 480p or higher. It is also still in active development and continues to regularly gain features and optimizations. Take heed, however: it is also one of the only shaders without a central public Github repo, as its developer has opted for release bundles linked to in the libretro forums instead. While RetroArch does host a version of it in their shader repos, it is highly outdated, so it is recommended to update it using the latest release from the developer's dedicated libretro forum thread, linked above.<br />
<br />
===CRT-Guest-Dr-Venom===<br />
*[https://github.com/libretro/slang-shaders/tree/master/crt/shaders/guest/crt-gdv-new crt-guest-dr-venom]<br />
<br />
The precursor to CRT-Guest-Advanced. While it is now considered outdated and not as feature-filled as Guest's newest shaders, it is much faster, more so than even the fastest Advanced preset, and it still has plenty of things to tweak to deliver a pleasing image. It therefore fills a middle-of-the-road niche among CRT shaders, delivering a nice balance of features and performance.<br />
<br />
===Sony Megatron===<br />
*[https://github.com/libretro/slang-shaders/tree/master/hdr Sony Megatron]<br />
*[https://forums.libretro.com/t/sony-megatron-colour-video-monitor/36109/957 Sony Megatron development and discussion thread]<br />
<br />
This shader is quite unique among CRT shaders, and shaders in general. It is currently the only shader that takes advantage of HDR support for greater color depth and brightness, allowing for highly accurate CRT emulation on HDR-capable displays, though it is also usable on regular SDR displays through a parameter change. Unlike other CRT shaders, its inner workings are actually fairly simple and it doesn't have many bells and whistles, focusing mainly on drawing scanlines and accurate phosphor masks as well as color correction, which coincidentally also makes it one of the fastest shaders featured on this page. As it is primarily meant for use on bright HDR-capable displays, it draws phosphor masks at full strength with no attempt at mitigating the resulting loss in brightness through parameters such as bloom, glow or mask strength typically seen in other CRT shaders, instead counting on the display to make up for it. On an SDR display, it is highly recommended to use it with the backlight turned up all the way, as otherwise the image will likely be too dim to view comfortably. There are presets emulating various CRT models and types, including several PVM models, certain arcade displays, and even PC monitors.<br />
<br />
==Future==<br />
<br />
===Phosphor Mask Emulation===<br />
At the frontier of CRT shader development has been phosphor mask emulation. As stated previously, there are three overarching mask types: aperture grilles, shadow masks and slot masks. Aperture grilles were used primarily by Sony TVs, professional displays and PC monitors (with a few other brands such as Mitsubishi releasing their own version after Sony's Trinitron patent expired in the late 90's), shadow masks by the majority of PC CRT monitors from the late 80's onwards, and slot masks by just about every non-Sony consumer-level CRT TV, the vast majority of arcade monitors, and very early home computer/PC monitors. A key part of CRT emulation, then, depends on accurately replicating the look of these masks.<br />
<br />
However, even within each of these mask types, there is a lot of variance, as some CRTs were much sharper and were able to resolve a lot more detail than others. This is encapsulated in a specification known as TVL, or television lines, defined as the number of vertical white lines a mask can resolve along the horizontal dimension in a stretch equal to the height of the tube's viewable area (this means TVL is calculated by measuring the screen's height, then counting the number of resolved lines across a horizontal span equal to that height, not across the entire length of the screen). A higher TVL count is the result of higher phosphor density and results in a sharper, more detailed image, as well as more prominent scanlines in low-res content. Most consumer-level CRTs had a relatively low TVL count, whereas professional monitors such as Sony's PVM and BVM series had much higher TVL. In PC monitors, the usual specification to determine sharpness was instead dot pitch, or the distance between two phosphors of the same color. The lower the dot pitch, the sharper the monitor and the more detail it could resolve.<br />
<br />
Taking into account the three mask types and the variance in TVL and dot pitch, then, along with many other variables, it is no wonder no two CRTs looked alike.<br />
<br />
==External Links==<br />
*[http://filthypants.blogspot.com/2015/04/more-crt-shaders.html More CRT Shaders (filthypants.blogspot.com)] - hunterk's comparison of current CRT shaders. <br />
<br />
[[Category:FAQs]]<br />
[[Category:Shaders/Filters]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=CRT_shaders&diff=48310CRT shaders2022-07-11T18:59:09Z<p>GPDP1: Begin work on section explaining phosphor mask emulation, part 1</p>
<hr />
<div>[[File:Retroarch_2013-07-22_17-21-17-60.png|thumb|298px|CRT-Geom-Flat, with default settings]]<br />
CRT shaders are one of the most popular categories of shaders. While there had been many attempts to include some kind of CRT-esque filters in older emulators - usually involving little more than overlaying dark gray or black lines, colloquially referred to as scanlines, over the image - modern CRT shaders are much more complex and configurable.<br />
<br />
Many of these replicate aperture grille CRTs (exemplified primarily by Sony TVs and monitors, though other manufacturers released their own versions of the technology later on), which have sharp images and strong scanlines. If you find that these shaders don't look a damn thing like your old TV, it's probably because you owned a slot mask-style CRT, which typically had less noticeable scanlines, or simply had a smaller set, which tended to be less sharp. The easiest way to tell the difference is to feel the curve of the screen; aperture grilles only curve horizontally if at all. Alternatively, look at the left and right sides of the glass against the frame - if the sides are curved, it's a slot mask; if they're straight, it's an aperture grille. Old TVs usually had slot masks, whereas monitors usually had shadow masks. While slot masks and shadow masks can be emulated to a certain degree even at 1080p, much higher resolutions like 4K or higher are better suited to the task. Aperture grilles are much easier to emulate, and can be satisfactorily replicated at 1080p, though it goes without saying even better results can be achieved with higher resolution.<br />
<br />
It is advisable to use integer scaling when using CRT shaders. This means either using windowed mode (x2,x3,x4) or setting an integer scaling option in the video options. The reason is that non-integer scaled scanlines will result in uneven lines with artifacts, though some shaders use oversampling to try to avoid this. If the resulting letterboxing annoys you and you still want to fill up as much of your screen's real estate as possible, you can also try integer scale overscaling, which scales the image up by another integer to fill the vertical image space while still preserving integer scaling, at the expense of some of the image on the top and bottom being cut off. As an example, at 1080p, turning on overscaling would scale a typical SNES game running at 256x224 to 5x scale i.e. 1280x1120, cutting off twenty pixels from both the top and bottom of the image to reach 1080p. Before you fret, know that at 1080p and 4K the loss from overscaling is usually negligible and well within the area that would've been expected to be cut off on a real CRT anyway due to overscan, and developers almost always took this into account and made sure not to put any crucial game information there, so on many if not most older games, overscaling is completely safe.<br />
<br />
==Download==<br />
All official releases of RetroArch come bundled with a full set of slang and GLSL shaders, including CRT shaders, pulled from their shader repositories on Github, which are regularly maintained and updated. The simplest way to keep up to date with shader development is through RetroArch's built-in updater, though if you are only interested in the CRT shaders, you can alternatively grab them from the following repos:<br />
<br />
[https://github.com/libretro/slang-shaders/tree/master/crt slang shaders] - For use with devices that support Vulkan, OpenGL 3.x, GLES3, and/or D3D10/11/12. This is the most current, regularly maintained repository.<br />
<br />
[https://github.com/libretro/glsl-shaders/tree/master/crt GLSL shaders] - For use with devices that only support up to OpenGL 2.x or GLES2. Largely deprecated, though still sporadically maintained.<br />
<br />
[https://github.com/libretro/common-shaders/tree/master/crt Cg shaders] - For use on platforms that only support Cg or HLSL runtimes, such as the PS3. Deprecated.<br />
<br />
==Types==<br />
===CRT-Geom===<br />
{{Main|CRT Geom}}<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-geom.cg crt-geom.cg]<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-cgwg-fast.cg crt-cgwg-fast-cg]<br />
<br />
Simulates an aperture grille display (with the dot mask enabled). Very versatile and modifiable. One of the first popular CRT shaders. Visit the main article for more details.<br />
<br />
===CRT-Calagari===<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-caligari.cg crt-calagari.cg]<br />
<br />
An older CRT shader similar to CRT-Geom but uses different methods to achieve its effects.<br />
<br />
===CRT-Easymode===<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-easymode.cg crt-easymode.cg]<br />
*[https://github.com/libretro/common-shaders/tree/master/crt/shaders/crt-easymode-halation crt-easymode-halation]<br />
<br />
A flat CRT shader whose settings are easier to understand. Similar to CRT-Geom in its effects.<br />
<br />
===CRT-Hyllian===<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-hyllian.cg crt-hyllian.cg]<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-hyllian-fast.cg crt-hyllian-fast.cg]<br />
<br />
Aims only for picture quality, so it avoids things that degrade the image just for accuracy. It, however, uses far less power to run, so it is possible to run this shader on lower end systems than CRT-Geom. <br />
<br />
Another version, crt-hyllian-lq.cg is specifically aimed at even lower end systems.<br />
<br />
===CRT-Lottes===<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-lottes.cg crt-lottes.cg]<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-lottes-halation.cg crt-lottes-halation.cg]<br />
<br />
A newer CRT shader that uses a horizontal shadow mask pattern with blooming. The horizontal pattern works quite well at current resolutions, though it isn't entirely accurate to a true vertical slot mask pattern.<br />
<br />
===GTU===<br />
*[https://github.com/libretro/common-shaders/tree/master/crt/shaders/gtu-v050 GTUv050 Cg]<br />
*[https://github.com/hizzlekizzle/quark-shaders/tree/master/GTU.shader GTUv040 Quark]<br />
*[https://github.com/libretro/common-shaders/tree/master/crt/shaders/GTU-famicom GTU-Famicom Cg]<br />
*[https://github.com/hunterk/interpolation-shaders/raw/master/GTUv050test.tar.gz GTUv50 Test program]<br />
<br />
A CRT shader that focuses more on simulating blur and blending effects and color levels of CRT screens rather than the physical attributes like phosphors and curvature. Highly configurable, can be really sharp, or really blurry or anywhere in between, with optional scanlines and contrast and gamma settings. Settings are stored in a separate "config.h" file for easy editing. GTU-Famicom is a variant that takes an image from an NES with "raw" colors and processes it to output an NTSC image much like an actual NES PPU.<br />
<br />
The test program is a program that can adjust various attributes, such as horizontal and vertical blur, scanlines, etc. It is useful for testing settings to use with the shader, and also to understand how CRT shaders work in general.<br />
<br />
===CRT-Royale===<br />
{{Main|CRT-Royale}}<br />
[[File:CRT-Royale.png|thumb|298px|CRT-Royale, with default settings at 1080p (view original for full details)]]<br />
<br />
*[https://github.com/libretro/common-shaders/tree/master/crt/shaders/crt-royale CRT-Royale]<br />
<br />
A highly advanced multi-pass CRT shader that simulates almost every aspect of the CRT screen. There are tons of parameters to configure, such as phosphor type (aperture grille, slot mask, and EDP shadow mask) and size (i.e. dot pitch), convergence offests, scanline blooming and many others. Higher resolution is better for this shader, especially with EDP shadow mask phosphor layout and with smaller phosphor dot pitch values. This shader is really complicated compared to most other CRT shaders, reading the README and the documentation in the user-settings.h is a must.<br />
<br />
===CRT-Royale-Kurozumi===<br />
<br />
*[https://github.com/libretro/common-shaders/blob/master/cgp/crt-royale-kurozumi.cgp CRT-Royale-Kurozumi]<br />
<br />
A preconfigured CRT-Royale made to look like a professional CRT monitor, specifically Sony's PVM/BVM line of monitors.<br />
<br />
===CRT-Guest-Advanced===<br />
*[https://forums.libretro.com/t/new-crt-shader-from-guest-crt-guest-advanced-updates/25444 Guest's shader development thread]<br />
<br />
This is quite possibly the most advanced, feature-rich CRT shader of all. It has just as if not more parameters to configure than CRT-Royale while being more optimized, and if greater speed is desired, there are several faster versions available, as well as variants that add other neat features such as NTSC emulation and better support for games that render at 480p or higher. It is also still in active development and continues to regularly gain features and optimizations. Take heed, however: it is also one of the only shaders without a central public Github repo, as its developer has opted for release bundles linked to in the libretro forums instead. While RetroArch does host a version of it in their shader repos, it is highly outdated, so it is recommended to update it using the latest release from the developer's dedicated libretro forum thread, linked above.<br />
<br />
===Sony Megatron===<br />
*[https://github.com/libretro/slang-shaders/tree/master/hdr Sony Megatron]<br />
<br />
This shader is quite unique among CRT shaders, and shaders in general. It is currently the only shader that takes advantage of HDR support for greater color depth and brightness, allowing for highly accurate CRT emulation on HDR-capable displays, though it is also usable on regular SDR displays. Unlike other CRT shaders, its inner workings are actually fairly simple and it doesn't have many bells and whistles, focusing mainly on drawing scanlines and accurate phosphor masks as well as color correction, which coincidentally also makes it one of the fastest shaders featured on this page. As it is primarily meant for use on bright HDR-capable displays, it draws phosphor masks at full strength with no attempt at mitigating the resulting loss in brightness through parameters such as bloom, glow or mask strength typically seen in other CRT shaders, instead counting on the display to make up for it. On an SDR display, it is highly recommended to use it with the backlight turned up all the way, as otherwise the image will likely be too dim to view comfortably. There are presets emulating various CRT models and types, including several PVM models, certain arcade displays, and even PC monitors.<br />
<br />
==Future==<br />
<br />
===Phosphor Mask Emulation===<br />
At the frontier of CRT shader development has been phosphor mask emulation. As stated previously, there are three overarching mask types: aperture grilles, shadow masks and slot masks. Aperture grilles were used primarily by Sony TVs, professional displays and PC monitors (with a few other brands such as Mitsubishi releasing their own version after Sony's Trinitron patent expired in the late 90's), shadow masks by the majority of PC CRT monitors from the late 80's onwards, and slot masks by just about every non-Sony consumer-level CRT TV, the vast majority of arcade monitors, and very early home computer/PC monitors. A key part of CRT emulation, then, depends on accurately replicating the look of these masks.<br />
<br />
However, even within each of these mask types, there is a lot of variance, as some CRTs were much sharper and were able to resolve a lot more detail than others. This is encapsulated in a specification known as TVL, or television lines, defined as the number of vertical white lines a mask can resolve along the horizontal dimension in a stretch equal to the height of the tube's viewable area (this means TVL is calculated by measuring the screen's height, then counting the number of resolved lines across a horizontal span equal to that height, not across the entire length of the screen). A higher TVL count is the result of higher phosphor density and results in a sharper, more detailed image, as well as more prominent scanlines in low-res content. Most consumer-level CRTs had a relatively low TVL count, whereas professional monitors such as Sony's PVM and BVM series had much higher TVL. In PC monitors, the usual specification to determine sharpness was instead dot pitch, or the distance between two phosphors of the same color. The lower the dot pitch, the sharper the monitor and the more detail it could resolve.<br />
<br />
Taking into account the three mask types and the variance in TVL and dot pitch, then, along with many other variables, it is no wonder no two CRTs looked alike.<br />
<br />
==External Links==<br />
*[http://filthypants.blogspot.com/2015/04/more-crt-shaders.html More CRT Shaders (filthypants.blogspot.com)] - hunterk's comparison of current CRT shaders. <br />
<br />
[[Category:FAQs]]<br />
[[Category:Shaders/Filters]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=CRT_shaders&diff=48211CRT shaders2022-07-11T08:54:06Z<p>GPDP1: Added sections on CRT-Guest-Advanced and Sony Megatron</p>
<hr />
<div>[[File:Retroarch_2013-07-22_17-21-17-60.png|thumb|298px|CRT-Geom-Flat, with default settings]]<br />
CRT shaders are one of the most popular categories of shaders. While there had been many attempts to include some kind of CRT-esque filters in older emulators - usually involving little more than overlaying dark gray or black lines, colloquially referred to as scanlines, over the image - modern CRT shaders are much more complex and configurable.<br />
<br />
Many of these replicate aperture grille CRTs (exemplified primarily by Sony TVs and monitors, though other manufacturers released their own versions of the technology later on), which have sharp images and strong scanlines. If you find that these shaders don't look a damn thing like your old TV, it's probably because you owned a slot mask-style CRT, which typically had less noticeable scanlines, or simply had a smaller set, which tended to be less sharp. The easiest way to tell the difference is to feel the curve of the screen; aperture grilles only curve horizontally if at all. Alternatively, look at the left and right sides of the glass against the frame - if the sides are curved, it's a slot mask; if they're straight, it's an aperture grille. Old TVs usually had slot masks, whereas monitors usually had shadow masks. While slot masks and shadow masks can be emulated to a certain degree even at 1080p, much higher resolutions like 4K or higher are better suited to the task. Aperture grilles are much easier to emulate, and can be satisfactorily replicated at 1080p, though it goes without saying even better results can be achieved with higher resolution.<br />
<br />
It is advisable to use integer scaling when using CRT shaders. This means either using windowed mode (x2,x3,x4) or setting an integer scaling option in the video options. The reason is that non-integer scaled scanlines will result in uneven lines with artifacts, though some shaders use oversampling to try to avoid this. If the resulting letterboxing annoys you and you still want to fill up as much of your screen's real estate as possible, you can also try integer scale overscaling, which scales the image up by another integer to fill the vertical image space while still preserving integer scaling, at the expense of some of the image on the top and bottom being cut off. As an example, at 1080p, turning on overscaling would scale a typical SNES game running at 256x224 to 5x scale i.e. 1280x1120, cutting off twenty pixels from both the top and bottom of the image to reach 1080p. Before you fret, know that at 1080p and 4K the loss from overscaling is usually negligible and well within the area that would've been expected to be cut off on a real CRT anyway due to overscan, and developers almost always took this into account and made sure not to put any crucial game information there, so on many if not most older games, overscaling is completely safe.<br />
<br />
==Download==<br />
All official releases of RetroArch come bundled with a full set of slang and GLSL shaders, including CRT shaders, pulled from their shader repositories on Github, which are regularly maintained and updated. The simplest way to keep up to date with shader development is through RetroArch's built-in updater, though if you are only interested in the CRT shaders, you can alternatively grab them from the following repos:<br />
<br />
[https://github.com/libretro/slang-shaders/tree/master/crt slang shaders] - For use with devices that support Vulkan, OpenGL 3.x, GLES3, and/or D3D10/11/12. This is the most current, regularly maintained repository.<br />
<br />
[https://github.com/libretro/glsl-shaders/tree/master/crt GLSL shaders] - For use with devices that only support up to OpenGL 2.x or GLES2. Largely deprecated, though still sporadically maintained.<br />
<br />
[https://github.com/libretro/common-shaders/tree/master/crt Cg shaders] - For use on platforms that only support Cg or HLSL runtimes, such as the PS3. Deprecated.<br />
<br />
==Types==<br />
===CRT-Geom===<br />
{{Main|CRT Geom}}<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-geom.cg crt-geom.cg]<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-cgwg-fast.cg crt-cgwg-fast-cg]<br />
<br />
Simulates an aperture grille display (with the dot mask enabled). Very versatile and modifiable. One of the first popular CRT shaders. Visit the main article for more details.<br />
<br />
===CRT-Calagari===<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-caligari.cg crt-calagari.cg]<br />
<br />
An older CRT shader similar to CRT-Geom but uses different methods to achieve its effects.<br />
<br />
===CRT-Easymode===<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-easymode.cg crt-easymode.cg]<br />
*[https://github.com/libretro/common-shaders/tree/master/crt/shaders/crt-easymode-halation crt-easymode-halation]<br />
<br />
A flat CRT shader whose settings are easier to understand. Similar to CRT-Geom in its effects.<br />
<br />
===CRT-Hyllian===<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-hyllian.cg crt-hyllian.cg]<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-hyllian-fast.cg crt-hyllian-fast.cg]<br />
<br />
Aims only for picture quality, so it avoids things that degrade the image just for accuracy. It, however, uses far less power to run, so it is possible to run this shader on lower end systems than CRT-Geom. <br />
<br />
Another version, crt-hyllian-lq.cg is specifically aimed at even lower end systems.<br />
<br />
===CRT-Lottes===<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-lottes.cg crt-lottes.cg]<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-lottes-halation.cg crt-lottes-halation.cg]<br />
<br />
A newer CRT shader that uses a horizontal shadow mask pattern with blooming. The horizontal pattern works quite well at current resolutions, though it isn't entirely accurate to a true vertical slot mask pattern.<br />
<br />
===GTU===<br />
*[https://github.com/libretro/common-shaders/tree/master/crt/shaders/gtu-v050 GTUv050 Cg]<br />
*[https://github.com/hizzlekizzle/quark-shaders/tree/master/GTU.shader GTUv040 Quark]<br />
*[https://github.com/libretro/common-shaders/tree/master/crt/shaders/GTU-famicom GTU-Famicom Cg]<br />
*[https://github.com/hunterk/interpolation-shaders/raw/master/GTUv050test.tar.gz GTUv50 Test program]<br />
<br />
A CRT shader that focuses more on simulating blur and blending effects and color levels of CRT screens rather than the physical attributes like phosphors and curvature. Highly configurable, can be really sharp, or really blurry or anywhere in between, with optional scanlines and contrast and gamma settings. Settings are stored in a separate "config.h" file for easy editing. GTU-Famicom is a variant that takes an image from an NES with "raw" colors and processes it to output an NTSC image much like an actual NES PPU.<br />
<br />
The test program is a program that can adjust various attributes, such as horizontal and vertical blur, scanlines, etc. It is useful for testing settings to use with the shader, and also to understand how CRT shaders work in general.<br />
<br />
===CRT-Royale===<br />
{{Main|CRT-Royale}}<br />
[[File:CRT-Royale.png|thumb|298px|CRT-Royale, with default settings at 1080p (view original for full details)]]<br />
<br />
*[https://github.com/libretro/common-shaders/tree/master/crt/shaders/crt-royale CRT-Royale]<br />
<br />
A highly advanced multi-pass CRT shader that simulates almost every aspect of the CRT screen. There are tons of parameters to configure, such as phosphor type (aperture grille, slot mask, and EDP shadow mask) and size (i.e. dot pitch), convergence offests, scanline blooming and many others. Higher resolution is better for this shader, especially with EDP shadow mask phosphor layout and with smaller phosphor dot pitch values. This shader is really complicated compared to most other CRT shaders, reading the README and the documentation in the user-settings.h is a must.<br />
<br />
===CRT-Royale-Kurozumi===<br />
<br />
*[https://github.com/libretro/common-shaders/blob/master/cgp/crt-royale-kurozumi.cgp CRT-Royale-Kurozumi]<br />
<br />
A preconfigured CRT-Royale made to look like a professional CRT monitor, specifically Sony's PVM/BVM line of monitors.<br />
<br />
===CRT-Guest-Advanced===<br />
*[https://forums.libretro.com/t/new-crt-shader-from-guest-crt-guest-advanced-updates/25444 Guest's shader development thread]<br />
<br />
This is quite possibly the most advanced, feature-rich CRT shader of all. It has just as if not more parameters to configure than CRT-Royale while being more optimized, and if greater speed is desired, there are several faster versions available, as well as variants that add other neat features such as NTSC emulation and better support for games that render at 480p or higher. It is also still in active development and continues to regularly gain features and optimizations. Take heed, however: it is also one of the only shaders without a central public Github repo, as its developer has opted for release bundles linked to in the libretro forums instead. While RetroArch does host a version of it in their shader repos, it is highly outdated, so it is recommended to update it using the latest release from the developer's dedicated libretro forum thread, linked above.<br />
<br />
===Sony Megatron===<br />
*[https://github.com/libretro/slang-shaders/tree/master/hdr Sony Megatron]<br />
<br />
This shader is quite unique among CRT shaders, and shaders in general. It is currently the only shader that takes advantage of HDR support for greater color depth and brightness, allowing for highly accurate CRT emulation on HDR-capable displays, though it is also usable on regular SDR displays. Unlike other CRT shaders, its inner workings are actually fairly simple and it doesn't have many bells and whistles, focusing mainly on drawing scanlines and accurate phosphor masks as well as color correction, which coincidentally also makes it one of the fastest shaders featured on this page. As it is primarily meant for use on bright HDR-capable displays, it draws phosphor masks at full strength with no attempt at mitigating the resulting loss in brightness through parameters such as bloom, glow or mask strength typically seen in other CRT shaders, instead counting on the display to make up for it. On an SDR display, it is highly recommended to use it with the backlight turned up all the way, as otherwise the image will likely be too dim to view comfortably. There are presets emulating various CRT models and types, including several PVM models, certain arcade displays, and even PC monitors.<br />
<br />
==Future==<br />
<br />
===Shadow Mask Phosphor Emulation===<br />
Hypothetical shadow mask phosphor shaders such as PhosphorLUT and CRT-Royale are being developed. Due to the nature of the shadow mask screen, 4K resolution is likely needed to avoid significant downsampling of the phosphors.<br />
<br />
==External Links==<br />
*[http://filthypants.blogspot.com/2015/04/more-crt-shaders.html More CRT Shaders (filthypants.blogspot.com)] - hunterk's comparison of current CRT shaders. <br />
<br />
[[Category:FAQs]]<br />
[[Category:Shaders/Filters]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=CRT_shaders&diff=48206CRT shaders2022-07-11T07:48:39Z<p>GPDP1: Added note regarding RetroArch's shader repos</p>
<hr />
<div>[[File:Retroarch_2013-07-22_17-21-17-60.png|thumb|298px|CRT-Geom-Flat, with default settings]]<br />
CRT shaders are one of the most popular categories of shaders. While there had been many attempts to include some kind of CRT-esque filters in older emulators - usually involving little more than overlaying dark gray or black lines, colloquially referred to as scanlines, over the image - modern CRT shaders are much more complex and configurable.<br />
<br />
Many of these replicate aperture grille CRTs (exemplified primarily by Sony TVs and monitors, though other manufacturers released their own versions of the technology later on), which have sharp images and strong scanlines. If you find that these shaders don't look a damn thing like your old TV, it's probably because you owned a slot mask-style CRT, which typically had less noticeable scanlines, or simply had a smaller set, which tended to be less sharp. The easiest way to tell the difference is to feel the curve of the screen; aperture grilles only curve horizontally if at all. Alternatively, look at the left and right sides of the glass against the frame - if the sides are curved, it's a slot mask; if they're straight, it's an aperture grille. Old TVs usually had slot masks, whereas monitors usually had shadow masks. While slot masks and shadow masks can be emulated to a certain degree even at 1080p, much higher resolutions like 4K or higher are better suited to the task. Aperture grilles are much easier to emulate, and can be satisfactorily replicated at 1080p, though it goes without saying even better results can be achieved with higher resolution.<br />
<br />
It is advisable to use integer scaling when using CRT shaders. This means either using windowed mode (x2,x3,x4) or setting an integer scaling option in the video options. The reason is that non-integer scaled scanlines will result in uneven lines with artifacts, though some shaders use oversampling to try to avoid this. If the resulting letterboxing annoys you and you still want to fill up as much of your screen's real estate as possible, you can also try integer scale overscaling, which scales the image up by another integer to fill the vertical image space while still preserving integer scaling, at the expense of some of the image on the top and bottom being cut off. As an example, at 1080p, turning on overscaling would scale a typical SNES game running at 256x224 to 5x scale i.e. 1280x1120, cutting off twenty pixels from both the top and bottom of the image to reach 1080p. Before you fret, know that at 1080p and 4K the loss from overscaling is usually negligible and well within the area that would've been expected to be cut off on a real CRT anyway due to overscan, and developers almost always took this into account and made sure not to put any crucial game information there, so on many if not most older games, overscaling is completely safe.<br />
<br />
==Download==<br />
All official releases of RetroArch come bundled with a full set of slang and GLSL shaders, including CRT shaders, pulled from their shader repositories on Github, which are regularly maintained and updated. The simplest way to keep up to date with shader development is through RetroArch's built-in updater, though if you are only interested in the CRT shaders, you can alternatively grab them from the following repos:<br />
<br />
[https://github.com/libretro/slang-shaders/tree/master/crt slang shaders] - For use with devices that support Vulkan, OpenGL 3.x, GLES3, and/or D3D10/11/12. This is the most current, regularly maintained repository.<br />
<br />
[https://github.com/libretro/glsl-shaders/tree/master/crt GLSL shaders] - For use with devices that only support up to OpenGL 2.x or GLES2. Largely deprecated, though still sporadically maintained.<br />
<br />
[https://github.com/libretro/common-shaders/tree/master/crt Cg shaders] - For use on platforms that only support Cg or HLSL runtimes, such as the PS3. Deprecated.<br />
<br />
==Types==<br />
===CRT-Geom===<br />
{{Main|CRT Geom}}<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-geom.cg crt-geom.cg]<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-cgwg-fast.cg crt-cgwg-fast-cg]<br />
<br />
Simulates an aperture grille display (with the dot mask enabled). Very versatile and modifiable. One of the first popular CRT shaders. Visit the main article for more details.<br />
<br />
===CRT-Calagari===<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-caligari.cg crt-calagari.cg]<br />
<br />
An older CRT shader similar to CRT-Geom but uses different methods to achieve its effects.<br />
<br />
===CRT-Easymode===<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-easymode.cg crt-easymode.cg]<br />
*[https://github.com/libretro/common-shaders/tree/master/crt/shaders/crt-easymode-halation crt-easymode-halation]<br />
<br />
A flat CRT shader whose settings are easier to understand. Similar to CRT-Geom in its effects.<br />
<br />
===CRT-Hyllian===<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-hyllian.cg crt-hyllian.cg]<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-hyllian-fast.cg crt-hyllian-fast.cg]<br />
<br />
Aims only for picture quality, so it avoids things that degrade the image just for accuracy. It, however, uses far less power to run, so it is possible to run this shader on lower end systems than CRT-Geom. <br />
<br />
Another version, crt-hyllian-lq.cg is specifically aimed at even lower end systems.<br />
<br />
===CRT-Lottes===<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-lottes.cg crt-lottes.cg]<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-lottes-halation.cg crt-lottes-halation.cg]<br />
<br />
A newer CRT shader that uses a horizontal shadow mask pattern with blooming. The horizontal pattern works quite well at current resolutions, though it isn't entirely accurate to a true vertical slot mask pattern.<br />
<br />
===GTU===<br />
*[https://github.com/libretro/common-shaders/tree/master/crt/shaders/gtu-v050 GTUv050 Cg]<br />
*[https://github.com/hizzlekizzle/quark-shaders/tree/master/GTU.shader GTUv040 Quark]<br />
*[https://github.com/libretro/common-shaders/tree/master/crt/shaders/GTU-famicom GTU-Famicom Cg]<br />
*[https://github.com/hunterk/interpolation-shaders/raw/master/GTUv050test.tar.gz GTUv50 Test program]<br />
<br />
A CRT shader that focuses more on simulating blur and blending effects and color levels of CRT screens rather than the physical attributes like phosphors and curvature. Highly configurable, can be really sharp, or really blurry or anywhere in between, with optional scanlines and contrast and gamma settings. Settings are stored in a separate "config.h" file for easy editing. GTU-Famicom is a variant that takes an image from an NES with "raw" colors and processes it to output an NTSC image much like an actual NES PPU.<br />
<br />
The test program is a program that can adjust various attributes, such as horizontal and vertical blur, scanlines, etc. It is useful for testing settings to use with the shader, and also to understand how CRT shaders work in general.<br />
<br />
===CRT-Royale===<br />
{{Main|CRT-Royale}}<br />
[[File:CRT-Royale.png|thumb|298px|CRT-Royale, with default settings at 1080p (view original for full details)]]<br />
<br />
*[https://github.com/libretro/common-shaders/tree/master/crt/shaders/crt-royale CRT-Royale]<br />
<br />
A highly advanced multi-pass CRT shader that simulates almost every aspect of the CRT screen. There are tons of parameters to configure, such as phosphor type (aperture grille, slot mask, and EDP shadow mask) and size (i.e. dot pitch), convergence offests, scanline blooming and many others. Higher resolution is better for this shader, especially with EDP shadow mask phosphor layout and with smaller phosphor dot pitch values. This shader is really complicated compared to most other CRT shaders, reading the README and the documentation in the user-settings.h is a must.<br />
<br />
===CRT-Royale-Kurozumi===<br />
<br />
*[https://github.com/libretro/common-shaders/blob/master/cgp/crt-royale-kurozumi.cgp CRT-Royale-Kurozumi]<br />
<br />
A preconfigured CRT-Royale made to look like a professional CRT monitor, specifically Sony's PVM/BVM line of monitors.<br />
<br />
==Future==<br />
<br />
===Shadow Mask Phosphor Emulation===<br />
Hypothetical shadow mask phosphor shaders such as PhosphorLUT and CRT-Royale are being developed. Due to the nature of the shadow mask screen, 4K resolution is likely needed to avoid significant downsampling of the phosphors.<br />
<br />
==External Links==<br />
*[http://filthypants.blogspot.com/2015/04/more-crt-shaders.html More CRT Shaders (filthypants.blogspot.com)] - hunterk's comparison of current CRT shaders. <br />
<br />
[[Category:FAQs]]<br />
[[Category:Shaders/Filters]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=CRT_shaders&diff=48185CRT shaders2022-07-10T08:02:42Z<p>GPDP1: oops</p>
<hr />
<div>[[File:Retroarch_2013-07-22_17-21-17-60.png|thumb|298px|CRT-Geom-Flat, with default settings]]<br />
CRT shaders are one of the most popular categories of shaders. While there had been many attempts to include some kind of CRT-esque filters in older emulators - usually involving little more than overlaying dark gray or black lines, colloquially referred to as scanlines, over the image - modern CRT shaders are much more complex and configurable.<br />
<br />
Many of these replicate aperture grille CRTs (exemplified primarily by Sony TVs and monitors, though other manufacturers released their own versions of the technology later on), which have sharp images and strong scanlines. If you find that these shaders don't look a damn thing like your old TV, it's probably because you owned a slot mask-style CRT, which typically had less noticeable scanlines, or simply had a smaller set, which tended to be less sharp. The easiest way to tell the difference is to feel the curve of the screen; aperture grilles only curve horizontally if at all. Alternatively, look at the left and right sides of the glass against the frame - if the sides are curved, it's a slot mask; if they're straight, it's an aperture grille. Old TVs usually had slot masks, whereas monitors usually had shadow masks. While slot masks and shadow masks can be emulated to a certain degree even at 1080p, much higher resolutions like 4K or higher are better suited to the task. Aperture grilles are much easier to emulate, and can be satisfactorily replicated at 1080p, though it goes without saying even better results can be achieved with higher resolution.<br />
<br />
It is advisable to use integer scaling when using CRT shaders. This means either using windowed mode (x2,x3,x4) or setting an integer scaling option in the video options. The reason is that non-integer scaled scanlines will result in uneven lines with artifacts, though some shaders use oversampling to try to avoid this. If the resulting letterboxing annoys you and you still want to fill up as much of your screen's real estate as possible, you can also try integer scale overscaling, which scales the image up by another integer to fill the vertical image space while still preserving integer scaling, at the expense of some of the image on the top and bottom being cut off. As an example, at 1080p, turning on overscaling would scale a typical SNES game running at 256x224 to 5x scale i.e. 1280x1120, cutting off twenty pixels from both the top and bottom of the image to reach 1080p. Before you fret, know that at 1080p and 4K the loss from overscaling is usually negligible and well within the area that would've been expected to be cut off on a real CRT anyway due to overscan, and developers almost always took this into account and made sure not to put any crucial game information there, so on many if not most older games, overscaling is completely safe.<br />
<br />
==Download==<br />
[https://github.com/libretro/slang-shaders/tree/master/crt slang shaders] - For use with devices that support Vulkan, OpenGL 3.x, GLES3, and/or D3D10/11/12. This is the most current, regularly maintained repository.<br />
<br />
[https://github.com/libretro/glsl-shaders/tree/master/crt GLSL shaders] - For use with devices that only support up to OpenGL 2.x or GLES2. Largely deprecated, though still sporadically maintained.<br />
<br />
[https://github.com/libretro/common-shaders/tree/master/crt Cg shaders] - For use on platforms that only support Cg or HLSL runtimes, such as the PS3. Deprecated.<br />
<br />
==Types==<br />
===CRT-Geom===<br />
{{Main|CRT Geom}}<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-geom.cg crt-geom.cg]<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-cgwg-fast.cg crt-cgwg-fast-cg]<br />
<br />
Simulates an aperture grille display (with the dot mask enabled). Very versatile and modifiable. One of the first popular CRT shaders. Visit the main article for more details.<br />
<br />
===CRT-Calagari===<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-caligari.cg crt-calagari.cg]<br />
<br />
An older CRT shader similar to CRT-Geom but uses different methods to achieve its effects.<br />
<br />
===CRT-Easymode===<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-easymode.cg crt-easymode.cg]<br />
*[https://github.com/libretro/common-shaders/tree/master/crt/shaders/crt-easymode-halation crt-easymode-halation]<br />
<br />
A flat CRT shader whose settings are easier to understand. Similar to CRT-Geom in its effects.<br />
<br />
===CRT-Hyllian===<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-hyllian.cg crt-hyllian.cg]<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-hyllian-fast.cg crt-hyllian-fast.cg]<br />
<br />
Aims only for picture quality, so it avoids things that degrade the image just for accuracy. It, however, uses far less power to run, so it is possible to run this shader on lower end systems than CRT-Geom. <br />
<br />
Another version, crt-hyllian-lq.cg is specifically aimed at even lower end systems.<br />
<br />
===CRT-Lottes===<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-lottes.cg crt-lottes.cg]<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-lottes-halation.cg crt-lottes-halation.cg]<br />
<br />
A newer CRT shader that uses a horizontal shadow mask pattern with blooming. The horizontal pattern works quite well at current resolutions, though it isn't entirely accurate to a true vertical slot mask pattern.<br />
<br />
===GTU===<br />
*[https://github.com/libretro/common-shaders/tree/master/crt/shaders/gtu-v050 GTUv050 Cg]<br />
*[https://github.com/hizzlekizzle/quark-shaders/tree/master/GTU.shader GTUv040 Quark]<br />
*[https://github.com/libretro/common-shaders/tree/master/crt/shaders/GTU-famicom GTU-Famicom Cg]<br />
*[https://github.com/hunterk/interpolation-shaders/raw/master/GTUv050test.tar.gz GTUv50 Test program]<br />
<br />
A CRT shader that focuses more on simulating blur and blending effects and color levels of CRT screens rather than the physical attributes like phosphors and curvature. Highly configurable, can be really sharp, or really blurry or anywhere in between, with optional scanlines and contrast and gamma settings. Settings are stored in a separate "config.h" file for easy editing. GTU-Famicom is a variant that takes an image from an NES with "raw" colors and processes it to output an NTSC image much like an actual NES PPU.<br />
<br />
The test program is a program that can adjust various attributes, such as horizontal and vertical blur, scanlines, etc. It is useful for testing settings to use with the shader, and also to understand how CRT shaders work in general.<br />
<br />
===CRT-Royale===<br />
{{Main|CRT-Royale}}<br />
[[File:CRT-Royale.png|thumb|298px|CRT-Royale, with default settings at 1080p (view original for full details)]]<br />
<br />
*[https://github.com/libretro/common-shaders/tree/master/crt/shaders/crt-royale CRT-Royale]<br />
<br />
A highly advanced multi-pass CRT shader that simulates almost every aspect of the CRT screen. There are tons of parameters to configure, such as phosphor type (aperture grille, slot mask, and EDP shadow mask) and size (i.e. dot pitch), convergence offests, scanline blooming and many others. Higher resolution is better for this shader, especially with EDP shadow mask phosphor layout and with smaller phosphor dot pitch values. This shader is really complicated compared to most other CRT shaders, reading the README and the documentation in the user-settings.h is a must.<br />
<br />
===CRT-Royale-Kurozumi===<br />
<br />
*[https://github.com/libretro/common-shaders/blob/master/cgp/crt-royale-kurozumi.cgp CRT-Royale-Kurozumi]<br />
<br />
A preconfigured CRT-Royale made to look like a professional CRT monitor, specifically Sony's PVM/BVM line of monitors.<br />
<br />
==Future==<br />
<br />
===Shadow Mask Phosphor Emulation===<br />
Hypothetical shadow mask phosphor shaders such as PhosphorLUT and CRT-Royale are being developed. Due to the nature of the shadow mask screen, 4K resolution is likely needed to avoid significant downsampling of the phosphors.<br />
<br />
==External Links==<br />
*[http://filthypants.blogspot.com/2015/04/more-crt-shaders.html More CRT Shaders (filthypants.blogspot.com)] - hunterk's comparison of current CRT shaders. <br />
<br />
[[Category:FAQs]]<br />
[[Category:Shaders/Filters]]</div>GPDP1https://emulation.gametechwiki.com/index.php?title=CRT_shaders&diff=48184CRT shaders2022-07-10T08:02:08Z<p>GPDP1: Added links to the main shaders repos, as well as some info on the shader types</p>
<hr />
<div>[[File:Retroarch_2013-07-22_17-21-17-60.png|thumb|298px|CRT-Geom-Flat, with default settings]]<br />
CRT shaders are one of the most popular categories of shaders. While there had been many attempts to include some kind of CRT-esque filters in older emulators - usually involving little more than overlaying dark gray or black lines, colloquially referred to as scanlines, over the image - modern CRT shaders are much more complex and configurable.<br />
<br />
Many of these replicate aperture grille CRTs (exemplified primarily by Sony TVs and monitors, though other manufacturers released their own versions of the technology later on), which have sharp images and strong scanlines. If you find that these shaders don't look a damn thing like your old TV, it's probably because you owned a slot mask-style CRT, which typically had less noticeable scanlines, or simply had a smaller set, which tended to be less sharp. The easiest way to tell the difference is to feel the curve of the screen; aperture grilles only curve horizontally if at all. Alternatively, look at the left and right sides of the glass against the frame - if the sides are curved, it's a slot mask; if they're straight, it's an aperture grille. Old TVs usually had slot masks, whereas monitors usually had shadow masks. While slot masks and shadow masks can be emulated to a certain degree even at 1080p, much higher resolutions like 4K or higher are better suited to the task. Aperture grilles are much easier to emulate, and can be satisfactorily replicated at 1080p, though it goes without saying even better results can be achieved with higher resolution.<br />
<br />
It is advisable to use integer scaling when using CRT shaders. This means either using windowed mode (x2,x3,x4) or setting an integer scaling option in the video options. The reason is that non-integer scaled scanlines will result in uneven lines with artifacts, though some shaders use oversampling to try to avoid this. If the resulting letterboxing annoys you and you still want to fill up as much of your screen's real estate as possible, you can also try integer scale overscaling, which scales the image up by another integer to fill the vertical image space while still preserving integer scaling, at the expense of some of the image on the top and bottom being cut off. As an example, at 1080p, turning on overscaling would scale a typical SNES game running at 256x224 to 5x scale i.e. 1280x1120, cutting off twenty pixels from both the top and bottom of the image to reach 1080p. Before you fret, know that at 1080p and 4K the loss from overscaling is usually negligible and well within the area that would've been expected to be cut off on a real CRT anyway due to overscan, and developers almost always took this into account and made sure not to put any crucial game information there, so on many if not most older games, overscaling is completely safe.<br />
<br />
==Download==<br />
[https://github.com/libretro/slang-shaders/tree/master/crt slang shaders] - For use with devices that support Vulkan, OpenGL 3.x, GLES3, and/or D3D10/11/12. This is the most current, regularly maintained repository.<br />
[https://github.com/libretro/glsl-shaders/tree/master/crt GLSL shaders] - For use with devices that only support up to OpenGL 2.x or GLES2. Largely deprecated, though still sporadically maintained.<br />
[https://github.com/libretro/common-shaders/tree/master/crt Cg shaders] - For use on platforms that only support Cg or HLSL runtimes, such as the PS3. Deprecated.<br />
<br />
==Types==<br />
===CRT-Geom===<br />
{{Main|CRT Geom}}<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-geom.cg crt-geom.cg]<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-cgwg-fast.cg crt-cgwg-fast-cg]<br />
<br />
Simulates an aperture grille display (with the dot mask enabled). Very versatile and modifiable. One of the first popular CRT shaders. Visit the main article for more details.<br />
<br />
===CRT-Calagari===<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-caligari.cg crt-calagari.cg]<br />
<br />
An older CRT shader similar to CRT-Geom but uses different methods to achieve its effects.<br />
<br />
===CRT-Easymode===<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-easymode.cg crt-easymode.cg]<br />
*[https://github.com/libretro/common-shaders/tree/master/crt/shaders/crt-easymode-halation crt-easymode-halation]<br />
<br />
A flat CRT shader whose settings are easier to understand. Similar to CRT-Geom in its effects.<br />
<br />
===CRT-Hyllian===<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-hyllian.cg crt-hyllian.cg]<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-hyllian-fast.cg crt-hyllian-fast.cg]<br />
<br />
Aims only for picture quality, so it avoids things that degrade the image just for accuracy. It, however, uses far less power to run, so it is possible to run this shader on lower end systems than CRT-Geom. <br />
<br />
Another version, crt-hyllian-lq.cg is specifically aimed at even lower end systems.<br />
<br />
===CRT-Lottes===<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-lottes.cg crt-lottes.cg]<br />
*[https://github.com/libretro/common-shaders/blob/master/crt/shaders/crt-lottes-halation.cg crt-lottes-halation.cg]<br />
<br />
A newer CRT shader that uses a horizontal shadow mask pattern with blooming. The horizontal pattern works quite well at current resolutions, though it isn't entirely accurate to a true vertical slot mask pattern.<br />
<br />
===GTU===<br />
*[https://github.com/libretro/common-shaders/tree/master/crt/shaders/gtu-v050 GTUv050 Cg]<br />
*[https://github.com/hizzlekizzle/quark-shaders/tree/master/GTU.shader GTUv040 Quark]<br />
*[https://github.com/libretro/common-shaders/tree/master/crt/shaders/GTU-famicom GTU-Famicom Cg]<br />
*[https://github.com/hunterk/interpolation-shaders/raw/master/GTUv050test.tar.gz GTUv50 Test program]<br />
<br />
A CRT shader that focuses more on simulating blur and blending effects and color levels of CRT screens rather than the physical attributes like phosphors and curvature. Highly configurable, can be really sharp, or really blurry or anywhere in between, with optional scanlines and contrast and gamma settings. Settings are stored in a separate "config.h" file for easy editing. GTU-Famicom is a variant that takes an image from an NES with "raw" colors and processes it to output an NTSC image much like an actual NES PPU.<br />
<br />
The test program is a program that can adjust various attributes, such as horizontal and vertical blur, scanlines, etc. It is useful for testing settings to use with the shader, and also to understand how CRT shaders work in general.<br />
<br />
===CRT-Royale===<br />
{{Main|CRT-Royale}}<br />
[[File:CRT-Royale.png|thumb|298px|CRT-Royale, with default settings at 1080p (view original for full details)]]<br />
<br />
*[https://github.com/libretro/common-shaders/tree/master/crt/shaders/crt-royale CRT-Royale]<br />
<br />
A highly advanced multi-pass CRT shader that simulates almost every aspect of the CRT screen. There are tons of parameters to configure, such as phosphor type (aperture grille, slot mask, and EDP shadow mask) and size (i.e. dot pitch), convergence offests, scanline blooming and many others. Higher resolution is better for this shader, especially with EDP shadow mask phosphor layout and with smaller phosphor dot pitch values. This shader is really complicated compared to most other CRT shaders, reading the README and the documentation in the user-settings.h is a must.<br />
<br />
===CRT-Royale-Kurozumi===<br />
<br />
*[https://github.com/libretro/common-shaders/blob/master/cgp/crt-royale-kurozumi.cgp CRT-Royale-Kurozumi]<br />
<br />
A preconfigured CRT-Royale made to look like a professional CRT monitor, specifically Sony's PVM/BVM line of monitors.<br />
<br />
==Future==<br />
<br />
===Shadow Mask Phosphor Emulation===<br />
Hypothetical shadow mask phosphor shaders such as PhosphorLUT and CRT-Royale are being developed. Due to the nature of the shadow mask screen, 4K resolution is likely needed to avoid significant downsampling of the phosphors.<br />
<br />
==External Links==<br />
*[http://filthypants.blogspot.com/2015/04/more-crt-shaders.html More CRT Shaders (filthypants.blogspot.com)] - hunterk's comparison of current CRT shaders. <br />
<br />
[[Category:FAQs]]<br />
[[Category:Shaders/Filters]]</div>GPDP1