XNA and C# vs the 360's in order processor

Question

Having read this rant, I feel that they're probably right (seeing as the Xenon and the CELL BE are both highly sensitive to branchy and cache ignorant code), but I've heard that people are making games fine with C# too.

So, is it true that it's impossible to do anything professional with XNA, or was the poster just missing what makes XNA the killer API for game development?

By professional, I don't mean in the sense that you can make money from it, but more in the sense that the more professional games have phsyics models and animation systems that seem outside the reach of a language with such definite barriers to the intrinsics. If I wanted to write a collision system or fluid dynamics engine for my game, I don't feel like C# offers me the chance to do that as the runtime code generator and the lack of intrinsics gets in the way of performance.

However, many people seem to be fine working within these constraints, making their successful games but seemingly avoiding any of the problems by omission. I've not noticed any XNA games do anything complex other than what's already provided by the libraries, or handled by shaders. Is this avoidance of the more complex game dynamics because of teh limitations of C#, or just people concentrating on getting it done?

In all honesty, I can't believe that AI war can maintain that many units of AI without some data oriented approach, or some dirty C# hacks to make it run better than the standard approach, and I guess that's partly my question too, how have people hacked C# so it's able to do what games coders do naturally with C++?

Answer 1

OK, just to poke some holes in that rant you linked:

• "C# relies on a "Just In Time" interpreter" - wrong - it is a JIT compiler. After a method is JITted once, the compiled code is reused for each invocation. The compiled code is very close to as fast as native, pre-compiled code.
• "Xenon CPU is an "in place" processor" - does he mean "in order"? - And: "Xenon CPU has no branch prediction". He implies these mean that JIT compiling naturally produces bad code that must be re-ordered by the CPU and causes lots of branching - which is absolute nonsense. The same performance advice for running on this CPU architecture applies to both C++ and C#.
• "[JIT] requires constant flushing on the 360" - wrong, the compiled code can be kept in cache like any normally compiled code. (If he means pipeline flush, see the above point.)
• "generics [...] use code generation" - generics are JITted like everything else and, like everything else, the JITted code is fast. There is no performance penalty for using generics.
• "all the sexy bits of language [...] require either branch prediction..." - how does this not apply to C++ as well? - "...or [...] in-place code generation" - does he mean JITting? Did I mention that it's fast? (I won't go into all the places the desktop CLR uses actual code generation - a feature not supported by the Xbox 360!)
• "[C# doesn't have] the massive libraries [of C++]" - except, say, XNA itself? And plenty more. (Still, this is a somewhat fair point.)

XNA on the Xbox 360 runs on a modified version of the .NET Compact Framework CLR. I have no doubt that it's not up to the standard of the desktop version. The JITter probably isn't as good - but I don't think it's bad either. I'm surprised he didn't mention the garbage collector which is dreadful compared to the desktop CLR.

(Of course - you shouldn't be hitting the garbage collector in a professionally developed game anyway, just as you must be careful with allocations in any professional-grade game.)

(For actual technical discussion of the .NET Compact Framework, perhaps start with this article series: Overview, JIT Compiler, and GC and heap.)

The way he is entirely unspecific about his terminology makes it difficult to even understand what he means. Either he's in maximum-rant mode, or doesn't know what he's talking about.

---

Now that we've got that out of the way, here are some things that you do miss out on by using XNA on the 360, rather than going native:

• Access to the SIMD/Vector unit for doing really, really fast CPU floating point maths
• Ability to use native language code that will probably be a little bit faster than C#
• Ability to be a little bit lazier with how you allocate memory
• XBLIG games have access to only 4 of the 6 cores (but we still get all 3 CPUs, and they're not full cores either, so we don't miss out on much) - not sure if this applies to non-XBLIG XNA games
• Full DirectX access for doing really obscure graphical trickery

It's also worth pointing out that these are only CPU-side restrictions. You've still got completely free access running on the GPU.

I described these things in this answer to what is effectively the same question as this one. As I mentioned in that answer XNA is absolutely suitable for "professional" development.

The only reasons you'd avoid is is because you can't hire C# talent, licence C# engines, and reuse existing C# code the same way you can with the existing base of C++ knowledge. Or because you might also be targeting a platform that does not support C#.

Of course, for many of us who aren't "professional" developers, XNA is our only option to get on the Xbox 360, making the point moot.

---

To answer your other questions:

Nothing in C# stops you using data-oriented approaches in essentially exactly the same way you'd use them in C++.

C# lacks the ability to automatically inline code at compile-time, and (without going off to check) I'm pretty sure the compact CLR's JITter can't inline methods (the desktop CLR can). So for performance-critical code you may have to manually inline in C#, where C++ provides some assistance.

Probably a bigger reason why you don't often see CPU-maths intensive things like collision detection and fluid simulations in C# is lack of access to the vector unit (as mentioned above).

Answer 2

You'd have to define 'professional'. Could you do Angry Birds, Plants vs Zombies, etc? Absolutely. Could you do Crysis 2, COD, Halo? I doubt it. Using C# is only really going to impact games that are very CPU intensive and also need to squeeze every last byte of of memory (you lose out to the garbage collection), so there's an awful lot you can still do.

As a learning tool for people getting started, prototyping tool, platform for writing games that can deal with the trade off, etc, it's fantastic and has a lot of power and simplicity, it just isn't designed to make what you'd necessarily call the 'AAA' games. It also takes away a lot of the pain and suffering people have to worry about with cross platform porting and compatibility.

If you come up with an amazing game and you run into the limitations of what you can do with XNA then I'd suggest contacting MS directly, if the idea really is good enough they might just let you get your hands on a full blown development kit.

Answer 3

The simple fact is that you don't need a high polygon count, full HDR lighting or the world's most interesting physics to make an interesting game, and if your game plan doesn't include any of those, then why not go for a faster development time solution?

more professional games have phsyics models and animation systems

That's just wrong. Professional games have what they need to have to implement their gameplay and achieve their artistic look, and nothing more and indeed, nothing less. A game isn't more professional because it looks more realistic or has more detailed physics. A game that is professional achieves it's gameplay and visual objectives, on time, on budget, etc, and ships and makes a profit.