The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.


SDL Forum Index
SDL
Simple Directmedia Layer Forums
Should the frame rate be a multiple of the refresh rate?
Sythical


Joined: 06 Aug 2013
Posts: 7
Hello!

I've recently started writing a simple 2D engine in order to gain some experience but my animations aren't as smooth as I'd like them to be. I'm decoupled the physics from the rendering since I want to use the engine mostly for physics simulation. The game loop is described on this page under the 'Free the physics' section.

For testing, I have a texture moving left to right and vice versa at a constant speed and the application is rendering over 3000 frames per second and the animation is also quite smooth. I decided to add SDL_Delay(14) before SDL_RenderPresent(renderer) to see how the engine would behave at more realistic frame rates. The frame rate dropped to 71 as expected but the animation was no longer smooth. I first assumed that there is something wrong with my code and tried to finding a bug but had no luck. I started outputting the difference in the consecutive x-positions of the texture and the time difference between each render. Some of the output:

3 0.00993483
3 0.0100341
3 0.00998648
3 0.0100013
3 0.00999638
3 0.00998122
3 0.010053

Most of the output was very consistent and so I started searching for other issues. I decided to enable vsync and everything became as smooth as butter. This made me realise that if I'm rendering at 71 frames per second, 11 frames will be skipped and so the speed of the texture won't look constant to the observer resulting in jerky animation.

So my actual question is: how to do so many games manage to have smooth animations at odd frame rates such as 62, 71, 83, etc. and should the frame rate be a multiple of the refresh rate?

Here is my game loop in case someone wants to read it:

Code:
while(main_event->type != SDL_QUIT)
{
    last_time = current_time;
    current_time = get_tick();
    accumulator += current_time - last_time;
   
    SDL_PollEvent(main_event);
   
    if(accumulator > accumulator_max) {
        accumulator = accumulator_max;
    }
   
    while(accumulator >= physics_step) {
        if(pos_x_new < 101) vel_x = 3;
        if(pos_x_new > 1300) vel_x = -3;

        pos_x_old = pos_x_new;
        pos_x_new += vel_x;
       
        accumulator -= physics_step;
    }
   
    interpolation_value = accumulator / static_cast<double>(physics_step);
    rect_data.x = pos_x_old + (pos_x_new - pos_x_old) * interpolation_value;

    SDL_RenderClear(renderer);
    SDL_RenderCopy(renderer, rect_texture, NULL, &rect_data);
    SDL_Delay(14);
    SDL_RenderPresent(renderer);
}


My physics is updated at 60 Hz. Thank you for reading Smile
Sparks


Joined: 01 Jun 2013
Posts: 47
Most good games are based on game time, not refresh rate. So, they are always constant.
In your loop, it is also odd that you use SDL_Delay(14);, is that really needed ?
Sythical


Joined: 06 Aug 2013
Posts: 7
Sparks wrote:
Most good games are based on game time, not refresh rate. So, they are always constant.

Yup, and my game has a constant speed. It'll run at the same speed no matter what the frame rate is.

Sparks wrote:
In your loop, it is also odd that you use SDL_Delay(14);, is that really needed ?

It's an artificial delay, normally it'll take a couple on milliseconds for the game to render. I've just added it to make the problem more apparent.