1,359
edits
Changes
Jump to navigation
Jump to search
New note under Retroarch's list about 'Super VI Mode'.
* [[Project64]] is a mostly 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 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].
* [[CEN64]] is an up-and-coming emulator that aims for cycle accuracy while, at the same time, aiming to eventually be usable on modern PC hardware. It currently lacks many features and has spotty compatibility, but it's gradually improving. It can already emulate some well-known edge cases such as the picture recognition in Pokemon Snap.
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 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 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 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-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), [https://www.youtube.com/watch?v=mzR93F9gPdc 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 on a low level).
