I just set up runahead for all of my 8 and 16-bit consoles and it is AWESOME. However, when trying to set runahead for mupen64plus, it doesn’t seem to reduce any amount of frames. I haven’t seen a lot of discussion regarding runahead on any of the 3D consoles, but from what I’ve read it should theoretically work with enough processing power. Since I’m on a PC with a fairly decent CPU, I figure I might have a chance here if I could get it to work.
N64 emulation is weird when it comes to input lag. You get games like Mario 64 that has a pretty bad 4 frames of lag, which i believe is worse than the real console, and Smash Bros which has zero lag, it reacts on the next frame. Then you disable framebuffer effects and Mario 64 also reacts on the next frame (but some stutters occur).
I haven’t seen a difference between Parallel and Mupen though. Both cores seem to react the same on my system. Oh and standalone N64 emulators feel really bad outside RetroArch. Mario 64 is unplayable on my LCD TV on PJ64+GlideN64. The input Lag is way more noticeable. Which is why i hope some day we see an update for the Mupen + Gliden64 core. It’s very outdated and it seems dead 
I noticed this as well since I was using Mario 64, Smash, and Mario kart 64 primarily for testing. Mario 64 and mario kart both had 4 frames of lag using mupen. When switching over to ParaLLel, I only had 2 for mario kart, I’ll have to give SM64 a shot now too.
That’s really interesting, I have always used PJ64 due to the high compatibility and never considered any difference in input lag until now. I can’t say I’ve noticed feeling like there is more than mupen, but it’s definitely there and I’d like to drop it to the smallest amount possible (given I’m also playing through an LCD TV). Do you know of any way to test for internal lag on PJ64? I’m curious to see how it compares.
I agree with you on the mupen+glideN64 core, I was really hopeful for that to progress. I think there is someone compiling standalone builds of the combo, but I would like to see it make a return as an RA core. Until then, I may check out angrylion a bit more since it seems to have dropped lag in MK64, which is the game that is most competitive between my friends and I. The joystick seems very ‘twitchy’ in comparison to PJ64 though so I’ll have to find some settings to get it more akin to the real deal. Hopefully, somehow, runahead can work with n64 cores in the future. There is so much on the table for some of these games. Seeing the PS1 and Saturn able to do runahead gives hope. And my PC seems to run either n64 core perfect with runahead enabled and 2 instances. I’m sure there’s more to it I’m missing though that is causing it not to function.
GlideN64 had many fixes in the last couple of years, a few of them pretty major. It’s pretty active. Right now i’m testing games in m64p and compatibility is amazing, with very few bugs in a handful of games. Atm, the Mupen core doesn’t come close to this. It must be more than a year out of date.
I also remember there was a talk about the ParaLLel core receiving GlideN64 but that seems abandoned as well.
So basically N64 emulation is only good outside RetroArch atm. “m64p” being the most compatible setup you can use.
So, I did the testing today and it completely confirmed what you were saying regarding the input lag on Project64+GlideN64… I did basically the exact method that is used in the “input lag investigation” thread with a 240fps camera and came up with these results based on 28 individual button presses. Crazy amount of additional lag with PJ64, I switched to ParaLLEl and won’t be looking back.
Here are the results for Mario Kart 64 (ntsc)
input lag (ms)
Project64 - 128.2738095 ms
ParaLLEl - 89.73214286 ms
Mupen+FBE OFF- 65.32738095 ms
Frames at 30fps
Project64 - 3.848214286 frames
ParaLLEl - 2.691964286 frames
Mupen+FBE OFF- 1.959821429 frames
Frames at 60fps
Project64 - 7.696428571 frames
ParaLLEl - 5.383928571 frames
Mupen+FBE OFF- 3.919642857 frames
Some background on my setup: -xbox one S controller via USB -Samsung KS8000 TV (about 22ms input lag according to rtings) -Latest public release of Windows 10 -Retroarch 1.7.3 -Project64 2.3.2 with GlideN64 3.0 -Hard GPU sync enabled, no runahead enabled
Which game did you test?
I believe the extra input lag in PJ64 is simply because it’s not a RetroArch core. A similar result will apply with other standalone emulators as well, i’m pretty sure. Which is why RetroArch is so important. Because with it’s input lag reduction options it makes emulators playable on LCDs.
Ahh, I totally forgot to mention that, I used the NTSC version of mario kart 64. Went to time trials mode, 1st track, and did jumps while standing still using a button press instead of the trigger for more precise recognition.
I agree, RA is awesome. I wonder though how the mupen64plus core will fare given the two additional internal lag frames it has compared to ParaLLel. Might attempt that next
1 Like
About the extra frames of lag in Mupen core compared to Parallel.
Honestly, i haven’t noticed that so far, at least with the games i tested. Could you tell me which game gives you extra lag frames in the Mupen core compared to Parallel?
Mario Kart 64 again - Noticed the extra frames when I was trying to get runahead to work with either of the n64 cores and was seeing how many frames to advance for each.
It’s not the core’s fault for the different input lag results. It’s the framebuffer emulation.
I can’t make Mario Kart 64 work with ParaLLEl+Angrylion. All i get is a black screen no matter what other options i change. So i played the game with ParaLLEl+Glide64 (the older plugin). And yes, it’s faster than Mupen+GlideN64 (the newer plugin). It reacts to the 3rd frame while in Mupen it reacts on the 5th. Just like you said, so i assume you also use ParaLLEl+Glide64.
However, if you use Mupen64+GlideN64 (the newer plugin) and you disable framebuffer effects, it reacts on the next frame! That’s zero lag. The same results are in Mario 64 as well.
So it’s the newer GlideN64’s fault. The way it handles framebuffer effects is slower than the older Glide64. And i know the older Glide64 plugin does emulate framebuffer effects during the tests because the monitor above the tunnel in the first Mario Kart racing track is working. While in GlideN64, if you disable framebuffer effects, the monitor is black (there is no option in ParaLLEl to disable framebuffer emulation anyway).
So in conclusion:
OLD Glide64 plugin + framebuffer ON = 2 frames of input lag
New GlideN64 plugin + framebuffer ON = 4 frames of input lag.
I also know that the newer GlideN64 plugin is slower than the real machine. But nobody wants to believe this because it reacts the same as Angrylion. And because Angrylion is accurate, it must mean that it’s as slow on the real machine. Which i don’t believe. But i don’t have the equipment to test the real machine and prove it so i just don’t complain anymore.
Edit: I also noticed the intruduction of stutters with Glide64 (framebuffer ON) and GlideN64 (framebuffer OFF) on Mario 64. It runs smoothly with GlideN64 (framebuffer ON) but with the added input lag. So i don’t know what’s going on with that.
1 Like
Have you tried using LLE CXD4 RSP with 640x480 resolution? That is what the plugin needs to work in ParaLLEl.
Yes. That’s my default configuration with ParaLLel. But Mario Kart won’t load.
GemaH, thank you so much for your post! Seriously awesome breakdown and now it all makes a lot more sense. I’m loving learning about all of this. I didn’t have too much time to mess with things yet, but I went ahead and tried the mupen core with glideN64 and no framebuffer. Only did a couple tracks, but the controls felt tighter than I’ve ever experienced on an emulator.
This brings up a crossroads situation for everyone emulating the n64 at this point though. Using mario kart 64 as an example, which is one of the better emulated n64 games, we have to make a choice. If you choose glide64 for its lower framebuffer lag, you get the bug that speeds up multiplayer matches way beyond normal. glideN64 fixes this bug, but gives you additional lag. Turning off the framebuffer cuts the lag down considerably, but now you don’t have the screen working in the first level and suffer potential other graphical or stuttering issues (if not in mk64, definitely in others). Runahead would be the ultimate fix if it could work since we would get the best of all worlds.
I would love to see someone do this testing on real hardware just so we can see. I have real hardware, but have no way of connecting it. I would guess though that with framebuffer off, I’m quite close to the real deal.
1 Like
No problem. I have spent a lot of time with N64 emulation and tried a lot of things with different emulators and settings so i can find the best way to play each game i care for. But input lag bothers me the most and it’s the one thing i can’t be sure about because i also don’t have the means to measure and compare the real hardware.
Most people in the scene seem to be happy with whatever results Angrylion provides. I’m skeptical though so i will wait until someone measures the real machine. Because i doubt the “real” Mario 64 or Mario Kart have so many frames of lag. But hey, if the lag does exist on the real machine as well then everything is fine. But if there is extra lag in Angrylion/GlideN64 (in these particular games at least) then something must be off with those plugins as well.
Is anyone claiming that Angrylion is finished and identical to hardware? I think that what people are saying is that Angrylion has a goal of accuracy and it has a good foundation for this because of being LLE and software rendered. So moving forward, it’s a better idea to improve on this, than to go back to try yet again with hardware rendered HLE emulation which will always be inaccurate no matter what.
At the end of the day, someone still has to put in the work to implement all the hardware features and fix all the bugs. Even with bsnes there is a difference between now and where it was at a couple of years ago, in terms of accuracy.
Dunno if anyone claims Angrylion is perfect. But some years ago when i brought up the Mario 64 framebuffer input lag issue in GlideN64, the answer i got was basically “Angrylion does the same, so there shouldn’t be an issue”.
Now, i’m not saying whoever says that is wrong. Maybe Angrylion does react the same way as the real hardware when it comes to input lag. Maybe i am in the wrong here. But if i had to bet, i’d say i’m right. The real N64 doesn’t feel quite as laggy in Mario 64, to me at least (using the same display). And i kinda doubt dream team Nintendo EAD would release one of their most important platform games with 4 frames of internal lag (not counting possible display, controller, OS, etc additional lag). I mean, Super Mario World had 2 frames of internal lag and that’s the maximum you can have before it gets bad i suppose. At least in platform games where you need more responsiveness.
But these are my only arguments. I can’t prove my case and neither else can until someone manages to get some accurate measurements from the real hardware. Right now, i can’t take Angrylion as the definitive proof of how the real N64 behaves. Graphically sure, but isn’t input lag a separate thing?
Just an update after now understanding FBE and its effects a bit better. Switched to Mupen64plus in RA, turned FBE to “false” and did the same test as before. I updated my original test results post, but have also quoted a section below. This is AMAZING. Input lag is literally cut in half from Project64+GlideN64. 65ms is incredibly fast, especially considering about ~22ms from the TV, 4ms average from the USB polling, etc. I attempted to turn off FBE on Project64 to see if I could similar numbers and have all the benefits of the newer GlideN64. Unfortunately, this throws the centering of the picture in fullscreen mode way off. The bottom half of the picture sits at the top of the screen. Oh well, I’m loving the results I have so far.
Also, of lesser significance, I tested mupen with FBE off and internal resolution at 6X standard. There was no statistical difference using the higher resolution. Nice to know I’m not losing any performance for visuals.
1 Like
An now the question remains. Are those BFE OFF metrics the same as the real console? Obviously the console does have the frame buffer effects. But does it suffer from that extra input lag when it does so?
It’s also a game by game thing. If you test Smash Bros for instance, even with BFE ON, the game has zero internal lag. It reacts to the next frame. So maybe the game doesn’t use the frame buffer at all?
I’m in your camp regarding the FBE lag, I don’t think it is nearly that much on real hardware. The problem is that I don’t think there will ever be a way to determine the lag solely created by the Frame buffer on a real console. This creates the same issue we have now - there’s no way to prove/disprove the that the lag from FBE is true to real hardware. If I were to do the testing on a real console and found that there were 3 frames less lag on a given game compared to GlideN64 with FBE on, people could just claim the additional lag is due to emulation overhead and not the FBE.
There are only certain games where the FBE causes such issues, but they are also some of the most popular. Hopefully something can be done to mitigate the massive lag for these games so they can be enjoyed true to their original form for years to come.
If runahead was able to work somehow, it would be a decent workaround- allowing us to run with the frame buffer emulation on, but with the ability to splice out a chunk of the lag introduced. It’s no substitute to fixing it directly from the plugin, but probably more likely to happen. I did stumble across this though so it seems like we aren’t the only ones pushing for this to be fixed https://github.com/gonetz/GLideN64/issues/1822
But when you disable the BFE and the game almost has zero or very little lag as a result and then, after you enable it, you get at least +2 frames of lag then you know it’s BFE lag. And if the real game reacts closer to how the emulator reacts without that extra lag then you know it must be something wrong with BFE emulation.
Maybe there is some overhead with the emulator itself, outside BFE, on top of that but it seems there’s definitely extra lag caused by BFE. At least with some games. Mario 64 is the poster child of this issue and i think it’s popular enough to worth some investigation.
Oh and 30fps games tend to always have at least 1 or 2 frames of lag since you always get repeated frames on a 60hz display. Which is how Mario 64 behaves in emulators without BFE.
Thanks for the link btw.