Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2 additional frames of input lag #33

Open
Tatsuya79 opened this issue May 21, 2021 · 10 comments
Open

2 additional frames of input lag #33

Tatsuya79 opened this issue May 21, 2021 · 10 comments

Comments

@Tatsuya79
Copy link

There's 2 additional frames of input lag in the libretro core vs stand-alone.

Tested in Gradius V, opengl in stand-alone (with "input record" frame advance feature), glcore in RA, win7 x64.

@Ryunam
Copy link

Ryunam commented May 21, 2021

Here we go again... :/ Do you think it might be due to the polling being called at the wrong time, as with other cores in the past?

@Tatsuya79
Copy link
Author

Could be that, could be end frame timing, could be both.

@covey-j
Copy link
Contributor

covey-j commented May 31, 2021

Could PCSX2/pcsx2#4115 have anything to do with it? It slightly reduced input lag in standalone, but hasn't been backported to the core. Not sure if that'd account for 2 additional frames, though.

@Ryunam
Copy link

Ryunam commented May 31, 2021

Maybe, if @Tatsuya79 was testing the latest standalone nightly, then perhaps the latency reduction caused by that commit should be taken into account. Otherwise, it is something that is specific to the Libretro implementation.

@Tatsuya79
Copy link
Author

I probably tested before that already in the past.
But anyone is welcome to test, I can't compile the core with msys2.

@covey-j
Copy link
Contributor

covey-j commented Jun 1, 2021

Did some quick testing in Gradius V. Here's what I found:

First, I was able to replicate the 2 additional frames of input lag vs. a recent build of the standalone. I got the same result when trying a build of the standalone from just prior to the initial libretro port. So it's something specific to the libretro implementation.

The PR I mentioned adds the Vsyncs in MTGS Queue setting to the standalone's config menu. This setting is actually already accessible to the libretro core via the PCSX2_vm.ini file. Setting VsyncQueueSize = 0 eliminated those two extra frames of input lag. Bizarrely, this setting had no effect in Gradius V in the standalone.

@Tatsuya79
Copy link
Author

Tatsuya79 commented Jun 1, 2021

Indeed setting VsyncQueueSize = 0 is working, now 5 frames to react in Gradius V, 3 in Thunderforce VI in RetroArch.

Stand-alone doesn't show the effect of that setting change with their frame step method indeed...
It's always so hard to do comparisons.

I wonder if we should set it to 0 by default in RA, if it has any impact on perfs here.
edit: yeah it seems faster with 2, like 20% on the min framerate in thunderforce.

@Immersion95
Copy link

Immersion95 commented Jun 19, 2021

The VsyncQueueSize = 0 doesn't work anymore and is overwritten after each boot. I tried to make it read only but another temp file is written then.

@covey-j
Copy link
Contributor

covey-j commented Jun 19, 2021

The VsyncQueueSize = 0 doesn't work anymore and is overwritten after each boot. I tried to make it read only but another temp file is written then.

There's no official support for manually tweaking the .ini files in system/pcsx2/inis. These files will eventually be phased out as part of #49, so expect .ini tweaks and workarounds to break over time. Currently, the core still relies on the .ini files to function properly, so I strongly discourage making any of them read-only. That can potentially cause problems such as downgraded performance and certain core options not working as intended.

@covey-j
Copy link
Contributor

covey-j commented Jun 19, 2021

I think the proper way to go about the VsyncQueueSize setting would be to backport PCSX2/pcsx2#4244 so that the setting is unaffected by speed hack presets, then expose the setting as a core option (probably under a different name than "VsyncQueueSize" since camel casing looks pretty bad in UI. I forget exactly what standalone calls it in their GUI, but we should probably go with that.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants