Choppy camera.

[Dr. Clown the Strangler]

I'm reading through the "SFML Game Development" book. And there's something I cannot figure out. I understood how the game loop's supposed to work, but when I put it together in a small test project, I ended up having a choppy camera.

Here's the source code. The "player" sometimes wraps back and forth.
It doesn't happen without a camera (=sf::View).

I compiled the final version of the seventh chapter and it doesn't seem to happen there.

PS: Never mind the strange usage of the vector.

[Ixrec]

I haven't read the book or anything, but the thing that jumps out to me is how you've wrapped event handling in this while(betweenFrames > perFrame) loop.  My impression was that you're supposed to do that processing every loop, and simply multiply by the time between two frames.  So my guess for fixing your problem is: delete that while loop around your event handling, and in your event handling multiply velocity by dt instead of by perframe.

[zsbzsb]

I'm reading through the "SFML Game Development" book. And there's something I cannot figure out. I understood how the game loop's supposed to work, but when I put it together in a small test project, I ended up having a choppy camera.

Here's the source code. The "player" sometimes wraps back and forth.
It doesn't happen without a camera (=sf::View).

I compiled the final version of the seventh chapter and it doesn't seem to happen there.

PS: Never mind the strange usage of the vector.

Try adding mWindow.setFramerateLimit(60); (before your game loop) to your code and then test to see if the the choppy camera problem is solved.

I haven't read the book or anything, but the thing that jumps out to me is how you've wrapped event handling in this while(betweenFrames > perFrame) loop.  My impression was that you're supposed to do that processing every loop, and simply multiply by the time between two frames.  So my guess for fixing your problem is: delete that while loop around your event handling, and in your event handling multiply velocity by dt instead of by perframe.

This works too, but remember floating points are not entirely precise. When you just multiply the velocity by the frame time you will still end up with slight speed differences depending on the framerate. This is why it is better to implement a fixed time step (just like in the OP's code). That way you are guaranteed to get the same movement speed no matter what the framerate is.