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++?

  • \$\begingroup\$ Rant indeed. Not finding ANY info on the guy and seeing they're (he's?) a startup, I'd like to see any kind of palpable information to back this up... \$\endgroup\$ – Jonathan Connell Jun 27 '11 at 13:37
  • \$\begingroup\$ For reasons I don't fully understand studios don't seem to admit to using XNA. However there are a lot of examples here link \$\endgroup\$ – Tristan Warner-Smith Jun 27 '11 at 13:50
  • \$\begingroup\$ Well, the obvious information to back it up is the fact that the CPU is pretty inherently bad at branchy code, which C# is. What I'd like to know, is, what are the professional XNA users doing that means they don't hit the soft limit imposed by C#? \$\endgroup\$ – Richard Fabian Jun 27 '11 at 13:52
  • 3
    \$\begingroup\$ i can't understand the down vote... \$\endgroup\$ – FxIII Jun 27 '11 at 13:54
  • 3
    \$\begingroup\$ I think a lot of people are downvoting Richard's question because of the (numerous) technical mistakes in his linked article, and some niggling over the word "professional" to mean "Halo-level production" rather than "makes money". The latter is a poor choice but don't downvote just because you disagree with the link - debunk it by answering instead. \$\endgroup\$ – user744 Jun 27 '11 at 16:38

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).

| improve this answer | |
  • \$\begingroup\$ I can't remember myself, but doesn't C# stop you iterating through simple arrays? I remember something about it boxing up first class types like int, float, char, and because of that, some data oriented approaches don't work as fast as they could. Is that right? What am I remembering? \$\endgroup\$ – Richard Fabian Jun 27 '11 at 16:29
  • 2
    \$\begingroup\$ C# will box value-types (not just intrinsics - you can create your own value types) if you assign them to an object type. And in version 1 (before generics) you couldn't put them into a non-array container without boxing them. But these days it's extremely easy to write box-free code. And the CLR Profiler allows you to detect any place where you may be boxing. \$\endgroup\$ – Andrew Russell Jun 27 '11 at 16:33
  • \$\begingroup\$ Is it even possible to have a JIT interpreter? Sounds paradoxical. \$\endgroup\$ – The Communist Duck Jun 27 '11 at 17:21
  • \$\begingroup\$ I've seen a few threaded code techniques I would classify as JIT interpretation. It's definitely an edge case. \$\endgroup\$ – user744 Jun 27 '11 at 19:06
  • 1
    \$\begingroup\$ @Roy T. The "XNA Math Library" (part of DirectX) and the "XNA Framework" are two completely different things with a very unfortunate naming collision. The documentation you linked does not apply to the XNA Framework. The XNA Framework maths types do not use the SIMD/Vector unit. \$\endgroup\$ – Andrew Russell Jun 29 '11 at 3:01

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.

| improve this answer | |
  • \$\begingroup\$ Could you make a crappy Duke Nukem sequel though? ;) \$\endgroup\$ – Jonathan Connell Jun 27 '11 at 14:20
  • 1
    \$\begingroup\$ Most benchmarks find that C# code runs somewhere between 30% and 70% slower than the equivalent C code (on PC). When you consider that most games are not CPU-bound, and also that critical portions of C# code can be written using unsafe code that can run almost as fast or faster than the equivalent C code (faster because the JIT has much more information available to it than a compiler, so it can make better optimization choices), you see that C# is perfectly capable for AAA games. \$\endgroup\$ – BlueRaja - Danny Pflughoeft Jun 27 '11 at 16:42
  • \$\begingroup\$ @BlueRaja: Unsafe code is not an option for most XNA development on the Xbox 360. \$\endgroup\$ – user744 Jun 27 '11 at 16:52
  • 1
    \$\begingroup\$ @BlueRaja: It's worth pointing out that unsafe code is often slower than the safe equivalent, because it reduces the number of optimisations the CLR can make. You have to measure it. \$\endgroup\$ – Andrew Russell Jun 27 '11 at 16:55
  • 2
    \$\begingroup\$ @Blueraja "When you consider that most games are not CPU-bound" citation needed much? I've not worked on a professionally developed game that isn't bound in all axes. if it wasn't we'd find some way to shift the load onto that part of the machine! \$\endgroup\$ – Richard Fabian Jun 27 '11 at 17:08

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.

| improve this answer | |
  • 1
    \$\begingroup\$ High polygon count and HDR would fall on the graphics-card, no? So you should expect exactly the same performance in C# and C++. \$\endgroup\$ – BlueRaja - Danny Pflughoeft Jun 27 '11 at 16:44
  • \$\begingroup\$ @BlueRaja: There's a CPU cost for those too, and memory- especially on the 360. \$\endgroup\$ – DeadMG Jun 27 '11 at 18:22
  • \$\begingroup\$ More or less, there's a bit more overhead on the graphics lib calls than there would be in native code. On the other hand, modern graphics libraries try VERY hard to reduce the number of call into the driver per frame, as it's one of the main bottlenecks. \$\endgroup\$ – drxzcl Jun 27 '11 at 18:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.