Notes about XNA

To finish this chapter, here are some additional tips and tricks about the XNA Framework and XNA Game Studio Express. As you saw, you can just start coding and it works great, but it is always good to have a couple of bookmarks for your browser you can rely on when you run into problems or don’t know how to solve a specific issue. Additionally, this section discusses the advantages of .NET and C# a little and checks out the differences between XNA and Managed DirectX.

Important Links

Just a couple of links for your bookmarks:

• http://msdn.microsoft.com/directx/xna/ - XNA Developer Center on Microsoft’s MSDN page with the XNA Game Studio Forum and the XNA Framework Forum, which are the most active XNA forums you will find on the Internet. You can also download the latest XNA version here, read the FAQ, and see what’s new.

• http://en.wikipedia.org/wiki/Microsoft_XNA - Entry on Wikipedia about XNA, constantly updated and contains many links to other topics. On the bottom of the page a few useful external links are listed.

• http://xnadevelopment.com - Nice new site with many links, tutorials, and tips to get you started in the XNA world.

• http://xnaresources.com - Another new site with lots of news and some really useful tutorials on tile engines. Also contains a lot of game components you might like.

• http://learnxna.com - XNA news site in form of a blog, also contains some video tutorials and focuses on learning XNA and tips and tricks with graphic tools.

• http://abi.exdream.com - Official website of the author. You can find more games I made here, as well as Rocket Commander XNA, the XNA Shooter, or the Racing Game from this book, and all the documentation and video tutorials I made for them. Additionally I suggest checking out the Rocket Commander Video Tutorials, which were pretty popular on Coding4Fun.

Is C# Good for Game Development?

There are constantly forum threads on sites like www.GameDev.net discussing the differences between C++ and C#. Usually after a few posts they all end in a senseless language war. Back in the early days of .NET (2002) I discussed quite a lot in those threads, but it was way too depressing when 99.9% of the programmers were on the C++ side and there was no way to convince anyone because they didn’t even take you seriously. The language war does not really have anything to do with C# as a language, except it might have some bad taste because Java failed as a game programming platform except for cell phone games, because both Java and C# are managed languages and look very similar. But if you think about it the same kind of wars happened in the days when C replaced Assembler and C++ replaced C. Even to this day, more than 20 years after C++ was developed by Bjarne Stroustrup, some game programmers still use C and do not really take full advantage of C++. Even if you take a look at the source code for popular game engines like Quake or Half-Life it looks more like C than C++.

This is something really strange in the game programming world; everyone is afraid of losing too much performance by switching to a new language, and additionally might also lose their old code base or have a lot of work converting it to a new language. However, game programmers quickly adopt new techniques and scripting languages, and are always on the very latest hardware developments. One year before Shader Model 4 cards are even available we game developers had Direct3D 10 available and many people checked this out without even having the hardware to run it.

I adopted .NET and C# pretty quickly in the beginning of 2002 after checking out the early betas at the end of 2001. I just started a new game engine and our team had a new project we wanted to do. There were absolutely no graphic engines or anything but some simple 2D games around in the early years of .NET. This made it very hard to use OpenGL or DirectX directly in C#. It required a lot of calls to unmanaged dlls and involved a lot of nasty pointer logic, which is only available in the unsafe mode of C#. In 2003 Microsoft finally released the first beta of Managed DirectX, which made it possible to program new DirectX applications quite easily in .NET. It proved that using Managed DirectX instead of the native DirectX dlls has only a performance impact of 1%–2%, which is really not important if you think about it (just the CPU has a little more work; most games are GPU bound anyway).

However, this did not mean that game developers were jumping on C#; everyone was still very skeptical and even after I released the first commercial .NET game ever, Arena Wars, in 2004, it took another year until more and more developers finally gave .NET another chance. Students and beginners especially really appreciate the simplicity of C#, and more and more people started to develop games in .NET. C++ versus C# discussions still exist and the discussion points are still the same, but the result is more balanced right now (I stopped looking at any topic that has “vs” in the name a long time ago; it is just a waste of time reading the same arguments over and over again).

