On 4/14/2011 10:06, Warp wrote:
>    I'm wondering if part of the cause isn't XNA and C#. In theory it shouldn't,
> but who knows about these things. After all, all those beautiful ginormous
> games are certainly not done with XNA.

I think that while XNA slows some things down, the graphics probably isn't 
one of them. You have to be a little careful with memory management, but 
there's enough value types that you can usually go without any per-frame 
heap allocations if you're a little careful. The JIT optimizations aren't 
great; certainly nothing like as good as on the PC. I don't know how fast 
the CPU is, but in doing something like loading and decompressing PNG files, 
my 3GHz 64-bit desktop machine runs the same code about 5x to 10x as fast. 
The threading is a little wonky, in that threads won't move between cores 
for example - you start a thread on a specific core and that's where it runs 
(or starves, if you're not careful). I suspect the .NET framework itself 
winds up taking up a fair amount of valuable memory if you're going to do a 
serious game where half a gig is limiting. It doesn't unload code once 
you've loaded it, so if you have a DLL for just posting your high score, 
once you invoke that, it's going to take up memory while you play the second 
round or whatever. (The actual graphics resources like fonts and images and 
sounds can go, tho.)

Note that on Windows, where you can use stuff that's *not* part of XNA, a 
lot of these restrictions disappear, too. They're just on the xbox for 
sandboxing, basically.

But the graphics library itself makes you allocate vertex buffers and index 
buffers, load compiled shaders as byte arrays, etc. It manages all kinds of 
formats for the rendering targets and such, uses the DirectX libraries to do 
a lot of the stuff like parsing .X and .FX files and compressing textures 
and such. So all the underlying stuff is translated pretty much to DX calls 
as far as I can tell. You have to deal with the graphics hardware at the 
graphics primitives level. While there's a lot of simplification going on in 
the library APIs, I don't think there's a lot that's time-consuming that you 
wind up doing in C# itself.

Now if you did something even more sophisticated, like real physics or 
per-triangle collision detection on a significantly-sized world, you'd 
probably start seeing more limitations than I have. But in theory the JIT 
should be able to turn that into code not too far off from C++, I would 
think. Certainly no worse than any other C# code doing heavy math like that.

But the library calls still have you allocating a vertex buffer with a 
declaration of which offsets within each vertex bind to which register in 
the shaders, then filling it in a separate write-only call, assigning the 
textures, then invoking the shader. And (except on the WinPhone) you can 
write your own shaders in a separate C-like language (HLSL) which may very 
well be what folks use to write DirectX shaders in non-XNA langauges too.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message