2,527
edits
Changes
Jump to navigation
Jump to search
|Larper64|Windows|[https://thirdworld.dev/files/Larper64.7z 0.1]|{{✓}}|{{✗}}|{{✗}}|{{✗}}|{{✗}}|{{✗}}|{{✗}}|-!colspan="11"|Mobile/ ARM
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===
===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 Nintendo 64 is the Reality Display Processor(RDP), itself a part one of two components in the N64's Reality Co-ProcessorCoprocessor made by SGI. The N64's RDP was the first real 3D accelerator GPU on consoles. In fact, it Reality Display Processor 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 RDPconsole's complexity & flexibilityrelease; this was a selling point that Nintendo wanted to emphasize as a result of working with SGI. In additionHowever, many reverse engineering efforts for popular Nintendo 64 games showed that Nintendo's software development kit included a common microcode for the RDP functions have . It's possible Nintendo didn't want to be reproduced in software for accuracygive developers access at a lower level out of fears that doing so would damage consumer units, which takes a lot but that meant most of processing powerthe effort spent emulating the RDP would go towards figuring out how to handle the microcode.
For this reason, most * Most developers have instead in 1999 and the early 2000s 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 resulted in much more reasonable system requirements for emulation, along with prettier, higher resolution graphics, this method can proved to be hit and miss. It , often requiring per-game tweaks and settings to prevent graphical glitches on many games. Some games implemented custom graphics flat out didn't work, because it wasn't clear what the microcode which had yet to be reverse-engineered. Although many did or even all of them have already been implemented in HLE mode in 2016-2018 with dedicated work from GLideN64's lead programmer, gonetzwhy, and one or two assistantsrequired extensive hardware testing.<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* On the low level side, Stunt Racer)|publisher=GitHub|accessdate=2018-06-17|date=2018-02-10}}</ref> For example, [https://youtu.be/HfCOnmRHI0o Factor 5]'s games do now work, specifically when using GLideN64 plugin's 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-developers would either completely emulate the RDP or autodetect the microcode and use an appropriate implementation-of-microcodes-forthe game.html|title=HLE implementation of microcodes for "Indiana Jones" The former would mean a software renderer accurate to the hardware but major performance bottlenecks unless optimizations like vectorization and "Battle for Naboo" completedmulti-threading were implemented.|publisher=Blogspot|accessdate=2018-06-17|date=2018-05-26}}</ref> Other games may The latter would mean faster performance but developers would still have issues with such RDP quirks as frame buffer/depth buffer access (issues with to figure out 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)to account for edge cases.
Lowgonetz 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-level emulation can be handled in two ways, complete low29}}</ref><ref name="ZSortBOSS">{{cite web|url=https://github.com/gonetz/GLideN64/issues/1685#issuecomment-level software emulation or a hybrid approach 364436534|title=Initial implementation of LLE RDP emulationBOSS ZSort ucode (WDC, which involves using graphics APIs to simulate 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 RDP while using lowhigh-level RSP emulation to emulate the graphics microcodemode.<ref name="Indiegogo">{{cite web|url=https://www.indiegogo. Low com/projects/indiana-j-infernal-machine-high-level software -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 the RDP involves replicating all RDP functionality in software, which allows microcodes for very high accuracy but can suffer from major performance issues unless optimizations such as vectorization "Indiana Jones" and multi"Battle for Naboo" completed.|publisher=Blogspot|accessdate=2018-threading are performed. Hybrid LLE emulation can allow for performance enhancement over low level software 06-17|date=2018-05-26}}</ref> Other games may still have issues with RDP emulation but can suffer from various problems due to things such as replicating quirks like frame buffer/depth buffer access (issues with how the N64's numerous blending/combine modes, emulating frame buffer access is used as well as performance issues), VI emulation, and replicating how polygons combine/blending modes are rasterized to the screen emulated (due to how the RDP renders primitives on a low levelsuch as noise issues and combiner accuracy).
|+PC
no edit summary
|emulated = {{✓}}
}}
The '''Nintendo 64''' is a 64-bit fifth-generation console released by Nintendo on September 29, 1996 for {{inflation|USD|199.99|1996}}. It has a 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, making a total of totaling 8MB of RAM), .</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.
==Emulators==
{| class="wikitable" style="text-align:center;"
! scope="col"|Name
! scope="col"|Operating SystemPlatform(s)
! scope="col"|Latest Version
! scope="col"|Active
! scope="col"|[[Recommended Emulators|Recommended]]
|-
!colspan="11"|PC/ x86
|-
|[[Mupen64Plus]]
|Multi-platformalign=left|{{Icon|Windows|Linux|macOS|FreeBSD}}
|[https://github.com/mupen64plus/mupen64plus-core/releases {{Mupen64PlusVer}}]
|{{✓}}
|-
|[[Project64]]
|align=left|{{Icon|Windows}}|[https://github.com/project64/project64/releases {{Project64Ver}}]|{{✓}}<br >[https://www.pj64-emu.com/nightly-builds Dev]
|{{✓}}
|{{✓}}
|{{✓}}
|{{✓}}
|{{✗}}
|{{✓}}
|-
|[[Project64 Netplay]]
|align=left|{{Icon|Windows}}
|[https://pj64netplay-emu.ml/download.html {{Project64NetplayVer}}]
|{{✓}}
|-
|[[CEN64]]
|align=left|{{Icon|Windows, |Linux, |macOS}}
|[https://github.com/tj90241/cen64 Git]
|{{✓}}
|{{✓}}
|{{✗}}
|{{✗~}}
|-
|[[1964]]
|align=left|{{Icon|Windows}}
|[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)
|{{✗}}
|{{✗}}
|-
|[https://web.archive.org/web/20160828165435/http://forums.daedalusx64.com/ Daedalus]DaedalusX64|Windowsalign=left|{{Icon|Linux}}|[http://www.dcemu.co.uk/vbulletin/threads/599734-Daedalusx64-for-Windows-OSX-Linux-Updated-v1-1?p=2148637718 1.1] - [https://github.com/DaedalusX64/daedalus /releases/latest Git]|{{✗✓}}
|{{✓}}
|{{✓}}
|-
|[[Sixtyforce]]
|align=left|{{Icon|macOS}}
|[http://sixtyforce.com/download/ 1.0.4]
|{{✓}}
|{{✓}}
|{{✓}}
|{{✗}}
|{{✗}}
|{{✗}}
|{{✗}}
|-
|Larper64
|align=left|{{Icon|Windows|Linux}}
|[https://thirdworld.dev/ 0.3]
|{{✓}}
|{{✗}}
|{{✗}}
|{{✗}}
|{{✗}}
|-
|[[UltraHLE]]
|align=left|{{Icon|Windows}}
|[https://web.archive.org/web/20070312015944/http://www.emuunlim.com/UltraHLE/ultrahle.zip 1.0]
|{{✗}}
|-
|[[MAME]]
|Multi-platformalign=left|{{Icon|Windows|Linux|macOS|FreeBSD}}
|[http://www.mamedev.org/release.html {{MAMEVer}}]
|{{✓}}
|-
|[[Ryu64]]
|align=left|{{Icon|Windows, |Linux, |macOS}}
|[https://github.com/Ryu64Emulator/Ryu64 Git]
|{{✗}}
|-
|R64Emu
|align=left|{{Icon|Windows, |Linux, |macOS}}
|[https://github.com/rasky/r64emu Git]
|{{✓}}
|{{✗}}
|-
|-
|[[Mupen64Plus]] FZ
|[[Android emulatorsalign=left|{{Icon|Android]]}}|[https://play.google.com/store/apps/details?id=org.mupen64plusae.v3.fzurita 3.0.208 222 (beta)]
|{{✓}}
|{{✓}}
|-
|[[Mupen64Plus]]-pandora
|align=left|{{Icon|Pandora}}|[https://pyra-handheld.com/boards/threads/mupen64plus-2-2.72661/ Build 2021] (v2.2)
|{{✓}}
|{{✓}}
|{{✓}}
|-
|MegaN64<br/><small>(Mupen64+ based)</small>[[Project64]]|[[Android emulatorsalign=left|{{Icon|Android]]}}|[https://playwww.googlepj64-emu.com/store/apps/details?id=com.aspieapps.free.emulator 7.0nightly-builds Dev]|{{✓}}
|{{✓}}
|{{✓}}
|{{✓}}
|{{✗}}
|{{✗}}|{{✗✓}}
|-
!colspan="11"|Consoles
|-
|[[Virtual Console]]
|[[Wii emulatorsalign=left|{{Icon|Wii]], [[Wii U emulators|Wii U]]WiiU}}
|N/A
|{{✓}}
|-
|Not64
|[[Wii emulatorsalign=left|{{Icon|GCN|Wii]], [[GameCube_emulators|GameCube]]}}|[https://github.com/Extrems/Not64/releases/latest 2017100920200524]|{{✗✓}}
|{{✓}}
|{{✓}}
|-
|[https://code.google.com/p/mupen64gc/ Wii64]
|[[Wii emulatorsalign=left|{{Icon|GCN|Wii]], [[GameCube_emulators|GameCube]]}}
|[https://code.google.com/archive/p/mupen64gc/downloads 1.1 beta]
|{{✗}}
|{{✗}}
|-
|[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]
|{{✓}}
|{{✓}}
|{{✗}}
|{{✗}}
|{{✓✗}}
|-
|}
* [[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 compatibilities 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.
* Daedalus is an Nintendo 64 emulator for PC which was ported to the PSP under the name of DaedalusX64. The PSP, which has been version later became the main version and got ported to Windowsplatforms such as the Dreamcast, the PS2, but results are even more hit-the PS Vita and-miss than on other emulators due to being made for PSP first and foremostthe 3DS. On PSP, most several games are playable, able to reach full speed and most of them work with some minor sound little emulation issues.
* [[Sixtyforce]] 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 irrelevant.
{{Main|Recommended N64 plugins}}
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)
</gallery>
===[[Texture filtering]]===
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.
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. 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.
RetroArch's Mupen64Plus core has taken some steps which help remedy these problems. It is the only emulator that implements 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 do not have these problems at all.
<gallery widths="300" mode="packed">
Project64_2013-06-26_17-44-58-31.png|Conker's Bad Fur Day copyright screen, displaying issues with filtered text.
Mupen64plus_2013-08-18_20-35-50-08.png|Ocarina of Time's menu subscreen, displaying issues with filtering. Note how the Quest Status screen appears to be divided into a grid.
{| class="wikitable" style="text-align:center;"
|-
! scope="col"|Name
! scope="col"|Operating SystemPlatform(s)
! scope="col"|Latest Version
! scope="col"|Active
! scope="col"|N64 Mouse
! scope="col"|[[Recommended Emulators|Recommended]]
|-
! colspan="7"|PC / x86
|-
|[[Project64]]
|align=left|{{Icon|Windows}}
|[https://github.com/project64/project64 2.3.2]
|{{✓}}
|-
|[[CEN64]]
|align=left|{{Icon|Windows, |Linux, |macOS}}
|[https://github.com/tj90241/cen64 Git]
|{{✓}}
|-
|[[MAME]]
|Multi-platformalign=left|{{Icon|Windows|Linux|macOS|FreeBSD}}
|[http://www.mamedev.org/release.html {{MAMEVer}}]
|{{✓}}
* Yoshi's Story
|}
==Notes==
<references group=N />
==References==
