What Does XNA Lack?

The lack of 3D audio really hurts, IMO. Support for something other than ADPCM on PC from XACT would be nice too. (Yes, you can use DSound and DShow, but that's such a total pain.) Interop capabilities and relaxed security restrictions on the professional version of the product are something I'd want as well.

Oh, and I'd expect them to make up their mind about whether XNA Build or XNA Content Pipeline is the build chain to use.

Yeah, I actually found it hard to believe they didn't include 3D audio in it. I spent a couple of hours looking in the internet hoping I was just getting something wrong. What was the point of that anyway? Wasn't it in some beta versions before 1.0?

Absolutely nothing for some types of games. However the types of games that might run into some problems with it would be games that rely on high amounts of frames per second or using modern graphics. I personally don’t think C# running on the .net platform will compete with unmanaged C++ for sheer processing power. Then again the last benchpress tests (not sure if they were legit) I saw had managed C# running only 8 or 9% below C++ so its not to far behind.

Just as a quick edit on my post I didn't know they decided not to include 3D audio, but yes that would hurt it quite a bit.

Quote:

Original post by Riya Absolutely nothing for some types of games. However the types of games that might run into some problems with it would be games that rely on high amounts of frames per second or using modern graphics. I personally don’t think C# running on the .net platform will compete with unmanaged C++ for sheer processing power. Then again the last benchpress tests (not sure if they were legit) I saw had managed C# running only 8 or 9% below C++ so its not to far behind.

Oh god please. Not another one of these threads...

Im a C++ Umanaged DX programmer, and Ive seen the same tests of 9% to even 2% decrease in speed, although speed dosent translate into money, time does.

At this point, I'd say good documentation and a body of work written by the community. It's difficult to figure out how to do some of the simplest things. Not necessarily because XNA is difficult, but only because it's hard to find someone else who has done what you're looking to do.

*Networking component.
*Displaying video.
*3D audio.

I'm going to agree with documentation. It's the reason I finally dropped Managed DirectX and went back to C++.

Actually, documentation is a problem. It didn't matter whether you had docs for MDX or not, because the API was identical to native DX. XNA, on the other hand, diverges a bit. Then there's the game framework and component junk, which is a whole problem of its own.

[Edited by - Promit on December 27, 2006 10:59:00 PM]

And where is the updated migration guide for those of us trying to migrate from MDX 1.1 to XNA?

Quote:

Original post by Promit Actually, documentation is a problem. It didn't matter whether you had docs for MDX or not, because the API was identical to native DX. XNA, on the other hand, diverges a bit. Then there's the game framework and component junk, which is a whole problem of its own.

Reflector is your friend. Sad maybe, but it works.

For the rest I can only agree with this. It's not so much that XNA lacks something, it's more of a question what limitations XNA enforces, be they needed for 360 support or simply not implemented yet/reserved for XNA Prof. The game framework and component stuff lost a lot of its added value and appeal as the designer and component management was scraped. As Benjamin also reported, occasionally it feels like one is wrestling with the pipeline and other parts of the API rather than coding a game. Do check the link to Ben's blog, it contains some goodies and a nice write-up on the pros and cons of XNA vs MDX.

I'll put in my current list of woes:

- Content pipeline isn't quite what it should be
- Lack of 3D audio
- No MRT's supported on 360


And finally, the performance characteristics on the 360 seem to be a bit sketchy. I just got a 360 and still have to set it up for XNA so this is hear-say, but going from Ben's notes and reading this and that, there seem to be some serious pitfalls with the CF on the 360. If we actually have to resort to inlining methods and using pooled structs instead of class-objects, that would detract a bit from the whole "clean managed code thing".

But enough with the doom and gloom, gotta come up with a game idea before January! [smile]

My personal wish (very personal) is a WPF renderer. It would be awesome to design a User Interface in Expression Blend and simply push the resulting Xaml/Code into the content pipeline so there would be an easy way of designing user interfaces.

Cheers

BTW: I've thought of implementing a renderer myself, but hey, MS did that already...

I'm praying for WPF also.

So many games are made with Flash that it seems like a no brainer to bring over WPF or at least WPF/E.

Quote:

Original post by Promit Oh, and I'd expect them to make up their mind about whether XNA Build or XNA Content Pipeline is the build chain to use.

I actually asked a question about this on the msdn forums ... the response was pretty interesting:

Quote:

Shawn Hargreaves on the XNA/MSDN forums Yes, there's quite a bit of overlap, both in terms of the problem space (incremental build, tracking relationships between meshes and textures and so on) and the underlying technologies such as MSBuild. Not really surprising considering that a lot of the same people worked on both systems! The big difference is in the amount of policy imposed by the solution. XNABuild and ARM are policy-free. They can slot into pretty much any existing system, and be used with any workflow you could possibly imagine. The downside of which is, you have to do a fair amount of work and write a fair amount of code to get them all hooked up to your particular infrastructure. The content pipeline takes a different approach here, imposing much more policy right out of the box. This allows us to do way more stuff for you automatically, for instance we can handle all the Windows vs. Xbox differences for you. Using XNABuild it would be up to you to define a target platform, make sure you set this appropriately, define what possible targets are supported, and write code to do the appropriate endian flipping, but the Content Pipeline comes already set up with Windows and Xbox targets, for instance.

Oh, and I too think that a WPF importer would be tres cool ...

Occlusion culling! >:|

Let's not forget built in support for fonts.

I know a lot of people consider Xna to be a replacement for mdx, but I simply can't agree. Xna's goals are laudible, and I look forward to the day I see my code running on a 360, but in terms of capabilities it simply doesn't match mdx.

No fonts, no occlusion queries, no 3D audio, no video playback, no networking. Hopefully they get added in the future. The lack of a fixed function pipeline irritates me too, but I know the 360 doesn't have one and it's the future of graphics programming.

I've used Xna a lot, and while yes, it does have a cleaner api, it's not necessarily that much easier either. The only real difference in difficulty is that Xna handles device and window creation for you. You still need to understand the principles of graphics programming, and that's by far the hardest part. The api is just candy.

So while I'm using both xna and mdx, if someone twisted my arm and made me choose, I'd stick to mdx, hands down. Xna is a nice library, but over hyped, and I think the novelty will wear off.

BTW: I'd also love to have Windows Workflow Foundation (WF) to program/design AI decision trees and event/state machines in!

It seems that people want and need more power over their application than XNA can give. At the end of the a lot of people are going to want to do their own thing with Unmanaged DX, and they don't want any control taken away from them.

I don't know very much about this yet, but couldn't you just load and use a third party wrapper assembly into your project for sound, physics etc? I've been searching the internet and I've found tons of managed wrappers for libraries originally written in unmanaged code.