The image on the left is a render of Suzanne from Blender, and the one on the right is a render from within the Windows build of my current codebase. No more distortion! The distortion was caused by incorrectly creating the Quaternion rotations from the x, y and z planes in the Collada model which, when combined with my translate and scale transformations, caused all kinds of weirdness.

I would never have got this far without PIX, I think I quite like it!

The above is a screen capture from the windows version of my current code-base. Blender-heads will recognise the (slightly distorted) image of Suzanne, the built-in Blender equivalent to the teapot model.

PIX was able to show me that I was not passing my transformation matrices to the correct parameter in the vertex shader. As a result they all defaulted to empty matrices and every vertex position output from it was then (0,0,0). I was simply telling my effect technique to use the wrong vertex shader in my .fx file, and that shader expected the “WorldViewProjection” parameter. Unfortunately, I was populating the “World”, “View” and “Projection” parameters!

After fixing the error in my .fx file, I managed to render something. And a quick Visual C# debug session later, I realised that I had a silly bug in the parsing code I use to pull the data out of the Collada files. And now I can render a monkey!

There’s clearly some work to be done to fix the distortion issues above but real progress has been made. I’ll fix those issues, tidy up the code and probably release a simple demo just for people who are interested.

I’ll be continuing the Blender and XNA series soon which should help those who wonder how I have achieved the above.

I’ve posted an update to this.

I mentioned that I was just getting the following output from my current rendering code:

I had posted on the XNA Forums that I was “completely in the dark” as to what was going on after a call to draw my model. The suggestion there was to use PIX, which is part of the DirectX SDK for Windows. Well, one 438MB download later and feeling like a challenge, it seems PIX has helped me at least identify the issue.

I am sending the position, normal and colour information to the graphics device plus the indices to tell it how to arrange that data into triangles. Well for testing purposes, I have told it to draw 1 triangle and I seem to be getting the right size vertex buffer to be passed to the graphics device but all its values are 0.

This essentially means I am drawing an object so small it has no dimensions, in black and on a black background. Working as intended then…

I am clearly missing the point somewhere when I construct my VertexBuffer in my ContentProcessor but at least PIX showed me the way!

I’ve posted an update to this.

One thing that will cause glitches in XNA games is if the garbage collector kicks in at an inappropriate time so a strategy to avoid this needs to be adopted quite early on in development of your game engine.

An excellent post by Shawn Hargreaves gives an overview of two distinct strategies to reduce the impact of garbage collection on your code. By picking one of these and sticking to it, you can either ensure that when garbage collection occurs, it doesn’t affect performance adversely or avoid garbage collection altogether.

Approach 1

Don’t allocate anything. This sounds quite hard to achieve but it isn’t as difficult as it sounds. You can allocate memory still (your game will be pretty limited if you cannot) but you allocate it all up-front.

The challenge with allocating everything up-front is that you have to know before-hand in your game how many objects you will need exactly. Well that’s pretty straightforward for storing something like meshes as you will know at compile time how many you need. It’s when you want to show multiple instances of those meshes on-screen at runtime that you are faced with a problem.

For example, if you have a car model and want to show a street scene in your game, you may wish to re-use that car model to place 3 cars on the road at night but put 20 on the road at peak times. You’ll need to allocate enough of those objects during the games initialisation to deal with all possibilities.

Approach 2

Allocate what you want, whenever you want but keep the managed heap simple. Each time you create a new object and store the reference, that is one more reference the GC needs to keep track of. The more references you have, the longer GC takes – bad news during a screen update. A lot of data with plenty of references to other objects is going to slow things down come GC time and the fact you are constantly allocating means that GC will occur sooner or later – always when you least need it.

To keep references to a minimum, you could use arrays to store your object collections and use a simple integer reference to link them instead. See Shawn’s post for more details.

My choice?

I went for Approach 1 – don’t allocate mid-game. The main reasons were that Approach 2 required that I maintain references between objects using integer indexes to look-up a required object in a collection. That then means that I have to manage those references myself. I find that idea a little crazy as c# is more than capable of maintaining those references out-of-the-box and the idea that I would ditch that and implement my own reference management code sounds like a recipe for disaster! As soon as I destroy an object, I would then have to go through all my data structures looking for references to it to clean up. That sounds a lot like a garbage collector to me and I have to wonder whether the performance benefit of reducing object references would be cancelled out by my own ‘DIY’ garbage collector.

One thing that made Approach 1 easier for me was to implement resource pooling. The idea is that you allocate an arbitrary number of objects up-front and then use a resource pool class to maintain the collection. When you need a new object, rather than allocate and risk garbage collection, you simply get a ‘ready-rolled’ one from the pool.

Luckily for me, Thomas H. Aylesworth has written a pretty cool generic class to allow you to pool any type of object. The only constraint is that the object must have a parameterless constructor. The reason is that you will need to be able to get an ‘empty’ object out of this pool and fill it with your data before it can be used. If it didn’t have a parameterless constructor, the pool would have trouble allocating all the objects you need up front as it would not know what parameters were appropriate for the constructor – it is a generic class after all.

I’ve added the class to my own engine, and you can too provided you leave his copyright and license information intact as I have done.

