# Locked frame rate

I'm a little bit confused about the way game engines handle frame rate. Correct me if I'm wrong:

1. By my assumptions, usually we have a frame rate which graphical API runs by it and a frame rate called fixed frame rate which other parties like physics, network etc. run by it.

2. I know with v-sync on, the frame rate for graphical API would be the display device refresh rate which is usually 60hz in nowadays monitors, and with v-sync off graphical API wouldn't wait for display device to draw previous frame completely and it constantly sends the new frame. So, if I turn v-sync on and change refresh rate to something I like, then frame rate for graphical API would be locked by that rate and if I turn v-sync off, then frame rate for graphical API would be as fast as possible.

3. If my previous assumptions are correct, then why have we for example a Time.captureFramerate which locks the render frame rate and a Resolution.refreshRate with the same intention in an engine like Unity3D?

4. And, what does it mean when game developers say we locked the frame rate at 30 or 60 frames per second? Does this mean they leave v-sync on and set refresh rate to 30 or 60 and user is not able to alter v-sync at runtime?

If we are to limit the main loop which render operation runs under it, is this the way?

while (main_loop)
{
while (fixed_loop)
{
// Stuff
}

// Lock main loop to 30 fps
if (render_time >= 1 / 30)
{
render_time -= delta;

Sleep(1);

continue;
}

render();
}

• When game developers say that they locked the framerate they mean that their game doesn't work well with dynamic framerate. It can be performance (physics) or accuracy (AI) issue. Physics and AI components always have fixed framerate. If render component has fixed framerate that means that this game has some issues with it. It can be related with animation or particles components. But in ideal game render component shouldn't require fixed framerate. V-sync has no any relationship with locked framerate. – Kostya Regent Jan 15 '15 at 18:17
• @KostyaRegent So you mean they render inside fixed frame rate loop? – MahanGM Jan 16 '15 at 2:59
• Yes, that's what I mean – Kostya Regent Jan 16 '15 at 9:16
• @KostyaRegent Ok, and what is your opinion about my code example above? If I don't want to put render in fixed frame rate loop, can I use that if to lock render rate in main loop? Is this the proper way? – MahanGM Jan 16 '15 at 11:17
• Some game engines also have a distinct logic update, which runs slower than the render update and may be fixed-time-interval'd or fixed to a set number of renders (every other frame, every 3rd frame, etc). This approach is useful when renderers have enough information to be able to interpolate their coords/anim/etc. for the renders that happen when no fresh logic update has happened, or in systems that have multiple distinct areas to render to (think Nintendo DS with its dual screens). – Slipp D. Thompson Jan 12 '16 at 5:07

Usually game that claims they use locked frame rates, they are doing so by using a system timer in a thread that pulsates the game rythm like a metronome. The rendering thread will sleep on some condition variable waiting to be notified by this thread before calling Swap or Present.

This approach has many problems, like not being in good synch with the actual display, not interleaving well if vsynch is ON because of double waiting, which if everything runs smooth should compensate after the first frame, but every some thousands frames some stutter may happen. This is something that also depends a lot on the platform, depending on timer precision. On windows people use timeBeginPeriod and set it to 1, 2 or 5ms... the point is less than half of 16 is necessary.
http://msdn.microsoft.com/en-us/library/windows/desktop/dd757624(v=vs.85).aspx
Flash plugin does that (annoyingly). And most movie players.

Of course it is not so straightforward to have a game where each part is nicely decoupled, and refresh rate can drift freely between each part. They are possible but require great care from everybody, and mostly the higher level engine architects. This is not always buisness-friendly because of increased dev costs.

Also check that out:
http://gafferongames.com/game-physics/fix-your-timestep/

• I understand what are you talking about, but I'm confused because I can't find a pseudo example on how main loop can be limited. I've read the link you've provided many times, but it only talks about fixed loop which is not my question. I write an example in my question so to be clear. – MahanGM Jan 16 '15 at 5:04
• Typically if you wanted to limit your loop to a certain frequency (say 30 Hz), after each render you'd sleep for 1/30 seconds minus the amount of time it already took to complete that frame. However, since sleeping is quite imprecise, it's probably easier to just do a two refreshes per render to halve the render frequency. – jmegaffin Feb 15 '15 at 13:52
• @MahanGM you are right, the "fix your timestep" is not about display regulation, but it is about decoupling refresh rates of subsystems. Boreal good idea, though I don't recommend trying to control frame rate. Letting the user gets 1000FPS in 10 years is good manner. Or toying with VSync in his/her driver. Rendering engines should have free rates. I'm going to write a dontfixyourframerate manifesto one of these days. – v.oddou Jun 15 '16 at 1:11