XNA is live

[zabuni]

Weeee (http://letskilldave.com/archive/2006/12/11/XNA-Launch-Day-is-here_2100_.aspx)

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.

[Fugitive]

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

[zabuni]

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.

[Spam]

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.

[Quaro]

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.

[Damien Neil]

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

[MatthewF]

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

[slantz]

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 (http://channel9.msdn.com/Showpost.aspx?postid=261254) -- 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?)

[MatthewF]

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.

[slantz]

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

[Coca Cola Zero]

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.

[Chris Nahr]

For one, its matrix math operators are simply terrible.

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

[Coca Cola Zero]

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.

[WarrenM]

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.

[Coca Cola Zero]

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.

[Marcus]

Has anyone bought the 99 deal yet?

[Coca Cola Zero]

Yes, I have.

[Chris Nahr]

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.

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.

[Marcus]

Yes, I have.

What do you think so far?

[Coca Cola Zero]

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.

[Coca Cola Zero]

What do you think so far?

It is really cool. They really need to work on some system whereby you can share your games/programs with other people (right now all you can do is give your entire project, source code and all, to someone else who also has the XNA Creator's Club membership), but they've said they are planning on fixing that and the current situation is temporary.

I was working on a basic engine with cel-style line rendering and shadow map shadows on Window/XNA for a few weeks before XNA 1.0 came out (using XNA beta 2) and it only took about 15 minutes to get that code running on the 360. The debugger integration is really slick. Exceptions on the 360 stop the debugger on your local PC, and you can also set breakpoints and do all of the normal VS2005ish remote debugging things.. it just works really, really well.

And despite the fact that my code is really very unoptimized right now, and I'm doing between 8 and 13 rendering passes depending upon how many splits I do for my PSSM shadow maps, it runs hellishly fast on the 360.

[Fugitive]

I was working on a basic engine with cel-style line rendering and shadow map shadows on Window/XNA for a few weeks before XNA 1.0 came out [...] And despite the fact that my code is really very unoptimized right now, and I'm doing between 8 and 13 rendering passes depending upon how many splits I do for my PSSM shadow maps, it runs hellishly fast on the 360.
Man, that makes my plan of making a 360 version of GORILLAS.BAS sound really lame in comparison... ;)

(I mainly just want to get comfortable with the language itself; I'm certainly no game designer.)

[Linoleum]

Hopefully they'll add some sort of vector math framework that lets you take advantage of the Altivec units. Altivec kicks ass.

[ARogan]

What sucks is it's not very backwards compatible with my beta 1 game I did. I've gotta hand port this stuff over to the 1.0 release.

[Chris Nahr]

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.

I looked it up on MSDN. The Matrix type in question is a struct, i.e. a value type. No garbage collection whatsoever takes place with value types, whether as parameters or return values, unless they are boxed to System.Object or nested within a reference type, neither of which happens here. So your worries about imposing an extra load on the garbage collector are unfounded since all those Matrices are created on the stack, just like individual float values.

Not to be rude or anything, but are you aware of the difference between value types ("struct") and reference types ("class")? Because that's, like, the single most fundamental thing about .NET programming. And if you haven't read Jeff Richter's CLR via C# yet you should drop everything, right now, and go buy and read it.

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.

Okay, I can see this issue. But the new static method you mentioned does not actually specify that you can use the same Matrix for the output parameter as for one of the input parameters. I'd test that if I were you. :)

[MatthewF]

Wait, I was bitching? I was merely pointing out the same things as CCZ, and worrying that it might not be possible to port certain codecs over to XNA. I guess I just underestimated how far along .NET and XNA have come.

[Coca Cola Zero]

but are you aware of the difference between value types ("struct") and reference types ("class")?

Not fully! But I am now. FWIW, I was aware of the difference between value types and reference types in the general programming sense, but was unaware that value types are handled fully on the stack in .NET. I'm really a C++ programmer (I wish I could use a lot of my C++ code in XNA and not have to port it all to C#, it would save me a ton of time, but alas...), I've only fiddled with .NET thus far, not completed any major projects in it and a lot of my thinking when it comes to managed languages is hobbled by exposure to Java when it first came out, unfortunately. Thanks for the heads up on the book.

[Coca Cola Zero]

Hopefully they'll add some sort of vector math framework that lets you take advantage of the Altivec units. Altivec kicks ass.

I severely doubt they will ever expose that sort of functionality directly. They might use it themselves in the CF CLR they've implemented, and might give you helper classes that allow you to submit data to do common operations using the altivec units, but they (understandably) seem to be being really careful to minimize the amount programmers can fuck around with things directly to the metal to avoid XNA opening up the gates to Xbox 360 piracy.

[Marcus]

And despite the fact that my code is really very unoptimized right now, and I'm doing between 8 and 13 rendering passes depending upon how many splits I do for my PSSM shadow maps, it runs hellishly fast on the 360.

Man it sounds all kinds of kick ass.