Fix GLUT thread to redraw at an accurate 60 FPS. #474
Conversation
mkilgore
requested review from
grymmjack,
SteveMcNeill,
a740g and
RhoSigma-QB64
|
@a740g Maybe, but the What would probably be a good idea is replacing |
Since the GetTicks() is visible in the logging, it's useful to have it start from zero rather than an arbitrary number.
Currently the GLUT thread draws the screen too slowly, Ex. The default is supposed to be 60 FPS, but it will always draw a bit slower than 60 FPS. This is because the current logic simply inserts delays for the entire length of a frame, not taking into account how long it took us to render the last frame. The new code uses GetTicks() to measure how much time has passed since the last render, which then lets us calculate the exact amount of delay until the next frame. We additionally then measure how long the delay lasted vs. what we asked for (since any delay we do only has a minimum guarentee, it will ocassionally last a bit longer) and adjust based on that as well. The result is a perfect 60 FPS as long as rendering is quick enough. If the rendering falls behind (Ex. a slow _GL SUB is in the program) then we'll start skipping frames to get back on track. Fixes: QB64-Phoenix-Edition#408
|
@mkilgore will this fix the stuttering that I shared here: Thank you for this contribution regardless! <3 |
I think it should. Thank you @mkilgore for fixing this! You should really push the merge button now. 😁 |
Like @a740g said I think it should probably fix some of it, you should see it move at 60 FPS after this. Some of the stutter will be due to syncing between the QB64 thread and the rendering thread and that's not addressed by this. #409 would be a complete fix for that but will also require some level of code modification to use. |
Currently the GLUT thread draws the screen too slowly, it is supposed to
default to 60 FPS but you'll always get a bit less than that. This is because
the current logic simply inserts delays for the entire length of a frame, not
taking into account how long it took us to render the last frame. Any time
spent rendering thus results in a slowed down FPS.
The new code uses GetTicks() to measure how much time has passed since
the last render, which then lets us calculate the exact amount of time
until the next frame so we can sleep for that amount. We additionally
then measure how long the sleep lasted vs. what we asked for (since any
sleep we do only has a minimum guarantee, it will occasionally last a bit
longer) and adjust based on that as well. The result is a perfect 60 FPS
as long as rendering is quick enough.
If the rendering falls behind (Ex. a slow _GL SUB is in the program)
then we'll start skipping frames to get back on track. This is behavior
may want to be talk about or perhaps make configurable, I went with
basically having it drop back to 30 FPS (and then 20/15/etc.) if the rendering
is too slow. The alternative would be that we just set the
deltaTickback to zeroand render as fast as possible.
The undocumented
_FPScommand can be used to change the speed from60 FPS to whatever is desired (with a cap of 200 FPS). This was always
true, but now it should be accurate to whatever you request.
Fixes: #408