Well, I sure hope emulation and computing power keep evolving.
Mario64 at Intro Scene:
GL - 85.5 fps
D3D11 - 85.6 fps
It important that Hard VSync is turned off and else ParallelN64 stutters, and Maximum Run Speed is at x0.0 for maximum framerate when benchmarking.
Show FPS and press SPACE bar for Throttle.
I don’t think there is a way to run all N64 games full speed with Angrylion, despite it being multithreaded now and even if you have a top CPU. It’s just a thing that probably wasn’t made for mainstream use and it just happens that CPUs now can brute force through it in some games. But some other games will always be slow with it and i don’t know if there’s going to be a CPU strong enough anytime soon. Moore’s law failed.
That is, unless the plugin itself receives a MASSIVE optimization boost or something. It being multithreaded now helped a lot in many games though. A couple of similar boosts like that and we should be able to run the more demanding games (with a beefy Desktop CPU, i’m not asking for wizardry).
The real bottleneck is the RSP. CXD4 is an interpreter RSP, meaning it will be slower than being dynamic, and that is the reason why ParaLLEl has its RSP built from LLVC dynamic to use with LLE plugins for better performance. The RDP video is pretty fast enough for any CPU with four cores that is at least 3 ghz from Phenom or Core 2 Quads, but recommended for newer CPUs with at least 4 cores and threads.
https://www.libretro.com/index.php/parallel-rdp-and-rsp-updates-september-2016/ Info about the bottlenecks of the RSP.
My i7 4790K @ stock clock seems to handle angrylion+cxd4 just fine in ParaLLEl, m64p and Project64 with fullspeed in all my games.
The only times I experience minor, shorter drops in speed is when there is explosions and smoke on the screen (GoldenEye for example)
Except for the occasional mild slow downs it’s pretty much a perfect experience, ParaLLEl wins because it’s a Libretro core which makes it possible for RetroArch shaders which I absolutely can’t live without.
As an end user I have nothing to complain about really.
Pokemon Snap intro stutters like hell on the real hardware too when the boy appears, but the audio plays fine. It’s actually WRONG when the games runs at constant 60fps with Glide64, this is not proper emulation.
I think the “Display Framerate” is not there to show if the emulation drops in framerate but the general framerate, so it is not a reliable source of emulation performance.
A more reliable performance (stutter) indicator would be a system like in PCSX2, where it shows how much headroom is left for proper emulation of the PS2 CPU and GPU (EE, GS).
When 100% load is reached your real CPU/machine can’t cope with the emulation demands.
In example:
The game can stutter and play at 5 fps like on the real hardware, but the emulation (your real CPU) should still have plenty of headroom power, and the headroom indicator should NOT reach 100%.
Parallel N64 devs, if you read this;
Maybe it would be wise to include an option to run the Audio core at full 60fps but let the Video core skip frames like the hardware does?
Currently the emulation is referenced to 60fps Video speed and stutters (including audio) when it drops from 60fps, which is NOT what the hardware N64 is doing.
The hardware N64 is sssslllloooowwww… and it appears that it has some internal adaptive frame skipping permanently On, which drops frames if the N64 can’t handle the load (all the damn time 
) but the audio is always in sync to 59.94Hz and stutter free.
Here is a 60fps capture of the hardware N64 of Pokemon Snap intro:
N64’s internal framerate was often quite low but the number of vertical interrupts (expressed as VI/s) was a consistent ~60 to keep in line with the NTSC broadcast standard (or 50 for PAL). RetroArch’s FPS counter shows the VI/s rate rather than the internal framerate. If the FPS counter drops below 60 fps, that means it’s not maintaining full emulation speed, regardless of the internal framerate.
Thanks for clarifying.
That means the “Framerate(restart):Original” option doesn’t work, since Glide64 and gln64 run at full 60fps ignoring the selected ‘original’ option, or does it apply only to angrylion?
If it applies only to anrgylion then it doesn’t seem to work either because Mario 64 doesn’t appear to run at 60fps with this option set to Fullspeed, even though the VI/s is consistent 60.
I’m not altogether sure how that option functions, to be honest.
The third scene where it zooms on his camera while walking, it is the slowest I found on ParaLLEl and Project64 due to not having actual frameskip, concerning it’s LLE. I know Factor5 games have frameskip when you watch the speedruns on real hardware. So far, Battle for Naboo on some levels plays half the speed sometimes on the FX-8350. For the Renderer itself, it seems to use all threads and goes around 50% usage, except one of them going higher by the LLE plugin. It’s interesting how in PCSX2 for software rendering, you should leave one thread for the pcsx2 and rest for graphics, but for Angrylion Multithreaded when testing an Quad core CPU, I get generally higher performance if I use all threads as opposed to three.
Edit: Some versions of Mupen64Plus and any Project64 have Quake 2 trying to either run at stable 30fps or 60fps and the demos plays too fast. With ParaLLEl and M64p, it plays at more correct speed, but I don’t know if it is completely correct on some areas since I haven’t seen the game running demos in real hardware. Although, I get slightly more performance on ParaLLEl if I disable expansion pack since enabling it will render the game in 24bit colors instead of dithered 16 bit. It is proven in Digital Foundry’s video of Quake 2.
VI/s isn’t frame rate. It’s hertz. TVs are 60hz and all consoles have that as the default. So when RetroArch says 60, it means the emulated console is running at full speed, not that the game runs at that frame rate.
The older Glide64 did have an actual frame rate counter (not hz). Not sure why they removed it from GlideN64.