Always remember this when you run into guys that might tell you C++ is superior and that C# is only for newbies. The same thing happened with Assembler and C++ few years ago, and in the future there will be new languages that make our life easier and there will still be people hesitant to adopt them right away. Most big game studios also can’t just adopt every new technology right away; they might be in the middle of some big project and they also have a very big code base, which is not easy to port. In the long run, however, code will get converted and we will move up the ladder of high-level languages.

Figure 1-15 is an old picture I did to show the differences between DirectX with C++ and Managed DirectX in C#. As you can see, MDX code can be half the size of unmanaged code. For XNA the code would even be shorter and it gets much easier to load textures and show them on the screen, but the comparison to MDX gets harder because the concepts are different.

Figure 1-15

Getting Used to the Content Pipeline

As you saw earlier with your first XNA project it is quite easy to just drag and drop a texture into your game project inside XNA Studio. Although it is nice to have all your game content in one place and directly side by side with the code, there are a couple of things you have to remember. Most projects I saw in my life did not put the textures, models, or shaders directly in the Visual Studio project. The reason for that is the fact that it is much easier to just copy a few files over and then let the game load them directly. By default Visual Studio will also not copy any content files to your output directory; you have to change the Build Action from None to Content and set the Copy to Output Directory setting to Copy if newer. This is quite a hassle and XNA makes it a little easier.

You might even ask why change the way you loaded textures before. If you just want your game to run on the Windows platform, you can certainly load textures and shaders dynamically and without importing them first into your project as XNA content files. This has the advantage that you can change textures or shaders while the game is running (a feature that is not supported by the XNA content pipeline). However, for model files this will not work because there are no load methods other than from the ContentManager class, which only loads compiled .xnb content files.

On the Xbox 360 you can only load content files; there is no support to load textures or shaders directly. If you use direct texture or shader loading, make sure you exclude that code from the Xbox 360 platform; the dlls for the Xbox will not support loading anything but the content files.

For more details about important model files, read the chapters in Part II of this book. This topic is not as easy as using textures. For that reason this section sticks with sprites and 2D textures and keeps things simple. For simple 2D games it is nice and easy, but to write a serious game you will need 3D models and many cool shader effects. I also suggest that you get an artist to do the textures and 3D models for you. It is a quite complex topic and you might waste a lot of time doing all this yourself. Other people might also be more talented doing textures and 3D models; take advantage of your coding skills and let other people do the painting. If you don’t have any artists available, try to use some of the models and textures from this book and the XNA starter kits to get started.

Differences with MDX

If you are coming from MDX (Managed DirectX) and want to migrate your game to the XNA Framework, there is a great guide on the official XNA pages at http://msdn.microsoft.com/directx/xna/migration/.

You can find the same help in the XNA documentation. I won’t repeat all that here, but basically you have to remember that XNA uses right-handed matrices and MDX was left handed by default. Also there are some new classes and structures to make sure you don’t need the Windows.Forms namespace anymore. Because there is no fixed function pipeline support, the old way of working with Windows Forms and handles and thinking of supporting older PC configurations is no longer necessary. Graphics and shaders are discussed in Part II of this book.

Additional Tools and Tips

Additionally you should take a look at the Getting Started help topics in the XNA documentation, which can be accessed from XNA Studio Help Contents XNA Game Studio Express. You can find more information about connecting to your Xbox 360, writing your first project, and about all the starter kits.

As I mentioned before, TestDriven.NET is a nice tool for Visual Studio and test-driven development is a very important methodology in this book (see Chapter 3). Another great tool for .NET development is the Ants Profiler. Unlike all other tools and programs I mentioned so far it is not free, but there are alternatives available on the net, which might help you as well. The Ants Profiler can be used to directly see how much time every single line of your project takes. In my opinion this is much more useful than using some high-level application performance tool like NvPerf from Nvidia, PIX from the DirectX SDK, or using the Performance Counters of Windows. You can quickly figure out why parts of your render code gets slow, detect bugs that call slow methods way too often, and it is always good to review your code by having some new interesting information available.

For more links on the Internet, check out the great collection of XNA links at http://xnadevelopment.com/links.shtml.

There are many more sites about XNA and it seems every day you see a couple of new community sites and more resources. Do a Google search to find out which site is the most popular.