Just noticed that the documentation (Manual) is actually an old version. Codeplex had some problems with it's source control server about a week ago, we properly lost the new documentation at that time. (Could not upload the new version and must have overridden
it).

I don't have FTP access from this network, I will upload an updated version when I come home.

The online docs are great so that you can get a good idea of what the text is talking about. Can we add the actual code used to create each joint in the example as well? This will help to get an idea of the 'normal' kinds of values to use in joints / springs,
or a starting point to work from. Perhaps a note in the documentation saying something like "Normal values are between (N) and (M). You may get weird results with values outside these ranges." (For new users like me that get wierd results when playing
with springs.)

@DrDeth - Normal values are currently demonstrated in the demo code, but it's a great idea to put that stuff straight into the manual. The more I think about it the more I want to start a separate 'advanced manual'. Only problem is time.

I just tried out the advanced samples. For some reason some of the demos bring my framerate down to a crawl. Namely the stacked boxes ones. It was never this bad in 1.x.

Edit: Ok, I'm going to assume the drop in performance is due to an increase in the number of objects. I can't go back and compare how many there are in 2.0 to 1.x as 1.x doesn't seem to want to convert right. Anyways, after looking over the
code I just modified a couple of variables to match what the "#if XBox" had under it and it runs fine. I guess the good thing is that you could say my computer has about the same processing power as an XBox 360 so that may actually help in
the development process as that's what I'm developing for. In any event the performance shouldn't be a problem as long as it's relative to the performance in 1.x.

@Lemunde: I might have increased the number of boxes in 2.0. Try setting it to a lower value and try again.

Update: I wanted to write this yesterday, but I was very busy. Anyways, I noticed you wrote Advanced demos. the advanced demo with the pyramid uses threading to do it's work. There is an overhead doing threading and that might be why you can't
run the demo without lag.

Try the simple samples instead, they still include a non-multithreaded version of the pyramid.

@1amowery: Ian has done a lot of micro optimization and really sped up Farseer. The absolute best way to achieve better performance is through multithreading. None of us developers for Farseer have a 360 so it's hard to performance tune for it. From what
I've read about the 360 the biggest problem is the garbage collector. Creating objects takes quite a bit of time too. Seems almost like it would be better to create a pool of as many bodies as you will need for say the whole level and possible create a pool
of all the geometery you will need for that level, then add bodies to the physics simulator. Only problem is with dynamic creation of stuff. Thats hard to do. Anyway good luck. Please let us know if you try it out on the 360.

As Matt wrote, there has been a lot of optimizations in never versions of Farseer. Jeff already made most of the engine use micro optimizations before 2.0. I just added a few and removed some redundant code. There is still room for improvement, but most of
them would only apply to specific situations.

The best way to create good performance with Farseer Physics is to use it correctly. Applying physics to a lot of bodies requires a lot of work (and even more work with geometrie). So make sure to minimize the amount of live physics objects
and implement caching/pools. A lot of ways to improve performance with Farseer Physics is described in the new 2.0 Manual.
The advanced demos also show examples on how you can use multithreading and pools to speed up your game.

And again as Matt wrote, 360 has some trouble with the garbage collector, specific kinds of math and CPU speed. You will have best performance if you use all cores on your Xbox (http://msdn.microsoft.com/en-us/library/bb204834(VS.85).aspx)
and if you push some of your work to the GPU instead of the CPU.

Also make sure to use profilers to see what's generating garbage, hotspots and delayed loading. Creating a good performance complex physics enabled game requires some work, but we try to keep it as simple for you as possible.

great to see you released a new version. I already tried it out.
Sorry for not having the time to write some documentation for the inactivity controller and scaling but i am busy with finishing my game. Found an investor who spends some money...
My next task will be to synchronize 2 farseerphysics simulations over the network using xna networking.
Is there some interest to optionally include that into the engine?
The only problem will be that this needs XNA and is not compatible with silverlight.

It's no problem. If you have any additions to the documentation, you are welcome to download the doc version, edit it and send it to me. It's important that we have no errors in the documentation. :)

Great to hear that you found an investor for your game. It's great that people use the power of Farseer Physics (and extend it as in your case ;) ) in their games. Would like to see the outcome when you are done.
I would really like to see your physics over network implementation. We like to have the engine stay as simple as possible, without any network specific components if possible. We could create a networked sample though. But lets have a look at it when you are
done with your game.

Thanks for the kinds words, you can give yourself a pad on the back for the work on the inactivity controller and all the other stuff :)

you will of course get a free copy of the game if its released.
Maybe i could do a demo for the scaling. I saw that this isn't included.
But this is exactly the component that solved all my performance problems (that's why i developed it;) )

just to let you know: i successfully synchronized 2 physics simulations over a LAN by creating a generic class that handles synchronization. One running on my computer and one running on a Xbox360 :)
I tried to make it independent of any network library and it will be possible to derive from this class to implement other libraries than the XNA net libraries. You could even extend the code to support other objects which needs to be synchronized (players,
etc...) by simply specifying the type of the generic class you want to synchronize and adding a handler for these objects.
All without changing the farseer code at all.

I could give you the sourcecode to add this to the samples if you are interested.
Just let me know.

Damn, i forgot something:
i made a generic ObjectPool too some time ago and i saw that some kind of this is shown in the demos. Maybe you want to add this too. I think it's a smarter approach due to the fact that you only need to derive from this class and add a few lines of code to
support any object you want.

@sensorium:
Using the XNA Net library has nothing to do with normal network programming. It's abstracted like hell.... in a good way.
Sorry, i can't show you the complete sourcecode of my network handling due to the fact that the investor is paying for it.
But i can (as i said in the post above) upload a sample how to do the basic synchronisation between 2 or more farseer simulations - that should be enough to give you the information you need.
Give me some days to get my code done. After it i will write the sample and upload it for genbox.

@genbox:
My solution for the objectpool is reusable. That is the only difference. You can apply it to every object.
As you can see, you could implement a pool for a specific object with ~10 lines of code. Here for example for a circle object:

@dp2208: Ok. I asked because I could not see the difference between the current Pool implentation and the description of yours.

The current Pool implementation is also generic, It does however, not contain the activate and deactivate specific parts as your implementation. (De)Activation of geometries/bodies is indeed what the Pool was (partly, It's main reason was Arbiters) created
for, but it can also be used as a normal object pool for anything else, without any (de)activation specific logic. I think we will be better off making the pool class partial (the partial keyword) so that people can implement their own stuff inside the pool,
instead of editing the Farseer sourcecode. What is your take on this?