At present, this core has entirely broken frame pacing. The core reports a fixed refresh rate of 75Hz to the frontend, but the Lynx (and the internal emulation code) has a variable refresh rate of 0-75Hz; games can render at any rate they please. In retro_run(), the Lynx is always emulated until the next 'end of frame' event occurs - if a game renders at e.g. 25 fps, this means retro_run() will actually correspond to (1/25) seconds worth of Lynx runtime instead of the expected (1/75) seconds. In this case, the game is emulated too quickly - but it appears to run at the correct speed in the frontend because the core uploads an 'oversized' audio buffer (1/25 seconds worth of samples). RetroArch syncs on audio in such a way that when too many samples are received, the frontend runs in 'slow motion' - so the 'too fast emulation' + 'too many audio samples' effectively cancel out. But the results are awful. This is a significant violation of the libretro API, and it destroys the frontend's ability to properly synchronise audio and video, and to pace the frames correctly.
This PR modifies the run loop such that a fixed number of CPU cycles are emulated on each call of retro_run(), corresponding to the actual frontend output video refresh rate (which can be set via a new Video Refresh Rate core option). Thus the Lynx is always emulated at the correct speed, audio is always uploaded in batches of the correct size, and generated video frames are captured and output when available (and when the frontend can accept them).
The default Video Refresh Rate has been set to 60Hz, which provides smooth results for most games (and also eliminates screen tearing on 60Hz displays, which was an issue when the core only reported a 75Hz refresh rate). If a game has a higher frame rate than this (rare, but e.g. the intro and menus of California Games run at the full 75 fps), then 'excess' frames will be dropped. Users with 75Hz+ VRR displays can set higher refresh rates to improve video smoothness in these cases.
At present, this core has entirely broken frame pacing. The core reports a fixed refresh rate of 75Hz to the frontend, but the Lynx (and the internal emulation code) has a variable refresh rate of 0-75Hz; games can render at any rate they please. In
retro_run(), the Lynx is always emulated until the next 'end of frame' event occurs - if a game renders at e.g. 25 fps, this meansretro_run()will actually correspond to (1/25) seconds worth of Lynx runtime instead of the expected (1/75) seconds. In this case, the game is emulated too quickly - but it appears to run at the correct speed in the frontend because the core uploads an 'oversized' audio buffer (1/25 seconds worth of samples). RetroArch syncs on audio in such a way that when too many samples are received, the frontend runs in 'slow motion' - so the 'too fast emulation' + 'too many audio samples' effectively cancel out. But the results are awful. This is a significant violation of the libretro API, and it destroys the frontend's ability to properly synchronise audio and video, and to pace the frames correctly.This PR modifies the run loop such that a fixed number of CPU cycles are emulated on each call of
retro_run(), corresponding to the actual frontend output video refresh rate (which can be set via a newVideo Refresh Ratecore option). Thus the Lynx is always emulated at the correct speed, audio is always uploaded in batches of the correct size, and generated video frames are captured and output when available (and when the frontend can accept them).The default
Video Refresh Ratehas been set to 60Hz, which provides smooth results for most games (and also eliminates screen tearing on 60Hz displays, which was an issue when the core only reported a 75Hz refresh rate). If a game has a higher frame rate than this (rare, but e.g. the intro and menus of California Games run at the full 75 fps), then 'excess' frames will be dropped. Users with 75Hz+ VRR displays can set higher refresh rates to improve video smoothness in these cases.