libretro / LRPS2

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

Vsyncs in MTGS Queue option #76

Closed covey-j closed 3 years ago

covey-j commented 3 years ago

This came up in #33. By default, the MTGS renders a number of frames ahead to improve performance at the cost of increased input lag. The number of frames to queue is controlled by the VsyncQueueSize variable and is adjustable in standalone via the Vsyncs in MTGS Queue GUI setting.

Proper way to go about this would be to backport https://github.com/PCSX2/pcsx2/pull/4244 so that the setting is unaffected by speed hack presets, then implement the core option.

SeventySixx commented 3 years ago

Done! :-) Does this close also #33?

covey-j commented 3 years ago

Done! :-) Does this close also #33?

Thanks @SeventySixx! I'd say further investigation is needed on #33 before closing it, as there was a behavioral difference between the core and standalone IIRC when I originally tested the .ini setting.

In particular, the two additional frames of input lag in e.g. Gradius V occurred when both standalone and the core were set to the default VsyncQueueSize=2 setting.

Reducing this to 0 didn't seem to affect the input lag in standalone (at least in Gradius V; it might in other games), but did affect the core so that its input lag was the same as in standalone. It's unclear to me as to the reason for this, and given the performance penalty of setting this to 0, it's worth figuring out eventually.

One thing to note is that we are doing our input polling differently than standalone does. And we're handling MTGS slightly differently as far as the threading. It's possible, for example, that we're spending an extra two frames on synchronization. Not sure yet. It's something I'd like to look into when I revisit the project. Having the issue open would help me remember.