Sure thing! But what test do you want me to do exactly?
What should I build?
Please build and test this RetroArch fork, and test with GL on Wayland:
Test for input lag improvements.
2 Likes
Alright! I’ll get back to you as soon as I can.
This might be a stupid question…
My video card have DVI-I output (the one with the “extra” 5 pins ) so I think it can natively output an analog signal, this will makes it easy to connect to a crt monitor (DVI-I -> VGA for example). The question is: will the crt pc monitor shave some input delay compared to my “normal” hdmi out to my ips monitor?
Usually the signal processing delay of monitors today is between 2 and 5ms. That’s the amount you’re looking to shave off with a CRT.
Of course your video card needs to actually output DVI-A, not DVI-D. “DVI-I” is just the connector type, and the actual signal is either DVI-A (analog) or DVI-D (digital.) DVI-I supports both, but the question is what does your video card output.
2 Likes
@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.
1 Like
@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.
4 Likes
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.
1 Like
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
1 Like
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.