# Framerate limitation

The most successful competitive game engines like id Tech, GoldSrc, Source and such allow for framerate limitations.

You can play with 30, with 60, with 99, with 72, with 68 etc. In short, you can cap it and control the cap.

I was wondering, how do I limit the framerate?

Not interested in code, but theory.

• Just out of curiosity, what's the point in this other than freeing up cycles for other processes? – 3Dave Jun 14 '12 at 14:52
• @DavidLively, Think about laptops, those overheat very easily on a very high frame rate, while with a cap of 60fps (more is useless anyway, even 60 is a bit much, 40 should do) they can control the temperature much better. – user17139 Jun 15 '12 at 9:40
• For competitive gaming it's best to have an even frame rate instead of spikes between 60 and 100 fps since sometimes some actions are frame rate dependent and not time dependent, an equal frame rate lets you get a feel for these actions. Btw note that if you enable VSync your game always has a max fps equal to your refresh rate because (the driver takes care of this). – Roy T. Jun 15 '12 at 9:50
• gafferongames.com/game-physics/fix-your-timestep – Prof. Falken Oct 24 '12 at 21:24

## 2 Answers

The theory is: Check when you last rendered a frame, and if it's not time to draw another frame yet, then don't, and wait until it is.

Say you want to limit your framerate to 60fps, that means that every frame has a render time of 1/60s = 16,67ms (rounded)

To limit your frame rate you just check the time at the start of your game loop, you can then compare it with the time at the end of the game loop: if the difference is less than 16.67ms you should stall for that time.

One way to do this is to use:

sleep(waittime)


However since sleep(x) yields the thread for a minimum of x miliseconds you don't know for certain if you will get control back in time.

A better way would be to use:

while(timediff < 16.67ms){ sleep(0); }


This yields the thread and requests control back as soon as possible.

Another solution is to just have a busy wait loop, this gives you the best control but uses the CPU needlessly.

Remember that the OS scheduler can always take away control from your thread so be prepared for some fluctuation.

• "1/60s" to be clear. :) – Richard Marskell - Drackir Jun 14 '12 at 14:40
• This solution is really bad. If you have vsync enabled or the OS decides to do stuff, your framerate will fluctuate a lot. – Tara May 14 '16 at 19:01
• @Dudeson Why is it bad? (this is the technique used in Quake3 btw). If your FPS is lower than 60 the loop just gets skipped. So it keeps your FPS as high as possible but never above 60. – Roy T. May 16 '16 at 17:05
• @RoyT. Interesting... Where did you get that info from? From the source code? Also, I'm saying waiting in a loop is bad because that's exactly how I did it in my engine and it causes me a lot of pain. The problem is, when you turn on vsync (in the GPU driver) you get a lot of frame drops if you additionally try to limit the frame rate in your code, because your timinig won't be perfect every frame. I'm just talking about vsync issues. Without vsync this is not an issue. And I'm not sure if vsync was the same kind of deal in the Quake 3 days as it is today. – Tara May 16 '16 at 21:07
• @Dudeson someone else pointed that out to me some time ago because I was worried about the busy waiting and sleep. I see now that you can fluctuate between 30fps and 60fps when v-sync is on if you slightly miss it. But I guess that happens with any technique (isn't this what FreeSync tries to alleviate). A limited framerate by code, or because your computer can't render at 60fps will always have this problem I think :) – Roy T. May 17 '16 at 10:03