Changes

|[https://pj64netplay-emugithub.mlcom/download.html {{Project64NetplayVer}}Project64Netplay/Project64-Netplay-2x git]

;[[CEN64]]: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.

;[[UltraHLE]]:marked a milestone in Nintendo 64 emulation, in that it was the first to play some popular N64 titles at full speed on hardware made at the time of its release through [[High/Low-level emulation|high-level emulation]]; it isn't without its drawbacks though - pressure from users, combined with legal threats from Nintendo, forced them to discontinue development. Besides being for historical value, there's not much to expect from this emulator anyway due to compatibility issues.

One of the biggest hurdles to emulating the Nintendo 64 is 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 components 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 Reality Coprocessor made by SGItime (OpenGL 1.x and Direct3D 9). The Reality Display Processor was For the most powerful consumeraverage user, hardware-grade accurate GPU at the acceleration would be out of reach for a long time of . [[UltraHLE]] offered a compromise. In contrast to earlier consoles, whose video chips in hindsight had been easy to render to the consolehost CPU's release; this was a selling point that Nintendo wanted framebuffer, performant RDP emulation had to emphasize as a result of working with SGI. Howevertake shortcuts, reverse engineering efforts for popular Nintendo 64 including programming around specific games showed that Nintendo's software development kit included 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 common microcode for functional equivalent rather than the RDPexact method. It's possible Nintendo didn't want This also gave way to give developers access at prettier, higher resolution graphics, though whether or not this is an improvement is subjective and a lower level out common point of fears that doing so would damage consumer unitsdiscussion. Unfortunately it proved to be hit and miss, but that meant most of the effort spent emulating the RDP would go towards figuring out how owing to handle the nature of per-game microcodedetection and having to tweak settings to prevent some games for running into graphical glitches.

* Most developers Low-level RDP emulation was continually improved in 1999 and 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 early 2000s opted to approximate functions through various APIs such community, though reception wasn't as Direct3D, OpenGLwarm overall, since it ran only on the CPU and even Glidewas thus painfully slow on mid-grade machines. While this resulted in much more reasonable A dozen forks attempted to bring the system requirements for down and the current incarnation that does so is Angrylion RDP Plus, using multithreading. Accurate low-level emulation, along with prettier, higher resolution graphics, this method proved would only come to be hit and missthe GPU in 2020, often requiring perwhen a new version of the Mupen64Plus-game tweaks and settings to prevent graphical glitches on many gamesbased ParaLLEl [[libretro]] core was released containing a rewritten RDP plugin using compute shaders in Vulkan. Some games flat out didnThough it isn't worka direct fork of Angrylion, because it wasn't clear what Themaister says the Angrylion code was the central point of reference for developing the microcode did or whyplugin, and required extensive hardware testing<ref>[https://github.com/Themaister/parallel-rdp#disclaimer README] for parallel-rdp repository on GitHub. § Disclaimer.* On the low"While paraLLEl-level side, developers would either completely emulate the RDP or autodetect the microcode and use uses Angrylion-Plus as an appropriate implementation for the gamereference, 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 former would mean test suite uses Angrylion-Plus as a software renderer accurate reference to the hardware but major performance bottlenecks unless optimizations like vectorization validate implementation and multicross-threading were implementedchecking behavior. The latter would mean faster performance but developers would still have "</ref> meaning ParaLLEl uses the same strategies that Angrylion does to figure out how to account for edge casesemulate 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).

The already available [http://assemblergames.com/l/threads/aleck64-on-retail-consoles-poc.55041/ patches] to convert arcade ROM dumps to regular N64 ROM format can be found [http://micro-64.com/database/aleck64.shtml here]. While Mupen64Plus-based emulators can't run these conversions out of the box, Project64 does just fine.