@RealNC well… 5 ms is less than a third of a frame, I guess at the moment I don’t think is worth the effort for me.
And to be fair I can’t complain much about input delay: from a (very, very rough) test DoDonPachi (with 1 frame of run-ahead) gives me about 2 frames of delay (button press to animation). But some other games are not that responsive (some dreamcast games for example) and I was hoping that maybe I could shave a couple of frames with a CRT…
Thanks for the answer!
What video driver are you using? If gl or glcore, are you using GPU Hard Sync set to 0? If Vulkan, are you using 2 max swapchain images? Are you using exclusive fullscreen? How about frame delay? Depending on your setup, you may be able to shave at least one more frame off.
Depends:
with fbneo I use GLcore with Hard GPU sync ON, Auto frame delay ON and framedelay 0.
with flycast Vulkan with Max swap chain 2, Auto frame delay OFF and framedelay 0.
Always exclusive fullscreen and v-sync ON (tearing is not for me and I don’t have a gsync/free sync monitor).
Polling behavior I let it default (late), is there a way to understand witch is better (early, normal, late)?
As I said fbaneo with run-ahead is very responsive and no complains, with flycast is more a game by game case. for example Ikaruga feels good while mars matrix not so much…
I assume you are not using a default value of run-ahead with fb-neo. Some games have zero frames of lag themselves so dunno how run-ahead would affect them, negatively.
Also, i have no idea how the polling option works, i never managed to feel a difference.
@GemaH I set run-ahead for each game (when needed) using the pause + frame advance method .
But, as I said, fbneo does not have any lag-related problems.
It removes frames. The frames don’t have to be input lag frames. Run-ahead removes frames regardless.
So for a game that doesn’t have internal input lag, you’re removing normal frames, and this results in a stutter/hiccup because of the removed frames every time you input something. The animation in the game jumps ahead. Use a very high value for run-ahead and it will become obvious what it does.
I feel Super Street Fighter 2 Turbo has a really noticeable input delay. With max swapchain to 2, it seems that MAME has a bit less input delay compared to FBNEO, if I turn runahead ON and set it to 3 and preferably 4, I see no animation cut and the control is much more responsive, I can really play without making mistakes this way, 5 is spot on but it cuts a few frames here and there. Without an original cabinet it’s hard to tell, but I remember ports like SFA3 Max for the PSP and Metal Slug XX, which seem to have some kind of emulation layer on real hardware, making the input delay really apparent, the DS port of Metal Slug 7 plays better and it’s probably the original game while the PSP is a port, though I could be wrong. Overall, other systems, such as PS1, 3DO, Genesis, SNES etc play really fine without runahead and max swapchain to 2, but arcade games sometimes feel ‘heavy’ without it ON. I’m starting to wonder if real hardware has a heavier response to controls and we’re getting used to features which enhance gameplay or if there’s real lag here that can only be solved with runahead?
IIRC, SF2T indeed has 4 frames of internal latency, so you’re wiping out all of that. I suspect that’s probably overshooting a bit, as most people’s setups are only 1-3 frames behind hardware before runahead.
It makes sense then, the game feels ‘heavy’ without runahead. It seems that 4 is the sweet spot for me, I see no cuts in animation, maybe it’s because there’s at least an added frame lag added by the core? It’s bad design, in my opinion, this and a few other games with such delay suffers quite a bit and it’s hard to adjust to it, specially since even console ports like the SNES and specially the Genesis ones feel so much smoother without runahead, much more, in fact.
You can easily count the number of frames of delay a game + core has by testing, for example, an attack on Street Fighter 2 frame-by-frame. By default, the key for that on RetroArch is “K” for frame-step and “P” for pause.
The core’s lag should ideally be zero frames. I don’t know any core that ads input lag other than a very old version of bsnes/higan, but there might be some.
Also, don’t forget some games have a different number of frames of lag depending on where you are in the game. For example: MegaMan 2 has 0 frames of lag on the menu, but 1 during gameplay.
Furthermore, you can test the whole chain’s input lag if you have a somewhat modern smartphone and film yourself pressing the button at slow-motion. That’s how I did my measurements here: An input lag investigation
I believe I’ve read the other threads, yours too. It’s mostly about ‘feel’ though, the thing is, maybe users like me became spoiled and it would be hard to go back to original hardware, depending on the game.
“feel” is a very treacherous thing. There’s nothing better than a cold hard “scientific” measurement, like a smartphone slow-motion camera.
That said, you’re right. If you became accustomed to run-ahead, going back to real hardware will be a downgrade and games might feel less responsive.
I agree, though at school I was never much into numbers, I’m not too technical, but I won’t argue this would be the right approach here. There are a bunch of systems I think play really fine without runahead and max swapchains to 2, those games which ‘feel’ more unresponsive, like Hunter said the original SSF2T has 4 frames of input delay, that’s too much. It really makes it almost unplayable, if I go back to SSF2 on the Genesis, as well as its MK ports, the controls are much more responsive. I also remember reading somewhere that the Naomi version of SFZ3 Upper suffers from delay too, compared to the original CPS2 board, I’m not sure where the line is drawn when devs take into account multiple hardware, but they’re not consistent throughout, it would be a stretch to say that 4 frame input delay is intended, when other versions it does not occur.
Don’t forget modern screens add additional input lag versus a CRT. Also, there is additional input lag on the system (controller pooling, graphics driver processing, etc) that might be big or small and don’t exist on the original hardware.
Also please note that setting swapchain to 2 images does not guarantee that 2 images are used. You can check how many images are really used by looking at the log when starting RetroArch from a command line.
When you play native PC games, source ports, etc and start to notice some unresponsiveness only in a few cases, such as specific games inside emulators, then I think it’s safe to say that while still accountable, TV/monitor, OS and other aspects could indeed have an influence there, I’m pretty sure we’re talking about internal input lag and possibly something with the added emulation complexity. About the swapchain, I did notice that heavier cores start to chop when in 2, such as Bettle Saturn, when I set it to 3, then it runs fine, same with other cores such as Opera (3DO) and Swanstation, when overclocking them, depending on what’s going on, it drops frames and the sound chops, setting it to 3 solves that, otherwise, it seems to work fine for other cores.
Yeah that is natural. 2 swapchain images don’t allow for the CPU and GPU to work in parallel, so frametimes are higher.