Advice to lock frame rate

On any platform you could control the rate of update and render with this simple algorithm

float dt; //delta time in seconds

float clock; //last time sample in seconds

float render_timer; //time control for rendering

dt = 0.0;

render_timer = 0.0; //init the render timer

clock = getTime(); //API callback to get the current time in seconds

while(true) //game loop

{

dt = getTime() - clock; //get the current delta time for this frame

clock = getTime(); //updates the clock to check the next delta time

update(); //update stuff;

if(render_timer >= (1.0f/60.0f)) //checks if the frame is ready to render

{

render(); //render your stuff

render_timer -= (1.0f/60.0f); //do not set to zero, remove the accumulated frame time to avoid skipping

}

render_time += dt; //updates the render timer

}

I never understood why ppl would lock their framerate manually rather than letting vsync do it's job...

On any platform you could control the rate of update and render with this simple algorithm

...

Can somebody explain why this is downvoted?

On any platform you could control the rate of update and render with this simple algorithm

I think I'm doing pretty much the same:

#define FRAMERATE 60
int timererFps;

while (true)
    {
        timerFps = SDL_GetTicks(); // SDL_GetTicks() gives the number of milliseconds since the program start.
                                   // I initialize the timer.

        update(); //update stuff...

        timerFps = SDL_GetTicks() - timerFps; //I get the time it took to update and draw;

        if(timerFps < 1000/FRAMERATE) // if timerFps is < 16.6666...7 ms (meaning it loaded the frame too fast)
        {
            SDL_Delay((1000/FRAMERATE) - timerFps); //delay the frame to be in time
        } 
        render(); // render stuff...
    }

Am I not correct?

ps: I just noticed I was rendering before to delay, I correct it, now I'm around 58fps.

I never understood why ppl would lock their framerate manually rather than letting vsync do it's job...

Because I don't know how to enable vsync with SDL2 I didn't see such thing.

I think I'm doing pretty much the same

I think yours and eduardo's are different. Your algo will update, render and wait some time as filler to make it 16 millisec per frame (1 update per render with waiting), while eduardo's will update multiple times until 16 millisecs or more has passed before rendering (one or more updates per render without waiting).

For more information, look at the article Fix your timestep! on the internet, it talks about various kinds of game loops.

Ah thank you I understand the difference, so are they equivalent or the one of eduardo is better to implement?

Because I don't know how to enable vsync with SDL2 I didn't see such thing.

I never used SDL, but judging from that post and my opengl experience, i guess you didn't use double buffering. Double buffering will remove any tearing effect on fast moving scenes, and lock your framerate for you as a bonus by default.

Ah thank you I understand the difference, so are they equivalent or the one of eduardo is better to implement?

With frame based movement, they are most definitely NOT equivalent. Quite the opposite, actually. Multiple updates will cause multiple frame-based moves in a single 'frame'. With frame based movement, you want only a one to one ratio of updates and renders.

Your fps fluctuations are possibly due to the precision of SDL_GetTicks, which is inadequately documented. The precision of this call is platform dependent, but may be as poor as 10ms, which would prevent you from precisely locking down your framerate. Even at it's documented 1ms accuracy you'll have trouble precisely locking down your framerate as the difference between 60fps and 65fps is only a bit over 1ms (16.66ms per frame vs 15.38ms per frame).

The real solution is to take the time and learn time based movement and get away from frame based movement. Otherwise, look at using a sub-ms resolution high performance counter, which is going to be very platform dependent. On Windows, look at QueryPerformanceCounter/QueryPerformanceFrequency.

Because I don't know how to enable vsync with SDL2 I didn't see such thing.

I never used SDL, but judging from that post and my opengl experience, i guess you didn't use double buffering. Double buffering will remove any tearing effect on fast moving scenes, and lock your framerate for you as a bonus by default.

I think I found the better way, looking at the function SDL_SetVideoMode (which I think doesn't exist in SDL2) I notice a flag that I didn't see before SDL_RENDERER_PRESENTVSYNC , I just add it to my renderer creation function:

renderer = SDL_CreateRenderer(window,-1,SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC);

Now the fps is stable 60. (But I wonder if this vsync can be still disable by the user)

So I guess now my best call is to really work on time based movement.

Thanks everyone for the help!

I think I found the better way, looking at the function SDL_SetVideoMode (which I think doesn't exist in SDL2) I notice a flag that I didn't see before SDL_RENDERER_PRESENTVSYNC , I just add it to my renderer creation function:

renderer = SDL_CreateRenderer(window,-1,SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC);

Now the fps is stable 60. (But I wonder if this vsync can be still disable by the user)

This is a bad idea. If your movement rate is based on fps. Enabling vsync will not do what you want. This is because vsync is not quaranteed to be 60hz. It depends on your gpu and display and settings. If you have a 75hz or 120hz display and your gpu supports it and have it enabled then with vsync your game will run at 75fps or 120fps. Or even worse if you are using a 1080i tv as a screen with 30hz progressive setting it will lock the fps to 30. And as you had already guessed users indeed can disable vsync from the driver settings.

You really need to use high preformance timers. Either by forcing updates to 60hz or adjusting movement rate with deltatime.

The purpose of multiple updates before rendering is splitting work in different steps before the render callbacks.

In a more hi-level solution, one could use different time-slices for different tasks and optimize the loop for a given application.

Like:

0ms X ms 16ms

Input Animation Update Physics Rendering Flush

Also, locking the rendering code in 60fps will avoid calling API commands like clear, shaders, swapbuffers, texture binding, ... in a rate greater than it is needed.

I had a great change in perfomance when I reduced the rate of calling of these commands.

In a worst case scenario locking at 40 or 30fps gave me more time to update other non-rendering stuff and the application performed even better!