framerate limit

[slotdev]

Hi Folks

Can someone sanity check me with this statement?

I do not have to call sf:Sleep anywhere in my program IF I call SetFramerateLimit already?

Currently, I call sf:Sleep(3) after every check of the render loop (no matter if we rendered something or not).

Thanks
Ed

[Laurent]

I do not have to call sf:Sleep anywhere in my program IF I call SetFramerateLimit already?

Correct, SetFramerateLimit already calls sf::Sleep to keep a constant framerate.

[slotdev]

Hmm OK. Well removing a sleep(3) from my program has really increased the framerate.....but now CPU is at 99%

[Laurent]

What's your framerate without calling SetFramerateLimit, and what limit do you use?

[slotdev]

I think the problem is we have our own framerate control, and also that in SFML. Let's assume we use 30fps.

We use a timer and we check this against the amount of time the last render took (so if render took 8ms, we will start rendering again in 25ms). This is called in the game loop.

SFML (I guess) does something similar, but did you mean it so we call Draw(etc) and then Display() as often as possible, and SFML won't update the screen if it's not time yet?

I hope that makes sense :S

[Laurent]

SFML does exactly what you do, ie. waiting in display() until the requested frametime is reached. So there's no point activating both

[slotdev]

SFML does exactly what you do, ie. waiting in display() until the requested frametime is reached. So there's no point activating both

Ah ha. The difference is then, that we continue to do other code which is required (checking other events/attached peripherals/etc) in between each render. So maybe disable the SFML framerate checking would be a good idea....

[atlasC1]

I'm brand new to SFML (trying it out in comparison to Allegro 5), and I too am slightly confused about the frame rate limiting.

Does limiting the frame rate limit the entire game loop speed? Or will it only affect the loop when display() is called?

What happens if our game runs into a complex situation, and the update takes too long to fit into a 60 ticks per second loop. Does the loop automatically drop frames, or will it continue to render them and slow down the loop even more? Would it be better to control the timing manually in this case, instead?

Thanks, and excellent work with the library!
-atlas

[Laurent]

A few lines of code may be clearer than a long explanation:

void Window::display()
{
    ...

    if (m_frameTimeLimit != Time::Zero)
    {
        sleep(m_frameTimeLimit - m_clock.getElapsedTime());
        m_clock.restart();
    }
}

There's really nothing complicated behind this feature, it's exactly what you would write if you did it yourself.

[atlasC1]

Thanks Laurent,

Makes sense; I took a look at the implementation in window.cpp.

So, to my understanding, by using this option, your game loop rate becomes dependent on your frame rate.

-atlas

[Tank]

Yes, but nothing stops you from making your calculations dependant on time.