Rocket Commander Game

We already talked so much about post-screen shaders, there is barely space left to talk about the Rocket Commander game. Well, that doesn’t matter so much because the Rocket Commander game has already been out for a year now and there are many tutorials available about it, including the very popular video tutorials series on Coding4Fun (which you can find on www.msdn.com or in any search engine).

It would not make sense to repeat all that again here. The Rocket Commander game is also written in Managed DirectX for .NET 1.1; the game itself runs in .NET 2. Managed DirectX is quite different from XNA - a lot of things could be ported easily, but all the font rendering, sprite handling, and so on is completely different code in DirectX and several features like animated models are not supported yet in XNA (or at least they are not easy to import).

For that reason Rocket Commander XNA only shows the basic engine, but it is still a great game and a lot of fun, even on the Xbox 360 with the Xbox 360 controller, for which the game was never intended. This section only talks about the transition problems from MDX to XNA. If you want to know more about Rocket Commander please visit its website at www.RocketCommander.com and check out the video tutorials. Read the source code and documentation and play one of the many game modifications that exist today.

Performance in XNA

No one believes how well XNA performs. The main reason for that is that most of the XNA games that exist today are just simple 2D games, which do not care much about performance and 3D hardware effects and shaders. The other reason is that many people think it is bad for performance to wrap DirectX to Managed DirectX or XNA, which just redirects the calls to the DirectX base framework. The important part here is how much code you can save and how much easier it is to write games in XNA, especially if you want to do a cross-platform game for both the Windows and Xbox 360 platforms. It would be a lot more work to get all these features by just using C++. You would probably need at least twice as many programmers to get everything to work as fast as an experienced XNA team could create a game. More likely you will also run into more problems with memory issues, pointer management, and overall manageability in an unmanaged environment.

I have proven in the past that most programmers are just plain wrong assuming Managed DirectX is a lot slower than DirectX; it does not really matter. If your code uses 100% of the GPU and 100% CPU you probably don’t have a game, but just a benchmark to stress test or play around. Even in these situations Managed DirectX reaches almost the same performance (98%–99%), but for a real game it does not matter anyway because you will not have time to optimize every single line of your code. Instead you will focus on the important parts and try to get 10%–20% of the code, which is called the most often, to work as fast as possible. Adding performance improvements to the other 80%–90% takes five times longer and the improvements would only bring you a very few percent better frame rate.

Instead, you should focus on the game itself. The gamer does not care if the game runs at 59 or 58 frames; he wants a fun game and if you allow different settings he can even minimize the resolution and disable effects to get to a higher frame rate. Too many games today only focus on the graphics (like I do in this book, but at least I try also to show many cool game ideas, and hopefully you can use the base code and make your own games without writing graphics engines for a long time without writing any new game).

Anyway, the Rocket Commander code was heavily optimized and I did a lot of performance tests back when I developed the first version. The whole game was also coded in just four weeks and it is not always easy to get the most out of the shaders if you have such little time. I still managed to get over 100 frames per second on a medium PC with a Shader Model 2.0 card and a high screen resolution while showing up to 5000 asteroids (in some cases over 30 million polygons were rendered each second) at the same time each frame including collision testing and some other effects. Lower-end PCs, even ones completely without shader support, were still able to run the game. It did not look as pretty, but it ran very nicely.

Today computers are even faster and CPUs have multiple cores, which can be used to execute several tasks at the same time. The Xbox 360 has three cores too and it uses six threads, which execute all the game code you need. I don’t know of any game today that really needs this immense CPU power on the Xbox 360; the GPU is pretty fast too, but especially on high resolutions it is still the GPU that will prevent you from getting better frame rates.

The Rocket Commander game is actually a nice example of how to split the work into two cores. The physics calculations and the pre-testing if asteroids and sectors are even visible take up half of the CPU time (sometimes even more). The rendering plus additional effects take the other half of the CPU time each frame. The physics can be done in parallel to the rendering because all the physics calculation checks is whether two asteroids intersect with each other and in that case, it bounces both of them off (see Figure 8-20) and makes sure they don’t intersect anymore.

Figure 8-20

The next frame the newly updated physics positions, movement vectors, and so on can be used, which is only a slight disadvantage because the physics is now calculated for the next frame and not for the current frame (it would be too late trying to render the new physics positions because most of the asteroids will already be rendered when the physics update is complete). As you can see in the image you don’t have to check every asteroid, only the ones near to each other, and this can even be optimized further by putting them into sectors, which helped to improve the physics performance by a factor of 10 in the original Rocket Commander.

