You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Other not currently compatible Nintendo 64 emulators is ParaLLEl N64 and its fork ParaLLeXT which uses GPU only ParaLLEl RDP, but as I understand it they where originally based on Mupen64 Plus and their renderer was also based on Angrylion:
So accurate software-based emulation of the N64 has remained an elusive pipe dream for decades. However, it seems things are finally changing now on high-end hardware.
This test was conducted on an Intel i7 7700K running at Boost Mode (4.80GHz). We are using both the OpenGL video driver and the Vulkan video driver for this test, and we are running the game Super Mario 64. The exact spot we are testing at it is at the Princess Peach castle courtyard.
Note that we are using the cxd4 RSP interpreter which, despite the SSE optimizations, would still be pretty slow compared to any RSP dynarec, so these results are impressive to say the least. There are games which dip more than this – for instance, Killer Instinct Gold can run at 48fps on the logo title screen, but on average, if you turn off VI filtering, most games should run at fullspeed with this configuration.
In case you didn’t notice already, Vulkan doesn’t really benefit us much when we do plain software rendering. We are talking maybe a conservative 3fps increase with VI filtering, and about 2fps or maybe even a bit less with VI turned off. Not much to brag about but it could help in case you barely get 60fps and you need a 2+ fps dip to avoid v-sync stutters.
Oddly enough, the sole exception to this is GoldenEye 007, where the tables are actually turned, and OpenGL actually leaps ahead of Vulkan quite significantly, conservatively by about 5fps with VI filter applied, and even higher with no VI filter. I tested this many times over to see if there was maybe a slight discrepancy going on, but I got the exact same results each and every time.
The text was updated successfully, but these errors were encountered:
Apparently; Mupen64Plus-Next, Mupen64Plus, parallel-n64 and paraLLeXT all already have an old version of Angrylion RDP Plus implemented, though they just call it "multithreaded angrylion", so think the flag for build old code with make is HAVE_THR_AL=1?
Could this "Angrylion RDP Plus" multithreading fork of the Angrylion renderer be used as an alternative software renderer in Kodi?
https://github.com/ata4/angrylion-rdp-plus
Update from fork "Angrylion RDP Plus" and use as alternative to "multithreaded angrylion" video renderer for Mupen64Plus-Next?
https://github.com/libretro/mupen64plus-libretro-nx/tree/develop/mupen64plus-video-angrylion
Not a good replacement for a GPU implementation but maybe an option for multithreaded software renderer on multi-core CPUs?
https://www.ngemu.com/threads/spread-the-word-angrylion-rdp-plus.200521/
https://www.reddit.com/r/emulation/comments/6vyeld/parallel_rdp_n64_vi_filter_vs_super_vi_filter/dm5wzxw/
It is designed to work as a video renderer for N64 emulators, including Mupen64Plus-Next (i.e. mupen64 forks and derivatives):
https://github.com/kodi-game/game.libretro.mupen64plus-nx
https://github.com/libretro?q=mupen64&type=all&language=&sort=
Other not currently compatible Nintendo 64 emulators is ParaLLEl N64 and its fork ParaLLeXT which uses GPU only ParaLLEl RDP, but as I understand it they where originally based on Mupen64 Plus and their renderer was also based on Angrylion:
Anyway, the project looks to become active again with a new release this year:
https://github.com/ata4/angrylion-rdp-plus/releases
Read more about it in this blog article on libretro.com from 2017:
https://www.libretro.com/index.php/cores-progress-report-catering-to-high-end-desktops-dolphin-libretro-core-and-others-now-supports-resolutions-of-8k-and-up/
Parallel N64 – Angrylion software renderer
So accurate software-based emulation of the N64 has remained an elusive pipe dream for decades. However, it seems things are finally changing now on high-end hardware.
This test was conducted on an Intel i7 7700K running at Boost Mode (4.80GHz). We are using both the OpenGL video driver and the Vulkan video driver for this test, and we are running the game Super Mario 64. The exact spot we are testing at it is at the Princess Peach castle courtyard.
Note that we are using the cxd4 RSP interpreter which, despite the SSE optimizations, would still be pretty slow compared to any RSP dynarec, so these results are impressive to say the least. There are games which dip more than this – for instance, Killer Instinct Gold can run at 48fps on the logo title screen, but on average, if you turn off VI filtering, most games should run at fullspeed with this configuration.
In case you didn’t notice already, Vulkan doesn’t really benefit us much when we do plain software rendering. We are talking maybe a conservative 3fps increase with VI filtering, and about 2fps or maybe even a bit less with VI turned off. Not much to brag about but it could help in case you barely get 60fps and you need a 2+ fps dip to avoid v-sync stutters.
Oddly enough, the sole exception to this is GoldenEye 007, where the tables are actually turned, and OpenGL actually leaps ahead of Vulkan quite significantly, conservatively by about 5fps with VI filter applied, and even higher with no VI filter. I tested this many times over to see if there was maybe a slight discrepancy going on, but I got the exact same results each and every time.
The text was updated successfully, but these errors were encountered: