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

Understanding of World.Step

Topics: Developer Forum, User Forum
Jan 7, 2011 at 10:54 AM

First of all thank you all very much for this great engine! I am trying to create a simple game with this now to get a good feeling for the engine.

What I did is to create a new DemoScreen based on the examples in the SimpleSamples Silverlight project. I add a new body (a rectangle) and use the ApplyForce method to it. The object moves as expected, so everything is fine.

Now I tried to play around with the World.Step method. Here I am getting into some kind of understanding problem: am I right assuming that calling the Step-method actually starts the calculations in the engine? Let's say I have this code fragment:

float step = 0.05f;

Should this not (precision issues aside) be more or less the same as

float step = 0.005f;
for (int i=0;i<10;i++)

(i.e. after the loop is done, the objects should have moved by about the same distance)

What I can witness here in my demo-project is, that while the objects seem to make more or less the same movement, the speed in which they do it gets influenced by the number of steps executed. Without having measured it, it seems that they move at a tenth of the speed compared to the first example.

The step-method is called in the Update-method of the DemoScreen class (like in the other Silverlight examples). It takes around 16seconds for 1000 calls to the update method in both variations (so approx. 60fps), so I cannot quite understand where the slower movement in the second case stems from?

Why am I doing this anyway? I have noticed that objects travelling at too high speed can pass through other object (in my example I have a second rectangle and I aim the first at the second one. Depending on the speed of the "projectile" rectangle it can pass through the first rectangle without touching it. At slower speeds it collides with the rectangle as expected. So this seems to be a resolution problem and I had hoped to get rid of this by increasing the number of calculation steps per time unit. Perhaps this is the wrong approach anyway.

I am thankful for any pointers here :)

Kind regards,



Jan 7, 2011 at 3:04 PM

Farseer supports CCD (continuous collision detection), which is also enabled by default. For fast moving objects set the IsBullet flag on a body to prevent it from tunneling through other objects. You can also increase the number of iterations Farseer does in each step in Settings.cs.

I have no ides where the slower movement comes from, but are you sure that you call step with the same amount of time within the same amount of elapsed realtime? Normally step should be dependent on the time elapsed since the last frame, which may vary a lot. I'd presume that doing step 10 times in a row takes a lot longer to compute (e.g. 10 times as long in your worst case) and thus your framerate should drop significantly. Depending on your setup XNA could even drop frames without you noticing it, resulting in world.step not called as often as you might presume.