SetFrameRate/VertSync?

[Roose Bolton of the Dreadfort]

So I was happily making my game,

I set the framerate limit to 60 which makes it easy for me to build my game around as I wanted to make it perform at a steady 60 fps on all machines so I knew what my update speed was going to be.

When I was adding Box2D and working on the new stuff, I noticed that there was a slight stutter in the movement of the player which made it look terrible.

I stuck VSync on and this fixed the problem completely and all looked amazing.

However; I have heard that using both of them together is a big 'No'.. so what should I do?

[Laurent]

Remove the framerate limit (keep only v-sync), and make all your logic depend on the elapsed time even if the framerate is fixed.

If you really need an accurate fixed timestep, search on this forum (or on Google), there are very good articles about it.

[Roose Bolton of the Dreadfort]

I don't necessarily need a completely accurate timestep.. although I am using Box2d...

So basically I am going to need to cap the updates to a fixed timepassed? A bit like this article - http://www.koonsolo.com/news/dewitters-gameloop/

So that means I am going to have to change all my draw code so it implements interpolation?

ARGH WHEN DOES IT END. haha

[Laurent]

No, if you don't need an accurate timestep then using the elapsed time in your logic calculations should be enough.

Box2D should have its own fixed timestep algorithm internally, don't worry about it.

[FRex]

Box2D should have its own fixed timestep algorithm internally, don't worry about it.

It doesn't, you need to call step x times a second or you'll get choppy simulation.
It should work great with SFML clocks on 60 fps. I don't know what OP is doing wrong.
I mean, 60 updates a second and going for 60 fps, so even if fps drops there will be 60 updates per second. That's what box user manual says.

[Roose Bolton of the Dreadfort]

Box2D should have its own fixed timestep algorithm internally, don't worry about it.

It doesn't, you need to call step x times a second or you'll get choppy simulation.
It should work great with SFML clocks on 60 fps. I don't know what OP is doing wrong.
I mean, 60 updates a second and going for 60 fps, so even if fps drops there will be 60 updates per second. That's what box user manual says.

I am not doing anything wrong, I am just needing advice. As I said, I run FrameRateLimit and VertSync together and it runs perfectly, without VertSync my get stutters slightly which looks horrible and I need a FrameLimit just so I know the update speed...

If I only Cap the game as the VertSync then different screens will run the game faster which will mess up movement and physics simulation.

[Laurent]

If I only Cap the game as the VertSync then different screens will run the game faster which will mess up movement and physics simulation.

Yeah... that's why I said (3rd time):

make all your logic depend on the elapsed time

And in case it's not clear, I mean the actual elapsed time, not 1/60.

[Roose Bolton of the Dreadfort]

If I only Cap the game as the VertSync then different screens will run the game faster which will mess up movement and physics simulation.

Yeah... that's why I said (3rd time):

make all your logic depend on the elapsed time

And in case it's not clear, I mean the actual elapsed time, not 1/60.

By that, do you simply mean movement * ElapsedTime ?

[Laurent]

Yes