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

Xbox 360 version of farseer And other stuff

Topics: Developer Forum, Project Management Forum, User Forum
May 17, 2009 at 7:02 AM

is there any plans in the future for a xbox 360 branch or specific optimizations?
like for 2.3 or 2.4 because i know that while farseer is amazing on pc in regards to speed and functionality on 360 however it has all the great functionality but the speed is adveage (not that this is farseers fault of course) the 360 is quite a different machine and there are a few things that are very bad for 360 performance :( .

For instance on my cross platform game im working on i made some ropes and stuff on pc and stuff like that, now on pc 5 ropes (14 segments each) runs at about 250-300 fps (on my laptop 1.6ghz pentuim m) on 360 it gets around 10fps now while lots of this has to do with xnas implimentation of certain things and its garbage collector (perhaps i havnt profiled it) im sure that in the long term there is some performance that could be sqweezed out on 360 (hopefully without requireing a major re write of how it all works)

Anyway i was mainly just wondering when if ever there will be some stuff done for the 360 performance of farseer (i would love to have water in my game using it too but the 360 cant handle it) so will there ever be plans for this genbox? or is 360 support just a nice extra? (it is still pritty dam cool for it to work flawlessly on both at any speed)

also are there any ideas or plans for 2.3 and up ??
if so i would love to hear about them or any other plans anyone else has for farseer

May 17, 2009 at 7:06 AM

one other thing

i have made for xna a xml serilizer for farseers geoms and bodys and anything inside them
i dont know if this would be useful for you or anyone else but i could give you a copy if you wanted

basicly it lets you create and load a sprite, make a geom and body out of it, set all of its settings, write it to xml that xna can read on 360 and pc and then during the game you can just load up all physics items in the world from the pregenerated xml files rather than createing them during the loading of the game

May 17, 2009 at 10:40 AM

It's hard optimizing for a platform that you do not own yourself :)

Anyway, Jeff and I have inlined a lot of code in an attempt to speed things up on both PC and XBOX360. They are micro-optimizations designed to reduce garbage, memory copying and overall codebase. We did get a great performance gain, but as always, micro-optimizations does not compare to better algorithms, so we constantly try to increase the efficientcy of our algorithms. (Thanks to Matt)

Our algorithms are general purpose and will work great for most games, but nothing compares to clever programming and custom built algorithms to handle physics logic. I had an instance where a user had 1000 geometries onscreen at one time, the normal algorithms made his game run at 3-4 FPS, he implemented his own algorithm (a broad phase collider) and due to his special game logic (where most of the geometries would not collide - they should not collide) he got around 85 FPS.

As much as I try to minimize the overhead of the garbage collector and memory copying, it is a fine line between user friendliness and performance. The Farseer Physics codebase is split into two parts:

1. The user API that for example have the posibility of sending data without using the ref keyword.
2. The internal API that does not use properties (at all), have everything manually inlined, use ref everywhere and use a lot of temp variables (to minimize cleanup and allocation)

If you (or anyone else) manage to find a bottleneck on the Xbox360, I would be happy to take a look at it and see if I can eliminate it.

As for the serializer, I would be happy to take a look at it. It is on my TODO list to include some sort of serialization to persist the state of the physics engine. (for savegames and the like).

May 17, 2009 at 11:50 PM
Edited May 17, 2009 at 11:51 PM

It be great if you could improve naything for the xbox,

i just ported mine to xbox to make sure everything worked,

So everything built fine and when i loaded the level all my NPCs and my character ran fine

i change their linear velocity for moving left and right,

but hen any one jumped the game just slowed to a crawl,

i could use my grappling hook(slider joint) and increase and decrease the length with all my npcs following

all of them using a dynamic ray class i created, casting 3 rays each that interacted with every geoemtry and check against every geometry for sight

and it ran smooth as butter

But as soon as someones feet left the ground it just destroyed the framerate slowing to about 1fps,

whether i pulled myself up by decreasing the length of the slider joint,

or applying an impulse it just sh*t its pants,

i really dont understand


edit: I was using the xna branch and modifying its build property

I am downloading the lastest source and am going to use the xbox branch in hopes of some miraculous change

May 18, 2009 at 12:12 AM

Ok so i just tried the latest source's xbox branch and it ran even slower,

and it ran slow regardless of what i was doing

I am very confused why as on 1.7 ghz, 232 mb ram, ati graphics, laptop it runs smooth.

The most complicated thing from farseer i use is a slider joint everything else is just classic geoms and bodies

May 18, 2009 at 1:48 AM
Edited May 18, 2009 at 1:49 AM

Hi all,

I'm yet to test my Farseer Samples on the Xbox (still waiting for repair-guys... grrrr) but nevertheless I've got some experience with optimizing .NET code.

The first thing I learned in struggling with .NET performance was to avoid trying to be smarter than the JIT compiler. Manually inlining functions, replacing properties by fields, caching delegates and variables, most of the times I found out that these do more harm than good with regards to performance, especially when going cross-platform, since you're basically in the dark as to how exactly your code will be crunched down to bits and bytes, and you may be denying the JIT some good opportunities.

From following this discussion and looking broadly at the Farseer code, I think that some things could be improved. I present my thoughts below along with some other suggestions you may feel inclined to look at:

  • Properties with simple getters and setters are automatically inlined, so they perform as well as direct field access. Particularly, if you declare a property using the new C# 3.0 syntax, like so " int Prop { get; set; }  ", you ensure that the property will always get inlined, and it guarantees good coding practices. Farseer exposes many data fields directly, which can be dangerous in the long run as the library grows in complexity.
  • This may be a bit unrelated to performance (in this particular case), but the Dispose pattern implementation is incorrect, as most of the classes inheriting from IDisposable do not override their finalizers (although they call GC.SuppressFinalize() from inside the Dispose method). Also, from my experience, the Dispose pattern can become less error-prone if most of the classes using it derive from a base Disposable class or similar for code reuse.
  • It can be difficult to understand just what optimizations are taking place when debugging your code in Visual Studio. Even if you build and test your project in Release, it is no guarantee that the JIT will go full power. The best way is to actively profile a Release build outside of Visual Studio.

I hope that some of this suggestions can help you make Farseer a more performant framework. Meanwhile, when I get my hands on the Xbox 360 I can try and run some tests and comparisons to see what else I can find by looking deeper into the Farseer source code.

Best regards and thanks for everything!


May 18, 2009 at 3:32 AM

Thanks glopes although im not quite smart enough to know if what your saying is correct haha,

but i think its worth mentioning

when i used the latest source on the xbox it was much slower but on the pc it was just about the same as before

and before i was using a version from april 29th, i switched the xbox version back to the xbox 360 copy of april 29th and when i decrease my npcs to 8 (very low compared to pc results) it runs very smooth.

I realize there have been major changes since april 29th obviously but perhaps something between then and now could be a link to the performance issues on the xbox.

bahh humbug, i have no clue so ill shutup

May 18, 2009 at 4:19 PM
Edited May 18, 2009 at 4:20 PM

First off, thanks for the information. Suggestions, corrections and the like are always welcome.
I've put numbers instead of bullets to comment each of your suggestions.

1. Indeed it does, but there are also some requirements to the methods being inlined. Size is just one of them. Farseer Physics was built using the 2.0 framework and the optimizations done by the JIT was useless. (not completely useless, but almost :) ) we therefore inlined the most critical parts of the engine to make sure that they rans as fast as possible, without the help of JIt optimizations.

