Upcoming topics are:
* Python, C#, and Beginners
* Developing a Graphics Driver III
* SlimDX Status Update
Why I don't like XNA
First, let's make sure there aren't any misconceptions. I think there's a lot of great things about XNA. It's really easy to get up and running, whether you're a beginner taking first steps, or an experienced developer doing rapid prototyping. If you are just trying to learn, or if you're just playing around and testing things, XNA is a beautiful, fun, and comfortable environment to work in. If any of that describes you, then what I'm about to talk about probably has absolutely nothing to do with you. Keep that in mind as you read.
On the other hand, if you're the sort of person who intends for other people to play your games, XNA has some rather serious problems. You can develop games in XNA and release them easily enough -- but I don't think it's worth bothering. There's too much of a disconnect between XNA and reality. If this is your intent, then what I'm about to talk about has everything to do with you.
XNA is first and foremost an API designed for the Xbox 360. There's no sense trying to avoid this fact. The reason it's this way is simple. The basic goal of XNA is to allow you to write basically identical code for Windows and Xbox, and have it run fine on both. The only way to do this is to force a least common denominator, and while the abstraction is leaky, the basic principle remains. And as a practical matter, the Xbox is the source of most of the limitations of XNA. It is a console, after all, and doesn't need to support the vast array of things that Windows does. Now of course the Xbox is capable of a few things that the PC isn't, but those aren't really exposed either. And then there's a few things that fall through the cracks just because the implementation is rather different between PC and Xbox -- occlusion queries are missing, for example.
So when it comes to making XNA based games, there are two possible alternatives. You can be developing for Windows, or you can be developing for Xbox. The two are not exclusive, of course. But no matter which one you're doing, there are some serious problems once it comes around to actually giving your game up for other people to play. Now up to this point, I've been rather vague and general. Let's get down to details.
First, the Xbox, because this is by far the more stupid platform to screw up. In order to develop for the Xbox, you need to join the XNA Creator's Club, which runs a hundred bucks a year. Fine, whatever. Paying such a small sum to develop is not a big deal at all, considering it's a tiny, tiny fraction of what a real devkit costs. (Plus unlike a real devkit, you can actually get one.) There are two basic problems though. First, everyone who is interested in playing your game must also be an XNA CC member, because that is the only way to get hold of the XNA Framework on your Xbox. So we've already excluded very nearly all casual and hardcore gamers, because neither of them are interested in paying that money just to play the indie games -- most of which aren't any good to begin with -- that might pop up. You're left with just other XNA developers, and the truth is that most of them are too busy making their own bad games to play yours. The second problem is that the XNA Framework on the Xbox is so closely linked to the dev tools that in order for anyone to play, they need your full source code and source assets. Then they need to build the game, connect their Xbox to their PC and transfer the files, and only then can they play. Update: I've been informed this is no longer true.
So ask yourself. Who is really going to bother? Have you bothered to play anyone else's XNA games on Xbox? I haven't even signed up for Creator's Club, because I'm not interested in paying to make games that no one can play anyway. Might as well stick to Windows.
XNA on Windows has its own problems, though. The only reason that these problems are not lethal to XNA games running on Windows is because, unlike on Xbox, we can actually use libraries other than XNA when running on Windows. The real irony is that the main library you end up using is, in fact, Managed DirectX. (By the way, your users now need both the DX and XNA redist packages!) And why do people end up with MDX code in their XNA games? Well, there are two reasons, and they both start with X: XInput and XACT.
Unless you're really out of things, you know what's wrong with XInput already. It's a great API, as long as you're using an Xbox controller. Not everybody has an Xbox controller. There's hundreds of non-XI compatible peripherals out there which people like to game with. I have a Thrustmaster controller I rather like. A lot of people use Logitech's Dual Shock knockoffs, or just connect an actual Dual Shock via a PS2->USB adapter. And let's not forget all the people with flight sticks, steering wheels and pedals, and all the other sorts of game controllers out there. Heck, some people might even like force feedback support once in a while. The end result is that you're forced to pull in DirectInput in order to give people the chance to play with anything other than keyboard and mouse. (This of course sucks even worse because DInput is such a miserably painful and unwieldy API. SlimDX doesn't support it yet either.)
And then there's XACT. It's not a great API by any stretch of the imagination, and the XACT Authoring Tool can be a really, really frustrating tool to work with. Put all that aside though. The real insult and killer blow is the format support. See, XACT will take your source files and shove them into these special files it has. It does a format conversion to something it can handle, and then lets you load them nicely at runtime without having to deal with decompression and decoding. XACT, like XInput, came from the Xbox. On the Xbox, it supports two compression formats. One is ADPCM, which is a simplistic lossy compression algorithm that can hit ratios up to 4:1. The tests I ran showed that a typical ADPCM file was about 4-5 times larger than a similar MP3 at 128 kbps, which is clearly far too large for music. The other format XACT supports is XMA, which is some sort of variation of WMA which can be decoded in hardware by the Xbox. Here's the catch: XMA does not work on PC, and there's no replacement. So your compression options are ADPCM, and...no, just ADPCM. Using XACT on PC, 5 minutes of music will probably cost you around 20-25 MB. Better hope your players have high bandwidth connections. Your best alternative is DirectSound coupled with either Ogg Vorbis or DirectShow.
It's also the case that I have some technical objections to design decisions made for XNA. I'm not going to elaborate on those points, though, because they pale in comparison to what I've discussed. (Although the occlusion queries thing really bothers me. They're generally considered fundamental to modern graphics engine design.) Right now, XNA simply isn't viable for anything except learning or prototyping.
Will things be fixed? I don't know. In principle, it shouldn't be too big of a problem to patch XACT up to be more useful, but there's rumblings of a new API, XAudio 2, that will be used for XP, Vista, and Xbox. If that's the case, then XACT may be nothing more than a stopgap. XInput won't ever gain support for non-Xbox controllers, and I don't think it should. As for the Xbox, I have no idea which of those restrictions are technical and which are intentional business decisions. All I know is that I won't be writing games in XNA anytime soon.
It seems to me that it was built for one thing: games. Which is fine, and makes perfect sense because like Promit pointed out: it's an XBOX 360 API. But for us windows weenies, some of us like to write editors and such for our libraries. And it seems people have difficulty even just binding to a Winform, this shouldn't be a difficult thing to achieve.
I could be wrong in my viewpoint, but in so far as the things I've read it seems like it's a hack to do anything worthwhile. Plus you lose any benefits that go with XNA. So, really, what's the point?
Overall, I think XNA is honestly a very good first attempt. They (Microsoft) just really need to rethink a few things on the next version or two.
And don't even get me started on the Visual C# express requirement....