Changes

One of the biggest hurdles to emulating the Nintendo 64 is was the Reality Display Processor (RDP), one which used a custom design that had to be fine-tuned to get more performance out of two components in the Reality Coprocessor made by SGIsystem using microcode. The Reality Display Processor was To emulate the RDP accurately, one would have to execute said microcode the most powerful consumer-grade GPU at way the time RDP did, which differed from PC graphics cards of the console's release; this was a selling point day. To complicate matters further, API standards that Nintendo were available on PCs two decades ago were nowhere near as flexible as they are today. If you wanted to emphasize as a result of working with SGI. Howevermake an accurate GPU-accelerated RDP plugin in 2003, reverse engineering efforts for popular Nintendo 64 games showed that Nintendoyou simply couldn's software development kit included a common microcode for t with the RDP. It's possible Nintendo didn't want to give developers access at a lower level out of fears that doing so would damage consumer units, but that meant most APIs of the effort spent emulating time (OpenGL 1.x and Direct3D 9). For the RDP average user, hardware-accurate GPU acceleration would go towards figuring be out how to handle the microcodeof reach for a long time.

* Most developers [[UltraHLE]] offered a compromise. In contrast to earlier consoles, whose video chips in 1999 and hindsight had been easy to render to the early 2000s opted host CPU's framebuffer, performant RDP emulation had to take shortcuts, including programming around specific games' microcode to approximate functions through various APIs such as cleanly translate their graphics commands into API calls using Direct3D, OpenGL, and even Glide. While With this resulted in much more reasonable , the theoretical system requirements for emulationplummeted, along with 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 method is an improvement is subjective and a common point of discussion. Unfortunately it proved to be hit and miss, often requiring owing to the nature of per-game tweaks microcode detection and having to tweak settings to prevent some games for running into graphical glitches on many games. Some games flat out didn't work, because it wasn't clear what the microcode did or why, and required extensive hardware testing.* On the low-level side, developers would either completely emulate the RDP or autodetect the microcode and use an appropriate implementation for the game. The former would mean a software renderer accurate to the hardware but major performance bottlenecks unless optimizations like vectorization and multi-threading were implemented. The latter would mean faster performance but developers would still have to figure out how to account for edge cases.

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 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 have spent a large portion of development improving GlideN64's microcode 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 (including issues with how the frame buffer framebuffer is used as well as performance issues), VI emulation, and how combine/blending modes are emulated (such as noise issues and combiner accuracy).