Rom's Rants

Saturday, October 27, 2007

XNA and VB, One Year Later

Over the last while, I've ranted and raved about Microsoft's XNA Game Studio Express Edition not supporting Visual Basic .NET.

Now that the ZMan is updating again, I've noticed a new post about some really poor communication skills from the XNA team about VB.NET support. He links to a great XNA/VB rant from a Microsoft MVP about it.

Now, awhile back one of the Microsoft guys said that the reason VB wasn't supported on the Xbox 360 was because VB used some features of the CLR that their version of the Compact Framework didn't support. I think I finally figured out what it was, and if it's the case, we have only our older VB6 brethren to blame.

The XNA team could have easily said that you couldn't use "My" on the 360, even though it's supported in the full .NET Compact Framework. They could have easily said that the Microsoft.VisualBasic namespace couldn't be used on the 360, and we would have adapted, even though it is also supported in the full .NET Compact Framework. But remember back in 2001 when the value of True was a big deal? It does make me wonder what other "hacks" were put into the full CLR to support the older VB6 way of doing things.

I love VB.NET with a passion, but over the last couple of years I have started to lose my faith in VB's future. When you look at many of the new features that are coming into the .NET Framework, the syntax that is being used to bring these features into VB is becoming more and more tortured, and some language constructs now go against best practices. (Using "Handles" with WPF applications means that you aren't using the WeakEvent pattern, for example.)

So as a result, we're going to have to move back to the realm of VB hacking to get things done...even though we no longer have that VB hacker icon to follow. If you want to use XNA and VB, you can check out Alan Phipp's page for now, but if we want full access to the managed world, we're going to have to tell Microsoft two things. One, it's okay to let the VB6 way of doing things die, and two, .NET-capable technologies that Microsoft releases must support all languages that are supported by Visual Studio out of the box.

Teams like the XNA team and the Windows Home Server team may only have the funding to support one language, but if something like that is detected inside Microsoft, the platform evangelism teams should step up to the plate with either funding or staff to help them support the other languages. After all, language diversity doesn't mean anything if Microsoft is only going to be giving us items we can use with C#.

Labels: Rant, Visual Basic, XNA

posted by Michael Russell at 10/27/2007 11:36:00 AM | 2 Comments Links to this post | View blog reactions

Thursday, November 09, 2006

[XNA] Content Pipeline Pros/Cons

I downloaded Microsoft's XNA Game Studio Express Edition Beta 2 last week while I was on my trip, and I've spent the last week messing around with it, going over the documentation, etc. There's a lot to like and a lot to dislike. Here are my initial impressions.

Pros

1. Strongly-typed loading. Each asset is serialized as a binary asset, and as a result, asset loading is not only quick, it's type-safe. The larger and more complex the asset, the better this is.
2. Extensible. The content pipeline was designed to be extended in every which way possible. For most items, composite objects are going to be the the name of the game because a lot of the commonly built functionality is already embedded into the framework. If you need extra functionality above and beyond what is there, for most things it will be easy enough to add it yourself.
3. (Mostly) self-configuring. It's nice to be able to add an asset and (most of the time) have the proper settings already set on the importer/converter.

Cons

1. .XNB. Whoever had the bright idea to make everything have the same extension and have to individually rename assets inside the IDE needs to be strung up by their testicles and flogged in public. It is very common to have a model in a folder with the appropriate texture having the same base name (chair.fbx/chair.tga for example). The reason for this is because if you don't have the files in the same folder, most modelling software freaks out with the texture paths.
2. No included packed file system. True, you can subclass the ContentManager to make your own packed file system, but the time savings from loading a strongly-typed serialized file are more than offset by slow individual file access times (due to security lookups, etc.) For small projects, this isn't that big of a deal, but once you start getting into asset counts in the 4- to 5-digit range, it matters.
3. Not team-friendly. Bear with me on this one. Converting an .FBX file to a model, or a .TGA to a texture takes little to no time, but when you have custom asset importers to handle certain items (lightmaps, pathfinding precalculations, visibility), the time it takes to process these items increases by several orders of magnitude. We aren't talking seconds...we're talking hours EACH. One of the primary purposes of any asset pipeline is that this time cost is paid one time per iteration of the asset. With the current XNA Content Pipeline, each person who gets the asset is going to have to pay the time cost unless they use source control, which leads me to...
4. Not source-control friendly. Now, Visual C# Express Edition does not support source control, but you can still use an external source control solution. The nice thing is that you can eliminate the extra time costs via source control. The downside is that to get this time savings, you have to check in not only the asset and the compiled asset, but the intermediate "temp" file as well. Then to do an iteration, you have to check out all three files, do the build, and then check them in again.
5. Documentation still fairly weak. Just try finding the information you need to write an image importer inside the documentation...be prepared to delve through over a dozen help topics and even then you'll have to go through and do it by trial-and-error.
6. Plug-ins. Don't get me wrong, I love the idea of plugins. My major issue here is that they seem to have missed one of the strengths of .NET. If I create a control in a Windows Forms project, I compile and then that control is available for use in my toolbox automatically. The IDE uses reflection on the compiled assembly and lets me use the control appropriately. If I'm writing plugins as part of my game, why do I have to then reference the plugin DLL through a setting?
7. Still haven't found a way to hack it to work outside of Visual C# Express Edition. I will find a way...

Labels: Content Pipeline, XNA