10,795
edits
Changes
Jump to navigation
Jump to search
m
==Emulation issues==
{{Main|Recommended N64 plugins}}
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.
===[[High/Low level emulation|High-level vs. low-level]] graphics===
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 the PC graphics cards of the day. To complicate matters further, API standards 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.
[[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 or miss, owing to the nature of per-game microcode detection and having to tweak settings to prevent some games from running into graphical glitches.
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 the reception wasn't as warm overall, since it ran only on the CPU and was thus painfully slow on mid-grade machines. A dozen forks attempted to bring the system requirements down, and the current incarnation that does so is Angrylion RDP Plus, using multithreading. Accurate low-level emulation would only come to the GPU in 2020 when a new version of the Mupen64Plus-based ParaLLEl [[libretro]] core was released containing a rewritten RDP plugin using compute shaders in Vulkan. Though it isn't a direct fork of Angrylion, Themaister says the Angrylion code was the central point of reference for developing the plugin,<ref>[https://github.com/Themaister/parallel-rdp#disclaimer README] for parallel-rdp repository on GitHub. § Disclaimer. "While paraLLEl-RDP uses Angrylion-Plus as an implementation reference, it is not a port, and not a derived codebase of said project. It is written from scratch by studying Angrylion-Plus and trying to understand what is going on. The test suite uses Angrylion-Plus as a reference to validate implementation and cross-checking behavior."</ref> meaning ParaLLEl uses the same strategies that Angrylion does to emulate the RDP while running on the host GPU (as long as said GPU supports Vulkan).
On the high-level side, gonetz and one or two assistants 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 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).
<gallery widths="300" mode="packed">
Majora's mask accurate.png| Low-level emulation of Majora's Mask using SoftGraphic
Project64 2013-07-26 14-20-17-55.png| High-level emulation of Majora's Mask using Jabo's Direct3D
</gallery>
===[[Texture filtering]]===
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 they would 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 (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 often low resolutions.
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 can also render 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.
<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.</gallery>
===Timing issues===
One of the biggest remaining problems in N64 emulation is the lack of accurate core timings, which in practice, means games don't 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. In some instances (particularly in Rare games) this can actually result in fewer 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 emulating them properly can result in considerable to major issues. Some notable examples include the following:
* Intros and cutscenes playing too fast and not correctly syncing up with musical cues. Seen in Goldeneye's intro and Body Harvest's beginning cutscene.
* Gameplay demos running at hyper speeds. Earthworm Jim 3D is most notorious for this, though the main game itself is largely unaffected.
* 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.
* 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.
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 shouldn't be seen as the emulator becoming slower, but rather as the emulator behaving exactly like the real hardware does, as many N64 games were notorious for framerate drops.
no edit summary
;n64oid
: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 it will have performance issues on many phones. 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.
==Peripherals==
* Yoshi's Story
|}
==Emulation issues==
{{Main|Recommended N64 plugins}}
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.
===[[High/Low level emulation|High-level vs. low-level]] graphics===
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 the PC graphics cards of the day. To complicate matters further, API standards 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.
[[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 or miss, owing to the nature of per-game microcode detection and having to tweak settings to prevent some games from running into graphical glitches.
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 the reception wasn't as warm overall, since it ran only on the CPU and was thus painfully slow on mid-grade machines. A dozen forks attempted to bring the system requirements down, and the current incarnation that does so is Angrylion RDP Plus, using multithreading. Accurate low-level emulation would only come to the GPU in 2020 when a new version of the Mupen64Plus-based ParaLLEl [[libretro]] core was released containing a rewritten RDP plugin using compute shaders in Vulkan. Though it isn't a direct fork of Angrylion, Themaister says the Angrylion code was the central point of reference for developing the plugin,<ref>[https://github.com/Themaister/parallel-rdp#disclaimer README] for parallel-rdp repository on GitHub. § Disclaimer. "While paraLLEl-RDP uses Angrylion-Plus as an implementation reference, it is not a port, and not a derived codebase of said project. It is written from scratch by studying Angrylion-Plus and trying to understand what is going on. The test suite uses Angrylion-Plus as a reference to validate implementation and cross-checking behavior."</ref> meaning ParaLLEl uses the same strategies that Angrylion does to emulate the RDP while running on the host GPU (as long as said GPU supports Vulkan).
On the high-level side, gonetz and one or two assistants 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 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).
<gallery widths="300" mode="packed">
Majora's mask accurate.png| Low-level emulation of Majora's Mask using SoftGraphic
Project64 2013-07-26 14-20-17-55.png| High-level emulation of Majora's Mask using Jabo's Direct3D
</gallery>
===[[Texture filtering]]===
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 they would 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 (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 often low resolutions.
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 can also render 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.
<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.</gallery>
===Timing issues===
One of the biggest remaining problems in N64 emulation is the lack of accurate core timings, which in practice, means games don't 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. In some instances (particularly in Rare games) this can actually result in fewer 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 emulating them properly can result in considerable to major issues. Some notable examples include the following:
* Intros and cutscenes playing too fast and not correctly syncing up with musical cues. Seen in Goldeneye's intro and Body Harvest's beginning cutscene.
* Gameplay demos running at hyper speeds. Earthworm Jim 3D is most notorious for this, though the main game itself is largely unaffected.
* 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.
* 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.
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 shouldn't be seen as the emulator becoming slower, but rather as the emulator behaving exactly like the real hardware does, as many N64 games were notorious for framerate drops.
==References==
