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

Velocity changes proportional to Physics Update.

Oct 23, 2008 at 3:22 PM
Edited Oct 23, 2008 at 3:29 PM

This is probably a noob question but I'm wondering if the best way to go is to change the Body.ApplyForce to a higher number when I update the PhysicsEngine with a lower update interval?
I want bodies to travel equally fast regardless of the update interval of the PhysicsEngine.

All answers are appreciated.

By the way, thanks for a great Physics Engine. It's both simple to use and doing what I want it to do, which is few who can. Keep up the good work.
Oct 23, 2008 at 9:28 PM
@DeusVult - I believe Farseer is designed to be used with a fixed update interval. Using a variable update interval is not recommended, I think. If you have tons of stuff going on maybe you should lower the frame rate some.  Also I think Farseer that scaling, a new feature in 2.0 might be what you are talking about.
Oct 23, 2008 at 10:24 PM
Thanks for the answer mattbettcher!

I tried to have a dynamic update interval because I want my game to have the possibility to be played at slow motion, as well as faster than normal speeds.
I've noticed myself that changing the update interval makes the game bodies "jumpy" and does not work, not good enough anyway. Is there any other way to simulate slow motion?
Nov 1, 2008 at 5:29 PM
Edited Nov 1, 2008 at 5:30 PM
Hi DeusVult,
have you tried using a fixed timestep like this?

class Physics
  const float TIMESTEP = 0.01f; // tune this value
  PhysicsSimulator simulator;
  float physicsDelta;

  // ...

  void Update(float timeFactor)
      this.physicsDelta += timeFactor;

     while (this.physicsDelta >= TIMESTEP)
         this.physicsDelta -= TIMESTEP;

   // ...
Nov 3, 2008 at 1:24 PM
Hi, mkilling. Thanks for the answer.

I have not tried using a fixed timestep so I'll test it out.
Nov 3, 2008 at 5:15 PM
Good idea though, mkilling!  I never thought of doing it like that.

However, I'm thinking that the while() loop should be changed to an if() statement.  If it is the physics simulation that causes the updates to lag, that physicsDelta may just keep going up faster than it goes down, making more and more calls to the simulation each frame, and causing the game to just slow to a crawl. (Draw() won't be called while Update() is still running.) If I recall correctly, Update() is called as often as physically possible (not fixed), so it should be able to catch up once the physics simulation stabalizes.  When it lags in this case, things will seem to slow down on screen durring laggy physics updates, then go hyper-speed until it catches up to where it should be in the simulation.

If you do intend for the entire game Update() (not physics) to be called at a fixed interval, the while() loop may be a better choice.  Guess it's something you'd want to think about.
Nov 4, 2008 at 12:21 AM
Hi Yota,

you're right. In my actual game code I cap the number of simulator updates at 5 per frame. My game runs at a variable timestep while I update the physics with a fixed timestep. I've so far ever experienced any serious slowdowns or other problems.