Jeff Slutter Oh my word! :-O

Game Loops and Frametime

Kwasi Mensah wrote a blog on #altdevblogaday entitled Game Loops on IOS that I skimmed through. I'm currently not dealing with game loops, frametime, nor IOS right now, so this post is just a little reminder for my future self should I find myself tumbling down that wormhole.

Glenn Fiedler's article Fix Your Timestep is the oft-referenced article on the topic for good reason, and is always worth another read through.

The summary for Kwasi's article:

• He has a function that gets called when there was a vsync
• If a vsync happens while he is in the function, the function will get called again immediately after it exits
• Most of the time you should be hitting 60 fps (or 30 fps) and occasionally your frametime might go over
• What you don't want is to spiral out of control if you occasionally miss a frame. If you are consistently missing frames than you should drop your goal frametime to the next level (60 -> 30)
• Start by timing how long it took to run the "DoFrame" function, call this time elapsed.
• If elapsed took longer than your goal frametime, then change the value of elapsed to your goal frametime plus how much you overran the vsync: fmod(elapsed,frametime)
• Store elapsed in a persistent variable, called bank, for the next call to "DoFrame".
• At the start of "DoFrame" subtract your goal frametime from the persistent bank variable.
• If bank is higher than zero, that means your last processing through "DoFrame" lasted longer than your goal frametime, and therefore, you missed a vsync (or more). In this case he suggests just forgoing the processing of "DoFrame" for this frame and just wait until the next vsync (the article explains why). So exit out of "DoFrame" until next time.
• Otherwise bank is less than, or equal to, zero. Which means that the last processing through "DoFrame" was quicker than your goal frametime (or, just as long). Reset bank to zero because we are starting a new, and do the processing of "DoFrame".

So, occasionally you'll have to eat some time to wait for the next vsync should you miss a goal vsync. But the idea is, if you don't, another vsync will come along, and if you miss that (as you are already under a sub-vsync interval of time remaining due to the miss) than you are going to throw off things even more. I guess this will cause a, probably unnoticeable, slow down in time for when you miss a vsync.

I have to give some thought to all of this, but until then...