FpsManager – A C++ helper class for framerate independent movement

Update – September 2013: Fixed an issue whereby the enforceFPS function only returned the time it took to run the enforceFPS function itself because I forgot to add the frameDuration. Fixed another issue where I reset the frameCount to 1 when it should have been reset to 0. Oops…

I wrote only a few months back that I didn’t want to write another piece of FPS code, ever. But this was before I started taking framerate independent movement seriously. In my past coding I’ve just enabled VSync and been done with it – as long as the machine had enough processing capacity to perform at 60fps everything was fine, and nearly everything I wrote was so simple that it didn’t task the box too much.

However, as I’ve been working on a lot of Android code recently where the processing capacity of the device can easily vary by orders of magnitude, I’ve started thinking more that I really need to be able to cater to framerate changes gracefully. And for this, I’ve reinvented the wheel – if only to be absolutely sure in no uncertain terms about how the wheel frickn’ works.

So to put this to the test, I wrote the FpsManager class, and rewrote the camera from my old post on Simple OpenGL FPS Controls into a proper class suitable for reuse in multiple projects and capable of working in a framerate independent manner. That’s the next post…

…first things first: The FpsManager! ;-)


Comments? Suggestions? Think I’ve designed it badly, or quite well? Know why it works just fine (from a usability standpoint) but provides a framerate just under that requested?

Feel free to let me know in the comments below! Cheers! =D

7 thoughts on “FpsManager – A C++ helper class for framerate independent movement”

  1. Pretty cool implementation! I prefer less variables (smaller memory impact), and only use GL.h+GLU.h (With WinAPI)…
    Though this is VERY readable, and would be easy to debug (if as unlikely as it sounds, and error does occur)!

    Though counting the frames passed bothers me often, it really is the only way to accurately force a specific FPS
    (one that isn’t divisible without a remainder by 1000 – the number of milliseconds in a second)!

    This is how I usually do it (unless I need 100% accuracy):

    for (;;) { // Unconditional “for”!

    const DWORD StartTime = GetTickCount();

    if (PeekMessage(&Msg, NULL, 0, 0, PM_REMOVE)) {

    if (Msg.message == WM_QUIT) break;




    while ((GetTickCount()-StartTime) < 17) // (16 = floor(1000/60) – 1000 MS – 1 SEC)
    Sleep(1); // Make the game run at 60 FPS (iterations a sec)


    Thank you very much for publishing this :)

  2. Hi Mitch and thanks for your post!

    I like your method, it’s minimal yet functional =D

    One of the problems I’ve been finding with fps limiting though is that calls to glfwSleep cause a sleep time which is amazingly innacurate! It’ll oversleep or undersleep like crazy! Although the time is very, very accurate the sleep period is really very ballpark… For example, I might ask to sleep for around 2ms – and then I sleep for like 19ms (more than a frame over!) – it’s killing me!

    So in an effort to see what I can do about it I’ve been playing with code that compensate for oversleeping.

    For example, let’s say I want to run at 50fps (25ms per frame) just to keep the numbers simple:
    – If a frame takes 12ms to complete, I should sleep for 13ms (i.e. 25 – 12 = 13ms),
    – So I attempt to sleep for 13ms, but I actually sleep for 19ms, so I’ve overslept by 6ms
    – Next frame, lets say it takes 11ms to complete, then I should sleep for 14ms (25 -11 = 14ms),
    – BUT I already overslept by 6ms, so I should really only sleep for 8ms to compensate (14 – 6 = 8ms)
    – and so on!

    I’ll post something up on it soon once I’ve had more time to try different ways of addressing / working-around the issue.


    1. Yup, that’s a problem alright. There’s a lot of nice things about GLFW3, but I feel timing helpers to assist in running your main loop should be available for use.

      Instead of using glfwSleep, maybe try using usleep, or nanosleep or use Mitch’s method via getTickCount() in the comments above.

Leave a Reply

Your email address will not be published.