Using the pool class

modelPool = new Pool(10);
effectPool = new Pool(5);
instancePool = new Pool(100);

This code shows how you would initialise the pool. Note, the Effect class in XNA does not have a parameterless constructor so cannot be used directly with the Pool class. I simply created my own Effect class and wrapped the XNA Effect class up in it. To ensure my code then refers to my Effect class rather than the XNA one, I add the following uses directive to the top of each source code file:

using Effect = XNAEngine.Graphics.Effect;
using XnaEffect = Microsoft.Xna.Framework.Graphics.Effect;

Then I made sure my Effect class had a parameterless constructor. This was all made a lot simpler by the fact that I wanted to customise the Effect and Model classes myself anyway and while the XNA classes are useful, your own class can be less generic than theirs and ideally faster.

Pool.Node effectNode = effectPool.Get();

This doesn’t allocate any memory. The Get() method on the Pool object simply marks one of it’s unused pre-allocated objects as ‘in-use’ and returns a reference to it. To access the Effect object itself, simply use the .item property.

effectPool.Return(effectNode);

This code returns the node back to the Pool, ready for re-use later. It isn’t destroying the object though, it’s there waiting if we need it again!

Conclusion

As Shawn said, “you must pick just one path and follow it to the bitter end”, which I plan on doing. I don’t think I ever would have taken the Approach 2 path he describes, but there may come a time when I need it so it’s nice to know the option exists.

I stumbled across the website of Benjamin Nitschke after reading an article about a Microsoft competition to write an XNA game in 4 days. I think you’ll agree that the results are staggering! So, it’s Ben’s book I decided to buy and here is a mini-review of it. The book is available now and I got it at Waterstone’s for £26.99.

Who is it for?

The book is aimed at newcomers to XNA but NOT newcomers to programming. In my opinion, this was a good move. There are a lot of C# books out there that cover the basics and I would have been disappointed had this book dedicated the initial chapters to re-iterating the basics and leaving less room for XNA goodness.

If you are a beginner, I would still recommend the book if you are interested in games programming as the initial chapters focus on simple games that could serve as an excellent way to brush up on your programming skills – much more fun than “Hello World!” It would be wise to have another text on pure C# programming though.

What it covers

Subjects covered (and this is an abbreviated list) are:

• Setting up the development environment.
• Using the Agile Method to develop games.
• Simple 2D games such as Pong and Breakout.
• Displaying a simple 3D model.
• Using shaders, normal mapping and other techniques to produce professional visuals such as bloom, motion blur, glass effects etc.
• Sound.
• Landscape design and implementation.
• Physics.

What’s refreshing is that by leaving out elementary basics, Benjamin is able to dedicate a large chunk of the book to advanced topics.

Each chapter tends to focus on a particular topic by showing how to implement it in a real game. There are a number of games created in the book ranging from the simple 2D games mentioned earlier, up to a fantastic 3D racing game in which you throw your car around a track that snakes in and out of a realistic rocky landscape.

Ben says early on how much he prefers XNA to DirectX programming and in fairness to him, he delivers the goods to back up his claims. The games he creates throughout the book certainly have that professional polish and don’t feel amateurish or compromised in any way.

How to use the book

The author does not list the code for each game in its entirety. Instead, he chooses to focus on the really important snippets of code that illustrate his point, leaving it up to the reader to download the source code from Wrox and read through to gain more insight. I think this is a good move on his part as I would have been just as disappointed with the book being ‘filled’ with code dumps, as I would if it dedicated chunks of pages to explaining how variables work.

When it comes to 3D, he focusses more on how to get XNA to do what you need it to do rather than explaining every single aspect of 3D, such as matrices. I’ve always found such texts on 3D very dry and at least with this method, you can actually get something done and become more comfortable with the concepts. It’s always less frustrating when you can actually experiment with real code to get instant feedback.

Agile

Benjamin is a big fan of the Agile Method and it really suits game development on XNA. I must admit I was initially shocked to see it promoted so much in the book but as I have progressed, the benefits have been realised. I won’t explain it in full but the process goes a bit like this:

• Think about a part of the game you want to implement (eg drawing the paddle in breakout and moving it around).
• Write a unit test which calls some (as yet uncoded) methods to accomplish this task.
• Write the methods which actually do the work.
• Run the unit test until you get the required result.

It’s a useful way of working as you focus on just one thing at a time and gradually tick off all the functionality your game requires. At the end you still have your unit tests so you can quickly identify any new bugs you have inadvertently created by just running each in isolation. I’ve always coded by dividing a problem into small chunks but this way formalises that a bit and really helps you focus on solving one problem at a time while doing it well.

Verdict

As you have hopefully gathered from this article, I like the book. It’s excellent value for money as it doesn’t re-iterate programming basics, doesn’t pad out the book with endless listings but does take you from being a beginner with XNA to being able to handle some very advanced topics. My gut instinct is once you have exhausted this book, you’ll be a pretty accomplished XNA games developer in your own right.

Thankfully, someone else has written a nice tool to create the intermediary bitmap for you. All you then need to do is select the white characters in photoshop and start applying effects!