search

libretro / LRPS2

GNU General Public License v2.0
166 stars 48 forks source link

2 additional frames of input lag #33

Open Tatsuya79 opened 3 years ago

Tatsuya79 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

covey-j commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

I think the proper way to go about the VsyncQueueSize setting would be to backport https://github.com/PCSX2/pcsx2/pull/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.)