You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently in SDL we do event polling in bursts each frame on the emulator main thread, which means that events will arrive in bursts at each "frame border" rather than asynchronously during gameplay. This likely is another cause of input lag, especially in 30hz games. #17685
Instead of polling for events every frame, we should just sit in a tight WaitEvent-loop, and have emulation and rendering happening on a different thread. This would be perfectly possible to implement with Vulkan and would be very similar to what we're doing on Windows.
However OpenGL comes with the complication that presentation has to happen on the same thread that created the context.
There does however seem to be workarounds that work:
Currently in SDL we do event polling in bursts each frame on the emulator main thread, which means that events will arrive in bursts at each "frame border" rather than asynchronously during gameplay. This likely is another cause of input lag, especially in 30hz games. #17685
Instead of polling for events every frame, we should just sit in a tight WaitEvent-loop, and have emulation and rendering happening on a different thread. This would be perfectly possible to implement with Vulkan and would be very similar to what we're doing on Windows.
However OpenGL comes with the complication that presentation has to happen on the same thread that created the context.
There does however seem to be workarounds that work:
https://skryabiin.wordpress.com/2015/04/25/hello-world/
But might simply not bother with improving lag with OpenGL for now.
The text was updated successfully, but these errors were encountered: