Framedelay and v-sync performance

[Dr.Venom]

With regards to the upcoming framedelay feature I was thinking whether it is possible to include some statistics on frametime in either the visual overlay or through the log? Just to get a quick and objective number on what value of framedelay would be "safe".

Just for juggling some thoughts, possibly a "-benchmark" shell option could be an option? For example it would run a game unthrottled for a certain amount of "Amiga time" minutes (realtime would thus be much shorter) and spit out the average frametime, maximum frametime and suggested "safe" framedelay value. Or deluxe version that spits out real statistics like a normal distribution of frametimes? E.g. "fs-uae hybris.adf -benchmark 10" would return something (in the log) like this:

- 90% of frametime < 4ms
- 95% frametime < 6ms
- 99% frametime < 8ms
- 100% frame < 10ms

and/or directly translating these to suggested "safe" values for framedelay? (or how it will be called in fs-uae )

On another thought, a visual cue could be an option? When enabled it would flash the overlay screen red when vsynced is missed. I.e. when the framedelay value is set to tight, the user is warned visually by the red flashes. Thinking of it, I guess there would be some benefit to it, as it is something which you could always have enabled (without it being intrusive but still realtime feedback), warning you also in edge cases in longer game playing sessions...

The end goal would of course be to make it simpler for an average user to quickly find confirmation of what values for framedelay would work without causing issues (even though as we discussed it will probably always remain a "pro user" option).

From my experience with GroovyMAME, I generally have it set to a "safe" value of 7 (meaning input response is improved by 7/10th * frametime). And I only for specific games /systems set it to something lower or higher. My hunch is it may be the same for fs-uae, that with some testing it's possible to settle on some "safe" vale for the lot of the games, which will provide the input latency benefit, without causing any underlying issues.

Anyway, would love to know your thoughts on some form of statistics feedback.

[FrodeSolheim]

Here is a test build with support for the frame_time option (Windows only):
http://fs-uae.net/devel/2.9.7dev4/

To allow 9 ms for emulation (before v-sync) use frame_time = 8
(this example implies a 11 ms wait for 50 HZ Pal and 7 ms wait for 60 Hz NTSC).

I'll probably not implement a benchmark mode for frame time statistics any time soon.

There are counters in the Ctrl+F10 overview which shows missed and/or duplicate frame counts. And, a missed v-sync will also appear as a spike in the fps graph!

But of course, it is a bit annoying to have the Ctrl+F10 overlay open, so an alternative indication of missed v-sync is not off the table...

[Dr.Venom]

Originally Posted by FrodeSolheim

Here is a test build with support for the frame_time option (Windows only):
http://fs-uae.net/devel/2.9.7dev4/

To allow 9 ms for emulation (before v-sync) use frame_time = 8
(this example implies a 11 ms wait for 50 HZ Pal and 7 ms wait for 60 Hz NTSC).

Thanks. I found some time for proper testing but unfortunately it doesn't work as expected.

Before starting the measurements according to the method mentioned in the Input Latency Measurements thread ( http://eab.abime.net/showthread.php?t=88777 ) I first checked whether it does "something", e.g. when using "frame_time=9" by looking at CTRL+F10. There I can see the yellow bar being much bigger for lower values of frame_time, so at least it seems to do "something" / add a wait.

I'll first post the results using the Turrican2 "jump" test (see the mentioned Input Latency thread).

Turrican II jump
Real Amiga 500: 2,2 frames

FS-UAE 2.9.7-dev4 without frame_time: 4,2 frames

The result is the same when using finish-swap-finish or finish-sleep-swap-finish for the video sync method. As such at default setting FS-UAE is about 2 frames behind a real Amiga when using the Turrican 2 "jump" test.

Now for the results using frame_time=9 (about half frame wait) and frame_time=5 (wait is further extended). Note that both audio and video are without any issues and CTRL+F10 is completely smooth / no skipped frames in both cases:

FS-UAE 2.9.7-dev4 frame_time = 9: 4,3 frames
FS-UAE 2.9.7-dev4 frame_time = 5: 5,4 frames

One would expect the input latency to be decreased proportionally to the framewait inserted. So with frame_time= 9 the expected result would have been ~3,7 frames and with frame_time=5 the expected result would have been ~3,5 frames of latency.

On the contrary the result for frame_time=9 is unchanged from not using frame_time and using frame_time=5 actually adds a full frame of latency! (Note: video and audio were completely smooth, and CTRL+F10 was also completely smooth without frame skipping).

Conclusion for now: the current framedelay implementation does not work as intented, more on the contrary is has either no effect or makes things worse.

I can only guess as to possible causes:
- it almost seems as if the framedelay wait is inserted after input is acquired, so there would be no benefit by design apart from shortening the window for frame emulation
- or maybe input updates from the system are blocked during the framedelay wait function?

But then you wouldn't expect it to add a whole frame of latency when using low values for frame_time (when video and audio are still smooth and CTRL+F10 shows no frame skipping or the like).

Maybe you have a clue...