XNA is live

Weeee

Although the actual usefulness is only somewhat interesting, as the actual tools have been downloadable for quite some time. I do think this will quell some of the homebrew scene. With this, and the DVD-ROM firmware hack, the homebrew people and the hard core pirates have been split down the middle, at least in terms of methods.

There’s still some motive for the homebrewers to try to hack the system, especially when it comes to making an updated XBMC. Most of the codecs exist in a mix of C and assembly, and would have to be ported to C#.

(Or maybe Managed C++? I’m not sure if assemblies produced from a full VS2005 setup would be usable. Even then, a lot of porting would probably still be necessary.)

The codecs would have to be rewritten from scratch anyway then: the architecture of the 360 is such that the assembly would be poorly optimized, and any non-Microsoft compiler would have to be rewritten to deal with the in-order execution cores.

As for XBMC, there are applications for transcoding and streaming any type of file to the 360 for playing. All that’s required is a copy of the newest version of media player.

Yeah, but that lacks the all-in-one-box appeal of xbmc. I haven’t used the xbox for gaming in forever, but we use xbmc every day.

Bad news – no access to the network on the Xbox with this so no legal version of XBMC. I agree that it would have an awesome move: completely eliminate the overlap between the pirates and the hackers/xbmc guys.

If XNA let you access the network, I’d be so tempted to try implementing a Moonbase Commander clone with it.

Plus, porting that code to C# is just not practical. No way is C# fast enough.

Not true. That’s a fashionable (but false) thing to say, and that myth really needs to be dispelled.

I’ve released an indie game developed in C#, so I can testify that C# is fast enough as I’ve worked with it personally and also done lots of research on this exact topic. Statements that C# is noticably slower are a myth. If anything is a problem, it’s Managed DirectX, which has relative performance issues and is a pretty poor wrapper for unmanaged DirectX.

Anyway, evidence I’ve seen shows that C# is, under normal circumstances, about 95% as efficient as C++ with just a rudamentary focus on optimization. It is possible to design test cases to exploit C#'s weaknesses, and in those rare cases C# can’t compete, but those are very specific, non-real-world problems that play to C++'s strengths over managed code.

The main issue you need to worry about when making an .NET/MDX app for PC is distributing those two things with your game. But you can roll these into your installer, so the only real pain you feel is about a 60MB bloat for your game. In our case, it inflated what would have been a 10-15MB game to about 75MB with all necessary components rolled in fairly seamlessly. But of course that is moot when dev’ing for 360 under XNA.

Arena Wars is probably the best example of a really amazing C# game for PC, though they wisely stayed away from MDX. And that game is 2-3 years old. XNA Racer (demo’d here – check the 12:00 minute mark for a good demo) by the same team is an even more relevant example. XNA Racer is Managed C#/XNA, and what you’re seeing is 1080p with 2x anti-aliasing, being downsampled to whatever resolution his TV is using (720p?)

Porting a video codec though? Trust me, I have plenty of experience with C# – one of the game engines I’ve worked on extensively, Reality Engine, uses C# as its scripting system. And while it’s fast enough, it’s not nearly as fast as writing that same code in C++. For one, its matrix math operators are simply terrible. It’s gotten better since .NET 1.0, but it still has a long way to go before you can write everything in it.

edit: Yeah, that racing game looks promising. I hadn’t expected them to expose that much functionality to the developer. I still think that using C# for something like an H264 codec might be too slow for the 360, but I’m not sure.

Hehe, sorry for the ninja editing. I was trying to put more useful information in there – didn’t mean to catch you off-guard.

I’m confident that someone could actually port those codecs, including H264 , to the 360 using XNA/C# if they really, really wanted to. But it would be difficult and time consuming and not really worth the effort if they never open up networking under XNA.

Also, while C#/CLR has issues with matrix operations, the graphics hardware in the 360 sure doesn’t and a clever programmer could offload a lot of calculations on to the GPU via shaders, which XNA fully supports.

What matrix math operators? C# doesn’t have such a thing. Are you people talking about library methods in Managed DirectX?

Yes, I’m talking about the matrix classes in XNA (which has replaced Managed DirectX). They don’t use passing by ref at all which causes lots of ridiculous temporary object creation that isn’t needed or wanted. Of course, I’m fully aware one could easily implement their own matrix classes with better optimization and the matrix class design of XNA isn’t, strictly speaking, a failing of C# as a language… but I’d still go with trying to offload all of that stuff to the gpu with shaders, considering that the read-back penalty on the 360 is nowhere near as bad as it is on the pc, and gpus are literally made to do matrix operations blindingly fast.

I’m quite sure the matrix classes aren’t going to be your bottleneck. It sounds like you’re bitching for the sake of bitching.

I’m not the one who is even bitching, Scry is! I said the codecs could be implemented in XNA (if someone really wanted to make the effort). So step off!

And FWIW, the matrix classes themselves aren’t even close to being a bottleneck under normal circumstances, but the fact that they create a lot of unnecessary temporary objects which need to be garbage collected actually can quite easily be a bottleneck. C# is plenty fast for most things, but if you abuse object creation the garbage collection can really kill you.

Has anyone bought the 99 deal yet?

Yes, I have.

So those matrices are implemented as value types? How big are they? If it’s just a 3x3 rotation matrix copying won’t take so long. Perhaps those methods need to operate on their parameters, and thus would have to create a copy anyway?

Also, it won’t be affecting garbage collection at all because value type parameters are copied on the stack, not on the managed heap. I can tell you for sure if you point me to the MSDN documentation.

What do you think so far?

The matrices are all 4x4. Still not huge, but still big enough and so often used that it can add up. Also the garbage collection issue I was talking about was due to return values really, not parameter copying.

eg:

Matrix Add (
Matrix matrix1,
Matrix matrix2
)

Adds two matrices, returning a new matrix object with the result… which makes sense, but 99.9% of the time you add two matrices, you want to do it in-place and have the results be stored in one of the two objects that were just added together, not in a new matrix.

In any case, now that you brought up MSDN, I went there to find a link to post here but while looking up the link I just noticed that they actually addressed this in XNA 1.0. Now all of the matrix methods I was complaining about have alternate forms, like this one for Add:

public static void Add (
ref Matrix matrix1,
ref Matrix matrix2,
out Matrix result
)

Which clearly solves the problem. These weren’t there in the XNA beta releases. I guess my bitching and moaning to Microsoft on this issue paid off!
Though I’m probably not the only one who complained.