The important thing here is that Rocket Commander XNA performs even better than the original. It is possible to play the game in HDTV 1080p resolution on the Xbox (or the PC) and still use all the graphics effects, use full anti-aliasing, and show several thousand asteroids at the same time at very high frame rates.

Moving from MDX to XNA

The base engine of Rocket Commander has quite similar concepts to the XnaGraphicEngine. In some places there are more features in the Rocket Commander engine like animated models or better handling and rendering of many asteroids. For example asteroids all use the same shaders and materials and allow the game to render them in a very efficient way. But some other features are implemented in an easier and better way in XnaGraphicEngine than in Rocket Commander like the font and sprite management in XNA. You also can take advantage of the new shader classes you wrote and you can even plug in new shaders if you want to play around with the visual appearance of Rocket Commander XNA a bit.

Please also note that some features like the animated model support or the occlusion testing for the lens flare effects in the original Rocket Commander are not possible in XNA yet. The occlusion testing is something that is just missing from the XNA Framework. I would guess it was too hard to get it to work on both the PC and the Xbox 360 the same way, but it is still bad for the lens flare effect because it will no longer disappear and blend in and out when an asteroid moves in front of the sun. The animated model can still be done by doing custom model processing or even introducing a new format for all the models, but you want to keep the port as simple as possible and you certainly don’t want to re-export every single model and re-test it all over again.

The network code of the game was also ripped out in the Xbox 360 version because there isn’t any access to the System.Net namespace on the Xbox 360. On the Windows platform the game still sends and receives high-scores to and from the Internet server via web services. All the levels and other game data is 100% compatible and even porting the mods to XNA would be possible, but I have other things to do. Feel free to write more Rocket Commander mods, especially on the XNA Framework. I’m always happy to receive emails from people all over the world using the code, writing mods, and telling me success stories by learning from the tutorials and the source code.

At the end of 2006 I wrote a long blog post on my website comparing MDX with XNA and talking all about the advantages and disadvantages of using XNA. If you worked with MDX before and are still wondering if XNA is worth the effort, read this article. In Rocket Commander XNA some new features were added, especially more unit tests and the multithreading that I will talk about in a second, but the overall number of source code lines decreased by more than 10%, which shows you that even porting a project makes it simpler. This effect is obviously even greater if you start fresh with an XNA project.

Using Threads to Improve Performance

The overall performance of Rocket Commander XNA is great on both Windows and the Xbox 360, especially when just doing some benchmarks and performance is absolutely perfect. The GPU is pushed to its limits and there is no reason why you should be afraid of Managed code. Windows performance is especially great; all my programs and games are completely GPU bound even in low resolutions and even when they only have one thread.

On the Xbox 360 the performance is a little bit worse and you have to take many things into consideration, which is hard because there is again not much documentation around. For example, the worst thing you can do on the Xbox 360 is to generate new data each frame, and even if you just create an enumerator by executing a foreach loop, it will affect your performance. The good thing is that you have three cores (and six hardware threads) at your fingertips, which allow you to optimize performance. It was possible for the Rocket Commander game to optimize the game loop a lot because the physics and update threads eat up almost 50% of the CPU time. On the PC it does not matter much because my GPU is slowing everything down (see Figure 8-21), but on the Xbox 360 I was able to almost double the frame rate using multiple threads. Nice.

Figure 8-21

Result and Screenshots

Rocket Commander XNA is a great game and it runs even better than the original, and it has now support for the Xbox 360 and the XNA Framework on the PC. Thanks to the new multithreading ability of the game and the fact that you can split up the physics and the rendering engine so easily, the game performs a lot better than before, the physics are now more precise, and the rendering engine has more time to render more asteroids if you like or add other cool effects.

Both games look so similar that it is hard to tell the difference between the original game and the XNA port. You will probably detect it only through the missing features (like animated models and occlusion checking for lens flares) or by just looking at the new game font. I added the XNA logo in the main menu to tell the difference between running the original game and the XNA version (see Figure 8-22).

Figure 8-22

I hope you have fun with the game. It is freely available like the original Rocket Commander game and you can use it for your own game ideas or just play around with it a little. Check out Figure 8-23 for a screenshot of Rocket Commander XNA in action.

Figure 8-23