Open vanfanel opened 2 years ago
Anything different from https://youtu.be/6n1ZEO9abDU ?
Anything different from https://youtu.be/6n1ZEO9abDU ?
Hi! Well, there's no possible way a youtube video can show precise framerate, since there's youtube compression, framerate, and playback software in the middle, while flycast renders the graphics in realtime using my local GPU.
Also, that video is 5 seconds long: hiccups can take way more seconds to happen.
This video is short but it's 60 FPS and the compression shouldn't be a problem given the resolution.
FYI Flycast doesn't do any kind of internal framerate pacing and lets the game in full control so there's nothing to tweak there.
Having a duplicate frame every couple of seconds or so is what I consider normal. If you have more than that you should look at your settings.
Having a duplicate frame every couple of seconds or so is what I consider normal. If you have more than that you should look at your settings.
Hm, I would say that those duplicate frames is what I call hiccups :) So yes, I mean these.
Why is that normal? I mean: that shouldn't happen (it certainly doesn't happen on a Dreamcast) and it's perfectly possible to force emulation to sync with the host rate.
For example, Redream doesn't show that behaviour.
@flyinghead I have also noticed that the Libretro builds have the exact same behaviour (ie: erratic hiccups every few seconds). So I believe it's emulation speed, which could be made to match the host refresh rate with an option. Many emulators do this (in Retroarch, almost every core does this).
Sounds like a duplicate of #520
@flyinghead I have also noticed that the Libretro builds have the exact same behaviour (ie: erratic hiccups every few seconds). So I believe it's emulation speed, which could be made to match the host refresh rate with an option. Many emulators do this (in Retroarch, almost every core does this).
Hmm..... I have flycast on retroarch for my Android phone and don't have any hiccups on the 240p test suite with the Sonic the hedgehog scrolling test. You might want to redo your estimated refresh rate in retroarch video menu. Then go to audio latency and go lower step by step, for example 96 then 64 till video hiccups go away.
@71knight I have very little deviation on my estimated screen refresh, like 0.2%.
I have reported issues like this many times before on different cores, and I have been told silimar thins ("I can't see it", etc), and then, years after that, more people notices and a fix is done.
Sync to host refresh and duplicate frames should be available on all emulators. Not just for one renderer either.
Going back to this, RetroArch core is perfectly smooth with 60FPS games, and with 30FPS games if "Full Frame Buffer Emulation" is activated.
But with standalone Flycast, there's no way to achieve perfect movement with 60FPS games, with a duplicate frame every couple of seconds or so as @flyinghead said. Wouldn't it be possible for the games to sync to host refresh? Works for PPSSPP and PCSX2: both have that setting and there are no duplicated frames. I would add such a setting if I knew how...
However, if the core runs on Libretro, it means it can sync to external refresh rate! So it should be easily doable, shouldn't it @flyinghead ?
Platform / OS / Hardware:
Debian 11 GNU/Linux
Github hash: 2319a00c4f5b2b89d030e8e499baf85d62da2c6b
Hardware: x86_64, Vulkan API 1.1. Device AMD RADV STONEY (ACO)
Description of the Issue
Internal framerate seems to differ from host physical framerate, resulting on small hiccups in framerate, even on ~60Hz screen and with VSYNC set ON.
It can be easily detected with the scrolling test in Dreamcast 240p test suite available here: https://artemiourbina.itch.io/240p-test-suite/download/eyJleHBpcmVzIjoxNjUzODI0ODA1LCJpZCI6OTY5MjE3fQ%3d%3d%2eBElnDYkoxUC4pyZlF7lvoK4dEMo%3d
Debugging Steps Tested
Simply try the Dreamcast 240p test suite, enter the scroll test, and observe scrolling smoothness for a while.
Logs Gathered
My personal guess here is that the emulator regulates the framerate internally, instead of relying on the vsync. When vsync is ON, the emulator should NOT regulate speed internally: it should run "as fast as possible" and vsync will limit the speed. An option for this could be the solution if I am right on the internal speed regulation guess.