This project has moved and is read-only. For the latest updates, please go here.

Jittery Framerate

Topics: Developer Forum, User Forum
Nov 15, 2008 at 12:56 AM
I've got a weird issue. I took the multi-threaded example, and I've built a game based off a lot of the existing framework there. I've left in the PhysicsSimulatorView because it's a very useful debug tool. Well the game has a weird "jumpy" framerate issue, where it's running at 98-100FPS, but objects move with a real weird jittery motion. However, if I turn on the PhysicsSimulatorView, it corrects itself, and runs at a solid 100FPS and the jitter goes away...

Any thoughts as to what could be causing this "jumpy" effect?
Nov 15, 2008 at 7:31 PM
Usually this is caused by the garbage collector. But stuff like Vsync, High framerate vs. low physics rate and irregular physics updates can cause the same effect.

Check the garbage collector. Make sure that you don't create too much garbage. Try setting your game at a lower frame rate (60 fps), play with Vsync and make sure that you don't run irregular physics updates.


If you update your physics 1 time every update, then do it 2 times every update, it will make your game stutter without lowering your FPS. You can take a look at this article Fix your timestep for more info.
Nov 15, 2008 at 8:33 PM
Edited Nov 15, 2008 at 8:33 PM
ok, that explains the how would I go about fixing the "temporal aliasing" in Farseer? So apparently what you said is what's happening. I just don't know how to interpolate as the article describes...

here's my DoThinkPhysics()



void DoThinkPhysics() 
    elapsedTime += iterateParam.GameTime.ElapsedGameTime.Milliseconds; 
    if (elapsedTime < 100)
        while (elapsedTime > 10)
            physicsSimulator.Update(elapsedTime * .002f);
            elapsedTime -= 10;
        physicsSimulator.Update(100 * .002f);
        elapsedTime = 0;

So how should I store the Physics engine state if the Update() method doesn't return a state? Or is there another way to interpolate?






Nov 15, 2008 at 11:57 PM
The timing of your game loop and the like is not really farseer related :)

Game loops can be a tricky thing to handle. If your game indeed are calling the physics update twice, your best bet is to play with some of the game loop properties.

Anyways, here is a slide show that might help you:

You should also implement multithreading AFTER you have created your game. You might not need it at all and multithreading can cause more problems than it solves. Adjusting your game to good performance now, can cause bad performance when you are done (with your game).
Nov 16, 2008 at 5:34 AM
Ok thanks for the advice! Switching back to single-threaded mode fixed the "temporal aliasing". I'll have to experiment and learn a lot more about this phenomena before I go back to's a shame too, so much performance wasted on an idling second CPU ;)
Nov 16, 2008 at 12:04 PM
Think of it like this:
As long as you only have 2 cores, the second core will automatically take over other kinds of work while the first core handles your game.
You can still load textures, do background checks, play sounds and other stuff using threading.

Even giant games like Bioshok have had problems with multthreaded physics. The game was running fine, but the phyics were ran at a lower frame rate, causing the position and rotation of physics objects to lag.

Oh, and those wated cpu cycles are nothing compared to the GPU ;)