I could find a reference to the pixel clock in flycast source libretro.cpp where it sets the VGA mode to 60Hz refresh rate or 59.94 for NTSC. I might be wrong but I thought Naomi/Atomiswave boards were 61.702586Hz? Is it currently running slower than supposed?
Not sure if Flycast deviates from the norm, but most cores will reclock themselves to run at your screen refresh rate. If you want to get the native speed of a core, you need to go to the “Frame Throttle” section in the RA settings and enable “Sync to Exact Content Framerate”.
That’s not how it works. Each core renders frames at (supposedly) the native system pixel clock. It’s then retroarch’s task to adapt it to screen refresh rate. Naomi currently on a 60Hz display -with audio_sync true- should be running slower than in the original machine, but I doubt it is since there’s no reference to system pixel clock in source, I’m asking if this is the case and doesn’t share the behavior of cores with accurate reported clocks like; bsnes, genesis gx plus, fbneo, sameboy…
I think this kind of aspects should be unified or at least notified in the docs, for example beetlePSX core clock currently is wrong, I think kronos is wrong too but I have to double check, to be honest I think I should revise now all cores since I have changed a few of them (and for peace of mind)
Framerate is not something that can be “adapted.” At least not when dealing with real-time generation of video frames (as opposed to viewing a video file.)
NES cores for example run at 60.8FPS with that option enabled, because that’s the native speed of an NES. RA will drop a frame about once per second on 60Hz (or 59.94Hz) displays. This shows itself as a stutter that occurs once per second. If you have a VRR display (g-sync or freesync), the monitor will change its refresh rate to match the core exactly and there will be no dropped frames. Or, if you configure your display to use 60.8Hz then it will also avoid the stutters.
If you disable this option (which is the default, since most people don’t have VRR displays), the core will instead run its emulation a tiny bit slower, so that it outputs at 60FPS instead (or 59.94FPS, if that’s what your display uses). As a result, games will also run a tiny bit slower. This is generally referred to as “reclocking.”
If Flycast respects this option, then it will behave in the same way. If you keep the option disabled, the emulation speed will be a bit slower to match your display’s refresh rate. If you enable the option, Flycast will run at original speed, but if you don’t have a VRR display or if you didn’t create a custom refresh rate to match, then you will get some stutter.
You can verify whether this is the case with Flycast by enabling the FPS indicator in RA. If it says 60FPS with the option off, but 61 or 62FPS with it on, then that means Flycast respects the option and runs at native speed with the option enabled, and at a slower speed with the option disabled.
adapted = synced? if that’s the case with a 60Hz refresh rate display then indeed the game runs slower, but I use modelines on a LCD so if flycast’s reported clock is 60Hz and my screen is set to 61.7Hz, the game would run faster (just tested feels/sounds fast). It’s certainly just guessing unless some developer confirms whats happening now within the core.
That’s not 100% true though, i think games clocked higher than 60Hz are actually rendered at 60fps in FBNeo. The “emulation speed” should be fine though.
Good to know, I only run CPS2, CPS3 and NeoGeo in fbneo, does that mean that on a 60Hz display games like tgm2 run smoothly at correct emulation speed? It might probably be the same case with flycast, if the board accepted VGA that kind of thing might be possible so no modeline is needed.
Does that mean they all stutter with no way to fix that?
I don’t hear any stutter in tgm2 & qbert. I’ll need to confirm with the team that they are running at the correct emulation speed though.
Edit : i confirm they are supposed to run at the correct emulation speed.