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

Xbox 360 Optimisation in the future?

Feb 22, 2009 at 8:41 AM
i was just wondering what kind of plans there are to optimise farseer on the 360

now i know that there is probably lots of other things that need to be done first
on my slowest pc (old 800mhz celeron) i get about 138 fps in xna with about 60 stacked objects
on xbox this drops to about 1.1fps

now i know that the xbox is not floating point optimised yet and also has GC overhead

but in most cases 1 360 thread (out of the 6) is the equivelent that of a 800mhz p3
(which holds up is almost everything else i do)
but in this its about 100 times slower

now i could be doing something wrong (but i dont think i am)

so basicly i have 4 questions 

1: Are there plans for Xbox 360 Optimisation in the future?
2: Is there any kind of timeline for this
3: Is there anything i can do to help? (i dont know to much about collision reactions but i am a decent programmer (ive done a sweep and prune before "but i dont think thats where the problem lies i think its in the reactions more-so")
4: What can i do in the mean time to maximise performace on 360 ive tried a few things but cant really seem to change that much should i let it use the default grid cell size or custem ? any other performance tips or optimisations i would love to know

thanks in advance to anyone who replys (i know ive written alot lol)

Feb 22, 2009 at 1:45 PM
Edited Feb 22, 2009 at 1:45 PM
1. Yes, eventually. Jeff already did a lot to optimize it for the Xbox, but we could probably do more. I don't own a Xbox360 so I can't check the results (does it get better or worse) and I don't have a good reliable test to see if performance indeed does get better.

2. No, not currently. Now that you have mentioned this topic, I'll try and see if I can squeeze it into FP 2.2 changelist.

3. Indeed there is. We are only 2 people working on FP 2.1 in our spare time, we are always looking for some help that can speed up the development. If you are able to identify some problems with our code, I will be happy to fix it right away. We are in the progress of changing some algorithms to speed up things, and I don't think our design is too bad, so we are on the right track.

I've made a small list of problematic code to look for:
a. Places where we could use struct instead of classes
b. We could be using ref and out instead of normal arguments and return. (Only places where we use structs. That is almost everywhere)
c. Rapid spawning of objects that gets discarded. The GC has more to do when you spawn objects just to destroy them afterwards. We could reuse the objects intead.
d. Avoid boxing/unboxing. Places where you convert to object and from object. I think I eliminated all of those except 3-4 places in 2.0. Those 3-4 places require boxing/unboxing because they need to. (Overriding the .Equals() from the .net)
e. Find operations that use - + * / % on structs (Vector a * Vector b) and replace them with manual operation (a.X + b.X and a.Y + b.Y) or buildin (Vector.Add(a,b)). This reduces copies made of structs.
f. Inline code. Copy the content of a method into where it's needed. (This is good in loops) to reduce the overhead of the method being called. The compact framework does almost no inlining by itself.

More info here, here and here.

4. You can do all of the above for one. For FP specific optimization you can make the grid cell size bigger. Try out a small grid cell size and continue to increase it until collisions with the geometry looks wrong. Grid cell size controls the precision of the collisions.
You can also try and seperate FP into a thread. Use some of those threads the Xbox360 comes with.

Use tools like the CLR profiler and Garbage collector counters to see if you have any places you can optimize. If you reuse objects in a loop that runs 100 times, you could potentially save 10000 objects from being garbage collected on each GC update.
Feb 24, 2009 at 10:36 PM
@danthekilla: I have an Xbox 360 and hopefully given some time and spare $ to get the membership. I am looking to get some huge performance gains on all the platforms by doing all of what Ian has pointed out above. The truth is FP should most likely be rewritten from scratch but nobody has time to do it. It's not the structure that makes it slow on the 360 it's the GC milling away because FP wasn't written for the 360. In one of my books on XNA programming has tons of tricks to get code to run as fast as possible and one of the biggest things is keeping tabs on the GC.
Feb 25, 2009 at 4:57 PM
This makes me worry a little :) I dont have a xbox 360 yet but I plan to buy one in a few weeks as I'm doing a game that I plan to release.

Now I don't have that many geoms/bodys in my game that are non static, around 5-10 out of ~150. I don't know if Farseer is optimized for this kind of scenario, I looked at the code and thought I saw a few places where you can skip some code earlier if the body is static? I will look at this more if it turns out to be a problem and see if I can help

Has anyone tried with a similar setup (~130 static bodies and ~10 non static) on a 360 and what kind of fps did you get?

Feb 25, 2009 at 10:20 PM
Static bodies does not have a big performance impact as they are not checked against other static bodies. All your 150 bodies will not be checked against each other and should perform very well on any kind of computer.