Changes

{{Infobox console|title = Nintendo 64|logo = Nintendo64Console.png|developer = [[:Nintendo]]|type = [[:Category:Consoles|Home video game console]]|generation = [[File:N64Category:Fifth-Console-Set.jpggeneration video game consoles|Fifth generation]]|thumbrelease = 1996|250pxdiscontinued = 2002|The predecessor = [[Super Nintendo 64 (N64)emulators|SNES]]|successor = [[GameCube emulators|GameCube]]|emulated = {{✓}}}}

|[https://github.com/mupen64plus/mupen64plus-core/releases 2.5]

|{{✗✓}}

|[[Mupen64Plus|Mupen64+]] AEFZ

|2[https://play.4google.4com/store/apps/details?id=org.mupen64plusae.v3.fzurita 3.0.181]|{{✓}}

|[https://github.com/Extrems/Not64 Not64]

|{{✓✗}}

|[https://code.google.com/archive/p/mupen64gc/downloads 1.1 beta]

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 run running with GLideN64. Mupen64Plus arguably has the edge in audio accuracy over Project64 + Azimer's audio plugin.

* [[Mupen64Plus]] is a cross-platform open-source 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. However, its last official release build was in 2015 and is generally inferior to Project64's more recent releases. 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.

* [[RetroArch]]'s N64 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 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].

* 1964, along with its various versions and forks, was once a decent, speedy open-source alternative to Project64 and Mupen64, though it usually lagged behind the two in compatibilitycompatibilities wise. Nowadays it has completely fallen off the radar, as development has stopped, is Windows-only, 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.

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 to approximate the RDP's functions using high-level emulation (HLE) through various APIs such as Direct3D, OpenGL, and even Glide. While this results in much more reasonable system requirements for emulation, along with prettier, higher resolution graphics, this method can be hit and miss. It often requiring per-game tweaks and settings to prevent graphical glitches on many games. Some games that implemented custom graphics microcode which has 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 GLideN64's lead programmer, gonetz, and one or two assistants.<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]'s games do not now work, no matter what, specifically when using GLideN64 plugin's high-level graphics pluginsmode.<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 have issues with such RDP quirks as frame buffer/depth buffer access (issues with how 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).

Low-level emulation can be handled in two ways, complete low -level software emulation or a hybrid approach of LLE RDP emulation, which involves using graphics APIs to simulate the RDP while using low -level RSP emulation to emulate the graphics microcode. Low level software emulation of the RDP involves replicating all RDP functionality in software, which allows for very high accuracy but can suffer from major performance issues unless optimizations such as vectorization and multi-threading are performed. Hybrid LLE emulation can allow for performance enhancement over low level software RDP emulation but can suffer from various problems due to things such as replicating the N64's numerous blending/combine modes, emulating frame buffer access and replicating how polygons are rasterized to the screen (due to how the RDP renders primatives primitives on a low level).

It should also be noted that, even though most games "work" through the HLE method, it is not an accurate representation of what the N64 hardware's video output actually looked like but rather a rough approximation by PC graphics hardware. Your mileage may vary on whether this is a good thing or not, given the N64's often blurry low-res output.

===[[Texture filtering]]===

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.<refname="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>

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.<refname="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.

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.<refname="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><refname="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.

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].

* CEN64, like Project64, had 64DD emulation ported to it from MAME. However, it focuses on accuracy and plays much slower than other emulators, aside for the 64DD emulation itself being is imperfect. ===iQue Player emulation===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.

===iQue emulation===Before Unlike the GBAChinese releases of their more recent systems and their games, DSiQue 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, Nintendo released a modified version 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 Nintendo 64 system for the Chinese marketlanguage already, which was called explain some of the iQueChinese ROMs floating for those. Fourteen games localized to ChineseHowever, including Sin and Punishmentrecently, a unique revision almost all pieces of Ocarina of Time (the Majora's Mask port was cancelled), Mario 64, and othersiQue Player software were decrypted to regular .z64 ROM format.

Unlike Several of the Chinese releases game localizations already run on N64 emulators, but as some hardware features of their more recent systems and their the iQue Player are not yet supported, some games, no dumps in the same format as regular N64 releases exist yet for well as the N64 iQue releases. Therefore, no emulation support exists for them at all. The Chinese ROM-hacking scene is very active though system menu and have translated the Japanese regular N64 releases for many of these to their language alreadyfeatures in games such as saving, which explain some of the Chinese ROMs floating for thosedo not work yet.

[[Category: Consoles]][[Category:Fifth-generation video game consoles]]