Changes

The '''Nintendo 64''' is a 64-bit fifth-generation console released by Nintendo on September 29, 1996 and had a for {{inflation|USD|199.99|1996}}. 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 with , 4MB of RAM and with ,<ref group=N>Though a separate add-on was later released called the "Expansion Pack 8MB Pak" that added an additional 4MB of RAM, totaling 8MB. It has a </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.

! scope="col"|Operating SystemPlatform(s)

!colspan="11"|PC/ x86

|Multi-platformalign=left|{{Icon|Windows|Linux|macOS|FreeBSD}}

|{{✓✗}}

|align=left|{{Icon|Windows}}|[https://github.com/project64/project64/releases {{Project64Ver}}]<br >[https://www.pj64-emu.com/nightly-builds Dev]|{{✓}}|{{✓}}

|align=left|{{Icon|Windows, |Linux, |macOS}}

|{{✗~}}

|align=left|{{Icon|Windows}}

|[https://web.archive.org/web/20160828165435/http://forums.daedalusx64.com/ Daedalus]DaedalusX64|Windowsalign=left|{{Icon|Linux}}|[httphttps://wwwgithub.dcemu.co.ukcom/DaedalusX64/vbulletindaedalus/threadsreleases/599734-Daedalusx64-for-Windows-OSX-Linux-Updated-v1-1?p=2148637718 1.1latest Git]|{{✗✓}}

|align=left|{{Icon|macOS}}|[http://sixtyforce.com/download/ 1.0.34]

|align=left|{{Icon|Windows}}

|Multi-platformalign=left|{{Icon|Windows|Linux|macOS|FreeBSD}}

|align=left|{{Icon|Windows, |Linux, |macOS}}

|{{✓✗}}

|align=left|{{Icon|Windows, |Linux, |macOS}}

|Larper64|align=left|{{Icon|Windows}}|[https://thirdworld.dev/files/Larper64-02.7z 0.2]|{{✓}}|{{✗}}|{{✗}}|{{✗}}|{{✗}}|{{✗}}|{{✗}}|-!colspan="11"|Mobile/ ARM

|[[Android emulatorsalign=left|{{Icon|Android]]}}|[https://play.google.com/store/apps/details?id=org.mupen64plusae.v3.fzurita 3.0.208 222 (beta)]

|align=left|{{Icon|Pandora}}

|[[Android emulatorsalign=left|{{Icon|Android]]}}

|[[Wii emulatorsalign=left|{{Icon|Wii]], [[Wii U emulators|Wii U]]WiiU}}

|[[Wii emulatorsalign=left|{{Icon|GCN|Wii]], [[GameCube_emulators|GameCube]]}}|[https://github.com/Extrems/Not64/releases/latest 2017100920190410]

|[[Wii emulatorsalign=left|{{Icon|GCN|Wii]], [[GameCube_emulators|GameCube]]}}

|[https://github.com/DaedalusX64/daedalus/releases/ Daedalus]|[[PlayStation Portable emulatorsalign=left|{{Icon|PlayStation Portable]]PSP}}|[https://github.com/DaedalusX64/daedalus/releases 1.1.7/latest Git]|{{✗✓}}

|{{✗✓}}

Although many Nintendo 64 emulators have been made and many games can be run between them, complete compatibility and/or accuracy still leaves a bit to be desired. For half a decade, Mupen64Plus and Project64 have vied for the most playable emulator, and which has been more compatible has depended on when and in what configuration each emulator has been tested. Both emulators default to lackluster plugins, but, as of August 2017, both emulators have roughly equal graphical accuracy when running with GLideN64. Mupen64Plus arguably has the edge in audio accuracy over Project64 + Azimer's audio plugin.

* [[Mupen64Plus]] is an open-source, multi-platform, plugin-based emulator based on Hacktarux's Mupen64. As of [https://github.com/mupen64plus/mupen64plus-core/pull/336 July 2017], the codebase has reached compatibility parity with Project64, when both emulators are run with GLideN64. Mupen64Plus lacks a native GUI, instead of being run either from the command line or by dragging and dropping ROMs onto the executable and editing the config with a text editor such as Notepad++. There are several third-party GUIs made for it, of which M64Py may be the most solid. The end-user experience has improved in 2017 with [https://m64p.github.io/ m64p], which combines new versions of Mupen64Plus with GLideN64 and a new Qt5 GUI. This is as compatible as N64 emulation gets as of August 2017, and the package can be played out-of-the-box without having to mess around with plugins. Mupen64Plus has also been ported to a number of different platforms. [[BizHawk]] and [[OpenEmu]] use shallow forks of Mupen64Plus and its plugins for their N64 emulation.

* [[Project64]] is a mostly an open-source emulator for Windows. Its official release builds are more up-to-date than Mupen64Plus', and the current version, 2.3.2, is roughly as accurate as the development versions of Mupen64Plus when both are played with recommended plugins. It has a more user-friendly interface than the Mupen64Plus attempts and supports more features such as overclocking and Transfer Pak emulation. However, it doesn't come with GLideN64 out-of-the-box, and the default video and audio plugins aren't even the best in the box. It presently remains confined to Windows, though work is underway to port it to Android and Linux. For the most part, it works well in [[Wine]], but, if you're on a different platform, use Mupen64Plus instead.

* [[RetroArch]]'s Nintendo 64 libretro core is based on Mupen64Plus and its plugins but with heavy modifications. It introduces many features and optimizations not present in mainline alongside RetroArch's general features, including Project64-style overclocking for faster framerates, 3-point texture filtering, superior A/V sync and latency, and even an exclusive LLE Vulkan renderer based on Angrylion's pixel-perfect plugin, making it a better alternative to the standalone version in most some cases. Its developers have expressed intentions to eventually rewrite the core and brand it as its own emulator, called paraLLEl. That new paraLLEl core 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].

* Daedalus is an Nintendo 64 emulator for the PSP, which has been ported to Windows, but results are even more hit-and-miss than on other emulators due to being made for PSP first and foremost. On PSP, most games are unplayableplayable, but there's a [http://daedalusx64.wikia.com/wiki/DaedalusX64_Compatibility_List small amount of them that work really well] with the right settings (Quest 64, for example)some minor sound issues. 

Emulation for The Nintendo 64 emulation scene can be described as a hot mess. It got to that point because of the overall emulation scene's climate in the N64 is not at early days, which was to stub off certain components of the point where many would expect emulated hardware as plugins. (Other consoles weren't immune to this phenomenon; it also happened to be by now[[PlayStation emulators|the first PlayStation]]. The ) Developers underestimated the complexity of the system is extremely complex compared , and with little demand for improvements beyond getting the popular titles working from beginning to end, most emulator developers stuck with the codebases they knew for as long as possible and never integrated any of the plugins that were needed to its contemporary consolesmake up a full project, or merge their codebases into one project. With And because almost no documentation being is available for clean-room reverse engineers, figuring out how the hardware actually functioned had to emulator developersbe done manually, it which took longer. The unfortunate result of this is difficult to create an emulator with a high degree of compatibility with games. Many that many games require specific plugin setups with arrangements and specific emulators in order to be played decentlyrun well, and there is no viable alternative that isn't just an iteration on the existing plugin-based emulators.

===[[High/Low level emulation|High-level vs. low-level ]] graphics===One of the biggest hurdles in the road to proper N64 emulation has been accurately emulating the N64's graphics hardware, known as the Reality Display Processor, itself a part of the N64's Reality Co-Processor. The N64's RDP was the first real 3D accelerator GPU on consoles. In fact, it was the most powerful consumer-grade GPU in the world at the time it came out. It is very hard to emulate all of its functions accurately due to the RDP's complexity & flexibility. In addition, many RDP functions have to be reproduced in software for accuracy, which takes a lot of processing power.

For this reason, most developers have instead opted One of the biggest hurdles to approximate emulating the Nintendo 64 is the Reality Display Processor (RDP's functions using high-level emulation (HLE) through various APIs such as Direct3D, OpenGL, and even Glide. While this results one of two components in much more reasonable system requirements for emulation, along with prettier, higher resolution graphics, this method can be hit and missthe Reality Coprocessor made by SGI. It often requiring perThe Reality Display Processor was the most powerful consumer-game tweaks and settings grade GPU at the time of the console's release; this was a selling point that Nintendo wanted to prevent graphical glitches on many gamesemphasize as a result of working with SGI. Some However, reverse engineering efforts for popular Nintendo 64 games implemented custom graphics microcode which had yet to be reverse-engineered. Although many or even all of them have already been implemented in HLE mode in 2016-2018 with dedicated work from GLideN64showed that Nintendo's lead programmer, gonetz, and one or two assistantssoftware development kit included a common microcode for the RDP.<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> For example, [https://youtu.be/HfCOnmRHI0o Factor 5]It's games do now work, specifically when using GLideN64 pluginpossible Nintendo didn's high-level graphics mode.<ref name="Indiegogo">{{cite web|url=https://www.indiegogo.com/projects/indiana-j-infernal-machine-high-t want to give developers access at a lower 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-out of-microcodes-for.html|title=HLE implementation fears that doing so would damage consumer units, but that meant most of microcodes for "Indiana Jones" and "Battle for Naboo" completed.|publisher=Blogspot|accessdate=2018-06-17|date=2018-05-26}}</ref> Other games may have issues with such the effort spent emulating the RDP quirks as frame buffer/depth buffer access (issues with would go towards figuring out how to handle the frame buffer is used as well as performance issues), VI emulation as well as issues with how combiner/blender modes are emulated (such as noise issues and combiner accuracy)microcode.

Low-level * Most developers in 1999 and the early 2000s opted to approximate functions through various APIs such as Direct3D, OpenGL, and even Glide. While this resulted in much more reasonable system requirements for emulation can , along with prettier, higher resolution graphics, this method proved to be handled in two wayshit and miss, complete lowoften requiring per-level software emulation game tweaks and settings to prevent graphical glitches on many games. Some games flat out didn't work, because it wasn't clear what the microcode did or a hybrid approach of LLE RDP emulationwhy, which involves using graphics APIs to simulate and required extensive hardware testing.* On the RDP while using low-level RSP emulation to side, developers would either completely emulate the graphics RDP or autodetect the microcodeand use an appropriate implementation for the game. Low level The former would mean a software emulation of renderer accurate to the RDP involves replicating all RDP functionality in software, which allows for very high accuracy hardware but can suffer from major performance issues bottlenecks unless optimizations such as like vectorization and multi-threading are performedwere implemented. Hybrid LLE emulation can allow for The latter would mean faster performance enhancement over low level software RDP emulation but can suffer from various problems due developers would still have to things such as replicating the N64's numerous blending/combine modes, emulating frame buffer access and replicating figure out how polygons are rasterized to the screen (due to how the RDP renders primitives on a low level)account for edge cases.

gonetz and one or two assistants have spent a large portion of development improving GlideN64's handling of microcode throughout 2016-2018.<ref name="gliden64_blog-1">{{cite web|url=https://gliden64.blogspot.com/2017/|title=Public Release 3.0|publisher=Blogspot|accessdate=2018-06-17|date=2017-12-29}}</ref><ref name="ZSortBOSS">{{cite web|url=https://github.com/gonetz/GLideN64/issues/1685#issuecomment-364436534|title=Initial implementation of BOSS ZSort ucode (WDC, Stunt Racer)|publisher=GitHub|accessdate=2018-06-17|date=2018-02-10}}</ref> This means that [https://youtu.be/HfCOnmRHI0o Factor 5]'s games are now working in the high-level graphics mode.<ref name="Indiegogo">{{cite web|url=https://www.indiegogo.com/projects/indiana-j-infernal-machine-high-level-emulation#/updates/all|title="Indiana J. & Infernal Machine" HLE|publisher=Indiegogo|accessdate=2018-06-17|date=2018-05-17}}</ref><ref name="gliden64_blog-2">{{cite web|url=https://gliden64.blogspot.com/2018/05/hle-implementation-of-microcodes-for.html|title=HLE implementation of microcodes for "Indiana Jones" and "Battle for Naboo" completed.|publisher=Blogspot|accessdate=2018-06-17|date=2018-05-26}}</ref> Other games may still have issues with RDP quirks like frame buffer/depth buffer access (issues with how the frame buffer is used as well as performance issues), VI emulation, and how combine/blending modes are emulated (such as noise issues and combiner accuracy). It should also be noted that even though most games "technically work" through the HLE method, but it is 's not an accurate representation of what the N64 hardware's video output actually looked like , but rather a rough approximation by PC your graphics hardwarecard. Your mileage may vary on whether Whether this is a good thing an improvement or not, given the N64's often blurry low-res outputis subjective.<gallery widths="300" mode="packed">Majora's mask accurate.png|Low level emulation of Majora's Mask with low-level graphics (using SoftGraphic)Project64 2013-07-26 14-20-17-55.png|High level emulation of Majora's Mask with high-level graphics (using Jabo's Direct3D)

The N64 Nintendo 64 was the first console consumer device to be able to feature texture filtering of any kindfilter textures when rendering 3D objects. However, unlike every console and PC graphics hardware and every console card made after the N64, its implementation of bilinear texture filtering was unique, primitive in that, in order to reduce strain on the system, it only used three samples as opposed to four, resulting in slightly jagged textures. Instead of faithfully applying this "imperfect" version of bilinearfiltering, HLE plugins instead apply conventional bilinear filtering, interpolating straight from the source texture up to the output resolution, much like on the same way a PC gamesgame would. While technically this that method of bilinear filtering is technically superior to the N64's, it can also result in textures that look even blurrier than on real hardware.

<gallery widths="300" mode="packed">

! scope="col"|Operating SystemPlatform(s)

|align=left|{{Icon|Windows}}

|align=left|{{Icon|Windows, |Linux, |macOS}}

|Multi-platformalign=left|{{Icon|Windows|Linux|macOS|FreeBSD}}