2. When I developed Farseer Physics Engine 2.0, I changed all the properties into automatic properties (and making it dependent on .net 3.0) - Our users where not happy about that change and called it syntax sugar instead of actual benefit. I prefer auto properties instead of fields (they are optimized as well as fields) and it makes the libarary backwards compatible. (changing a field to a property or the other way around, is not). Right now we survive using public fields instead, this might change in the future as it matures.

3. It is indeed used incorrectly; or said in another way: it is used as a workaround. The engine removes all bodies, geometries, controllers, springs and joints on each update of the physics simulator. If you call Dispose() on a object, it will set the IsDisposed property to true, and remove the object from the engine on next update.

Normally, If a user happens to call Dispose() on an object that still lives in the engine, it can't remove the object because it is used everywhere (it is still referenced in the broad phase for example). The garbage collector does not remove anything that still has a (strong) reference to it.
If you have any suggestions on how this can be changed to fit the engine better, I would like to hear them. Getting it to work correctly was a battle.

4. I've read that article several times :) I have even written some of my own. (One is on Ziggy, but it is in a bad state - not updated and without pictures).
There are also some great articles on XNA/Game specific performance - such as magicial square root (more info here), fast multiplication using bitshifting and approximation of common operators (think it was mentioned in "Understanding XNA Framework Performance" - search google)

5. Indeed - most optimizations don't take place when debug is enabled. The JIT simply does not do them to make code debugable. I've tested Farseer using both Ants and the built-in profiler of Visual Studio 2008 Team Edition (from work).
I still need to learn how to master a profiler. Yes, I can see the allocations and memory usage and what causes them, but there is a lot more to it than that ;)
Someday I will revert the inlined code back to the original (that is also why they are still commented by regions). The JIT compiler has a lot more optimizations now than it used to. (It inlines methods that has structs as arguments for example - It did not do that before). Some day I will also use the newest syntax of the C# language (auto properties, lambda expressions and the like).

May 18, 2009 at 4:21 PM

@tlegion: That sounds weird. Have you tried the simple samples on Xbox360?

May 19, 2009 at 12:25 AM

@genbox: Thanks for your post, it was very informative. Like I said, I only took a broad look to Farseer, so my comments were mainly to ensure that you knew what you were doing. Glad to hear you took all that into consideration. Dealing with managed code is far more tricky than they let you believe :P...

The JIT has been gaining new tricks up its sleeve, that's for sure, and it sure is good to keep testing it occasionally. If we can come to rely on the JIT in the long run it will always be an advantage IMHO.

As to the removal of Bodies/Geoms and other things from the simulation, I understand it's a tricky issue, and I can see your reasons for using Dispose() this way. Ideally, the responsibility of removing an item from a collection should be of whomever put it there. So instead of calling Body.Dispose(), it would be cleaner to just call PhysicsSimulator.Remove(body), and do the cleanup code there. However, if threading is in place, I understand that this can happen at a troublesome moment. The sheer amount of circular references surrounding the Body class can also be a pain to deal with, I guess. I don't think I have a better solution just yet, but I can give it a best shot once I get to know the organization of the framework more closely.

Thanks for the references, I'll look them up to see if I can gain more insight into XNA performance approaches.

@tlegion: Please do try with the simple samples to make sure that it's related to Farseer and so that it will be easier to pinpoint the exact cause if it is.

Best regards to everyone,


May 19, 2009 at 6:15 AM

I will try the simple samples for sure,

I am kinda busy for a while with finals, tests befre finals, and essays in place of finals, so i wont be able to try it right now,

i will boot up my xbox tomorrow hopefully when i have a bit of spare time