It’s been a while since i updated Mupen so i don’t know when this started. I do remember however that at some point i was getting 5 frames of lag in Mario 64 instead of 6.
Hard GPU is ON and i tried the frame delay settings. Mario 64 still gives me 6 full frames of input lag. Try the frame advance option in RetroArch. Are you getting different results?
This is the first I’ve heard of it, so if you can track down when it started happening, we can try to figure out what caused it.
In video settings, two options can decrease input lag: Hard GPU sync and Frame Delay. Try turning Gpu sync on and set frame delay as high as possible without audio distortion.
I tried all the options. Still getting 6 frames of lag in Mario 64. Try the frame advance option, are you getting different results?
It’s been a while since i tested this, like a year ago or so. I just tried it yesterday on the latest version and got this result. But i do remember i was getting 5 frames of lag before.
You can set frame buffer emulation in the emulator options to false and it will improve your response time but it will make the frame rate a little jumpy. Also have you tried running without vsync to see if the lag improves? I know on the latest build of Mupen64Plus I had to disable vsync through retroarch and invoke it through the driver. I was having a different problem with actual lag and stutter though, but alot of times input lag can be tied to vsync. Check to make sure that you have desktop composition disabled and you’re running in bordered windowed full-screen instead of actual full screen. Ofcourse don’t forget to put GPU synced frames as low as possible and frame delay as high as possible.
I’ve never heard someone recommend using borderless windowed over exclusive fullscreen to improve latency. Is that true?
Disabling frame buffer emulation does eliminate input lag but, like you said, introduces stutter/synchronization issues and that makes the game even more irritating to play.
Another game that suffers from high input lag, Banjo-Kazooie, suffers from many graphical glitches as well, if you disable frame buffer. Oh and Banjo-Kazooie needs 7 (yes SEVEN) frames to make an action.
Even if you want to disable framebuffer, there is no such option in ParaLLel+Angrylion, this option only appears in GlideN64. And in some cases, input lag is even worse in ParaLLel. Banjo Kazooie has a staggering 8 frames of lag there. Pretty much unplayable i think.
N64 emulation suffers maybe more than any other when it comes to input lag. It’s a game by game thing though, games like Smash Bros seem to have no lag at all, regardless options.
I tried every other option available to me but the lag persists (if you use frame buffer or ParaLLel). I am convinced the issue is with the cores/emulators. Not the options. I can also feel the lag in standalone emulators. Mario 64 in particular is unplayable in PJ64 (with framebuffer ON) when playing on a LCD screen even with game mode ON (it’s hard to time the multi jumps correctly because you have to press the button before Mario lands). CRT is a bit better but still pretty bad.
These statements suggest that the issue is internal to the games themselves.
The games themselves don’t have as much lag.
I have a N64 with both Mario 64 and Banjo-Kazooie. If there is any lag (i can’t feel it) it’s nowhere near as big as it is with emulators/retroArch cores. In case of Mario 64 i have to re-wire my brain to play it on any emulator because of the increased lag.
Maybe the issue is with framebuffer emulation. Maybe Smash Bros doesn’t use it, therefore it doesn’t lag. If you disable framebuffer emulation in GlideN64, the lag magically disappears in Mario 64. But doing so it may produce other regressions and glitches. Like it does with Banjo-Kazooie. So maybe frame buffer emulation has issues that cause unusually high input lag.
It’s actually pretty common knowledge among the stand alone emulator community. It’s the only way I kept my sanity with most emulators. There’s something about V-sync when running true fullscreen that eats frames. I complained once about input latency due to V-sync in a forum and their response was run the emulator in windowed mode. I was like “I don’t want to run my games in a window.” They were like “then deal with the input lag.” So at the time I was using Nestopia and did not play nice with borderless window so I just ran it in a big window and the lag was significantly less. I ran SNES9X which did play nice with borderless window and that made SNES emulation just one step above tolerable. There are only 2 emulators that Ive used that I’ve had no issues with input lag and that is Kega Fusion and Ootake. Kega Fusion automatically runs in a borderless window and automatically disables the desktop composition. I believe Ootake does the same. Play a 2D shooter like Gradius Gaiden on the ePSXe emulator in true fullscreen and you’ll get killed running into enemies and walls. Play in a borderless window and you’ll get killed for all the right reasons. It really is a thing. So I have Retroarch default to running in windowed fullscreen mode and disabled desktop composition.
This doesn’t apply if you are talking about Windows 8+ though. There’s no way to disable the compositor and if you care about input lag the only way around it is exclusive fullscreen. It was one thing holding higan/bsnes back for awhile was lack of exclusive fullscreen support. The retroarch setting to disable desktop composition does nothing on Windows 8+.
Yeah all three of my computers are Windows 7 and will be to the bitter end. The OP never mentioned which OS he actually has. All I know is on Windows 7, running emulators in a window is the best way to run them to drastically reduce input lag. In the grand scheme of things running in a window is what cuts the lag. Disabling the desktop composition usually keeps the emulator from hitching like it does on ePSXe. However it doesn’t seem to be as important to Retroarch cores as it is to other emulators. I think the OP’s issue might be tied more to V-sync than anything since I’ve had a run in with V-sync on the latest Mupen core.
Please use the “frame advance” feature in RetroArch while playing Mario 64. Press “P”. Then hold the jump button and while holding it press “K”. How many times do you have to press K until you see Mario reacting (the first frame where Mario actually leaves the ground)?
If it’s 5 or 6 presses then you have higher input lag than normal. You can reduce it to just 1 or 2 if you disable frame buffer emulation but you shouldn’t have to do that. Frame buffer is needed for accurate results and it’s something the N64 does but the emulation has issues that cause higher input lag than normal.
You can’t test input latency like that. What you’re seeing is not representative of what your input latency actually is. Turning off frame buffer emulation skips frames. That’s why the frame rate is so jumpy when it’s not on and why you see Mario jump within less frames when you use that method. I tested other cores like Nestopia, QuickNES, SNES9X, and BSNES Balanced using this method and guess what I found. Complete parity between every core. Both Nestopia and QuickNES under this method showed Mario jumps after 2 frames in Super Mario Bros. Both BSNES and SNES9X show Mario jump in 3 frames in Super Mario World. I tested other games too like Space Megaforce for Super Nintendo and both SNES and SNES9X showed the ship move in just 2 frames. Now, SNES9X with GPU synced frames set to 0 and a frame delay of 14 factually is quicker than BSNES balanced with a GPU synced frames at 0 and a frame delay of 5. However with your test method they are the same. So on to the N64. Mario jumps in 5 frames most of the time. Sometimes he jumps on the 6th frame too. If you think Banjo Kazooie feels unplayable, fire up Quake II or Turok 2 for N64, then you’ll know what unplayable feels like. Not all games feel like they should. Input lag on Quake II feels almost like a full second after input! However Perfect Dark feels great. N64 emulation is a different animal.
That’s what i’m saying. N64 emulation has issues with input lag or needs too many frames in some games to do an action. Probably the ones that use the frame buffer a lot?
My point is that on the real N64 this isn’t as bad. I’m just pointing this out because many people assume it’s fine and those same delays exist on the real N64. Since i have a N64 i can assure you those delays aren’t there. Maybe there is some input lag but i highly doubt Mario needs 5 or 6 frames to jump on the real N64. I played the game to death on the real machine, on the emulator it feels completely different and sluggish. Ι don’t know how to measure it but i can feel it. And that’s even when i’m emulating the game on a CRT PC monitor. On the LCD it’s literally unplayable even with game mode ON. I have to press the jump button before Mario lands to do the triple jumps. This isn’t how the game should work.
Acknowledging there is an issue may result in a fix someday. But if people think it’s normal then it will never happen.
I don’t think anyone assumes that it’s fine. It’s just the way it is right now since N64 emulation development has been dormant for years and hasn’t really had any massive breakthroughs until the whole Angrylion CPU rendering came along. Remember that these emulators are written by people who are passionate about preserving video games and have the know how to do so, but these people most of the time have jobs and alot of times front their own money to create these emulators with no commercial gain to help recover those costs like Byuu (creator of BSNES). From what I understand there is still alot that is not known about how the N64 works and I’ve heard that Nintendo wanted it that way to prevent piracy which is completely believable. The N64 isn’t like most emulators today where it seems that if one game works on it, they all will work on it for the most part with only minor or no bugs. N64 emulation is like one hack piled on top of another hack from what I’ve heard. The authors of N64 emulators pretty much have to tweak the emulator on a game by game basis and/or provide the user with the tools to be able to tweak the emulator. Ever notice how many plugins N64 emulators have? There’s not one plug in that’s a magic bullet for all games other than Angrylion using the software rendering and it’s much more demanding on a CPU. My computer buckles under the software rendering for N64 so I have to use emulators like Mupen64Plus and hope it will run games decently. What I’m saying is give it time. You’re not the only who notices the inconsistent input lag on N64 emulation between titles. I assure you it’s being worked on.