Changes

Jump to navigation Jump to search

Nintendo 64 emulators

1 byte added, 20:03, 12 May 2022
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 PC graphics cards of the day. To complicate matters further, API standards that were 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 and miss, owing to the nature of per-game microcode detection and having to tweak settings to prevent some games for 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 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).
Anonymous user

Navigation menu