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

Farseer limitations on XNA and Silverlight?

Oct 4, 2007 at 1:11 AM
Hey, awesome release!!! Very clean code it's a pleasure to be using your library =)

I have some questions, I have been considering porting my game to Silverlight. Your demos were kind of ideal to see how your engine would react with lots of entities. So I tried the demo4 and changed the pyramidBaseBodyCount to 18 (which doesn't seem all that much??) and this pretty much brings IE to it's knees (it crashes). Is this a limitations of the physics engine or silverlight?

Then I notice in the same demo for XNA, you do a

#if XBOX
private int pyramidBaseBodyCount = 8;
private int pyramidBaseBodyCount = 12;

Is this also due to a limitations on the XBOX??


I take it that the 360 cannot handle more than 8 while keeping good performance??
Oct 4, 2007 at 1:50 AM
Edited Oct 4, 2007 at 1:53 AM
The Pyramid stacking is one of the most intense (performance-wise) samples. 18 boxes on the base -> 157 boxes each involved in 3/4 resting collisions. The collsion resolution, internally, is iterated 5 times for each contact point. There is room for some more optimzation in this area. My next step is to inline everything in the collision resolution method.

Yes the limit for stacking is 8 on xbox.. actually it may be able to to a few more but I settled on 8. You'll notice that as soon as you knock the pyramid around a bit the frame-rate jumps up quickly. It's really simultaneous collisions that are the bottle-neck.

I suspect the browser has the same issue although it would be somewhat based on the cpu of the computer it's running on.

I'd say if you are using farseer for a game you will want to keep an eya simultaneous collisions. I have plans to add "sleeping" contatacts at some point but not anytime soon.

For now, games involving 100s or 1000s of simultaneous bodies is not Farseer's strong point.

Hope that answers your question.

Oct 4, 2007 at 5:17 AM
I think one of the keyfetures for future updates would be object auto freeze, with set angularevelocity and linearvelocity thresholds per object. That would limit the osselation that all the bricks are doing in the pyramid and reduce overall cpu-load on 'stationary' scenes.

Very nice release btw, we are just looking over the demos in the office. :D

Oct 4, 2007 at 11:02 AM
You can improve the pyramid stability by either upping the physicSimulator.Iterations property to 10 or by updating the simultor with a smaller timestep... ofcourse this is at a performance cost.

Sweep and Prune, Sleeping Bodies, and inlining code are 3 areas that would improve performance...

Glad you are liking the engine so far.