PC XNA Game converted to Xbox 360 - Huge Performance Issues

Question

So I wanted to convert my PC game to work on the Xbox 360. It ran damn fine on the PC, with a Intel Core 2 Quad @ 2.40Ghz and a Radeon 4850 512MB.

I ported it to the Xbox, and right off the bat, there was some problem with invariance and inheritance regarding importing of lists, so I simply used the LINQ method called .Cast<>().

If that method is takes a big overhead, let me know, because I cannot deploy Performance Analysis on the 360 for some reason, most likely because it plays on the 360.

Then another problem came, and it was a nice System.OutOfMemoryException. My skybox textures were 4096x4096, so reducing them by half removed that error. Odd though, they were only 3MB x 6, so it shouldn't be using that much of the 512MB available.

So when all those problems were cleared out of the way, a nice 1 frame per 2 seconds were introduced. It then crashes after 1 minute of gameplay, a "Code 4" whatever that means.

It plays like a powerpoint. Here are some performance analysis images from PC gameplay. They are not bad.

CPU: http://i.imgur.com/JYx7Z.png RAM: http://i.imgur.com/C29KN.png And 72% = 150MB mind you.

I hope anyone here has some experience on this issue. Frankly I am all ears.

Answer 1

The root cause of your performance problems is almost certainly because you're allocating memory while your game is running (after startup, during the Draw/Update loop).

On Windows this is fine. The garbage collector on Windows is generational (will only clean up new objects when possible) and extremely fast. It is clever about when it chooses to run, too.

The garbage collector on the Xbox 360, on the other hand, is completely rubbish. It runs for every 1MB of memory allocated. It checks the entire managed heap when it runs. And it's quite slow to boot.

So the answer is to never allocate memory while your game is in its running state.

There's a good blog post about this here. (It also describes the alternative to never allocating memory - which is to reduce heap complexity - which is really very difficult to implement and I don't recommend it.)

• You will have to remove things like LINQ, as the query objects it creates are heap objects, as are the delegates it frequently requires. Use simple loops instead.
• If you are allocating your own reference types in draw/update, you will have to convert to using value types where possible or add object pooling.
• Creating string objects is another common source of memory allocations - instead you can re-use a StringBuilder and render that directly.
• Converting things (especially: numbers) to strings, even for StringBuilder will allocate memory. You need to write/find allocation-free alternatives. My answer to this similar question has one for int.

The best way to diagnose where you are allocating memory is to run your game with the CLR Profiler on Windows. This will tell you where and when memory is being allocated. Simply optimise until you're not allocating.

(Or until you're reliably allocating less than 1MB per level/map/room/whatever, and do a manual GC during a time where it's appropriate to stutter - like a static loading screen or a fade-to-black.)

Code 4 is an Unhandled Exception. You need to install a top-level exception handler that outputs a message, or run your game in the debugger, to determine the cause.

Finally: That is probably the compressed size of your textures (using PNG or JPEG or similar). If your textures are uncompressed, 4096 × 4096 × 6 × 4 bytes = 384MB. This is huge - no wonder you ran out of memory. You could compress them with DXT1 and make them 6 times smaller (instructions, wiki). You could also reduce their resolution. And do you need the bottom face at all?