Meanwhile, in Jim “So Evil That Even George Ducks and Covers” Perry-land the Overlocker himself continues to spam his blog. This time, he covers Spy Game Design – Multiplatform Issues/Capability and Spy Game Design – Character Training. Lets see if he can keep up the pace while The Hidden One continues to, well, hide.

• Spy Game Design – Agent Specialties
• Spy Game Design – Inventory and Related Areas
• Spy Game Design – Assignments/Missions
• Spy Game Design–Death
• Spy Game Design – Advancement
• Spy Game Design – Combat
• Spy Game Design – Identities

And, compared to the AppBuh Forums mess his forums are alive and kicking.

As you may or may not know (until now) a fellow XNA developer @DeathmatchGames and his family were victims of the May 22nd tornado that ravaged Joplin, MO. You can find extensive coverage of the tornado and the devestation [sic] it's caused at CNN.com, Google, and everywhere else.

Head over to the DeathmatchGames - Joplin Tornado Fund to read more and to learn about the ways to help.

Technical Director, UberGeekGames

For the Xbox or Windows Phone 7 programmer, performance is something that should always be kept in mind. For any moderately complex game, it can be very easy for framerate issues to crop up, and seeing as those pesky gamers insist on having a smooth playing experience, it can quickly become problematic.

Having had quite a bit of experience in this area with our last few games, this article will be a “missing manual” of sorts; the kind of cheat sheet that would have saved me more than one headache!

The target audience

I’m going to make a couple of reasonable assumptions to guide us. First, you either have a game that currently has performance issues, or you’re planning a game that will most likely run into performance issues later on in development. Second, you’ve already read through Shawn’s blog posts on performance. If you haven’t, go read them now: http://msdn.com/blogs/shawnhar I’ll wait.

Back? Excellent. You should already be familiar with the basic principles of profiling, how to use a profiler, rig up an FPS counter, and how to determine if you’re CPU or GPU bound. Without further ado, we will now dive into the deep end of the performance pool, so to speak. Each of the following sections will cover a technique that can help improve your game’s performance.

Quadtrees, Grid Registration, and spatial partitioning

Quadtrees are an oft-recommended improvement, and with good reason – they can vastly improve the performance of many different systems, the most popular being collision detection and view space culling.

For example, let’s say you’re building a shooter and will have a large number of bullets colliding with an even larger number of enemies. A naive approach would be to run your collision detection algorithm on every bullet against every enemy. This will take exponentially longer as the number of enemies and bullets increases.

By implementing a quadtree, you break the game world up into smaller chunks. Enemies, bullets, and anything else that needs to be collided with will be added to whichever chunk contains them. This way, you only need to check collisions against the bullets and enemies in the same chunk.

Quadtrees can be built in both 2D and 3D worlds. In 3D, they can also be used for efficient view space culling. They are typically known as “octrees” in 3D space.

Garbage collection

The CLR on the Xbox and WP7 have much slower garbage collectors than on the PC (soon this won’t be the case for WP7: http://blogs.msdn.com/b/abhinaba/archive/2011/04/13/generational-gc-in-windows-phone-mango.aspx – huzzah!). If your game has frequent stuttering or pauses, then you most likely have a garbage collection issue. This has been covered in Shawn’s blog, but here are a few additional tips I’ve picked up:

-          Beware of boxing. This can come from odd places, such as adding maintaining a list of interfaces; the following code will generate garbage:

interface ISomethingOrOther

{
    void Something();
}

struct Something : ISomethingOrOther
{
    public void Something()
   {
   }
}

List<ISomethingOrOther> ListOfInterfaces = new List<ISomethingOrOther>();

ListOfInterfaces.Add(new Something()); // boxing!

-          Boxing can also occur when you use an enum as a key in a Dictionary<Enum, something>. I usually use a Dictionary<int, something> and cast to int when indexing into it like so:

enum YourEnum

{

    A, B, C

}

//adding elements will cause boxing.

Dictionary<YourEnum, string> dictionaryWithBoxing = new Dictionary<YourEnum, string>()

{

    { YourEnum.A, "a" },

    { YourEnum.B, "b" },

    { YourEnum.C, "c" },

}

//no boxing!

Dictionary<int, string> yourDictionaryWithoutBoxing = new Dictionary<int, string>()

{

    { (int)YourEnum.A, "a" },

    { (int)YourEnum.B, "b" },

    { (int)YourEnum.C, "c" },

}

Nick has more info in this blog post: http://blog.nickgravelyn.com/2009/04/net-misconceptions-part-1/

-          Make liberal use of pooling to avoid creating new objects at runtime. A simple template that I use:

class SomeObject
{
    //stuff
    public void Spawn(Vector2 position)
    {
    }
}

class SomeObjectPool

{
    public static bool[] isAlive;
    public static SomeObject[] pool;
    public static SomeObjectPool()
    {
        pool = new SomeObject[100];
        isAlive = new bool[100];
        for(int i=0;i<pool.Length;i++)
        {
            isAlive[i] = false;
            pool[i] = new SomeObject();
        }
    }

public static void Spawn(Vector2 position)
{
    for(int i=0;i<pool.Length;i++)
    {
        If(!isAlive[i])
        {
            isAlive[i] = true;
            pool[i].Spawn(position);
            break;
        }
    }
}
}

Nick also has a template for this: http://forums.create.msdn.com/forums/t/3375.aspx

-          Pooling classes is almost always a better solution than switching to structs, unless you know exactly why you need them. Classes behave very differently from structs, sometimes in unintuitive ways if you are not familiar with the difference between value and reference types. This page contains a good primer on the differences: http://www.albahari.com/valuevsreftypes.aspx

Draw that 2D content most efficiently with Spritesheets

If you draw sprites individually, loading them one at a time and drawing them, you will prevent the GPU from batching its draw calls in the most efficient manner. By using spritesheets, the GPU will not need to switch textures in between draw calls and can batch your drawing more efficiently. This post by Shawn succinctly explains the general idea: http://forums.create.msdn.com/forums/p/24254/131437.aspx#131437

The spritesheet sample is here: http://create.msdn.com/en-US/education/catalog/sample/sprite_sheet

And I’ve personally been using Nick’s SpriteSheetPacker tool to automate the packaging process, with great success: http://spritesheetpacker.codeplex.com/

Batch your SpriteBatches

Efficient rendering is all about batching. Remember the elf in a box model: http://blogs.msdn.com/b/shawnhar/archive/2008/03/31/an-elf-in-a-box.aspx

If you want to maximize GPU performance, use as few SpriteBatch batches as possible. There are, of course, many cases where you just have to end and begin a new SpriteBatch in order to switch renderstates or blend states, but for all other cases – use a single spritebatch!

Multithreading

On the Xbox 360, you have three separate processor cores and six hardware threads, four of which are available for you to use (one on core one, one on core two, and the two on core three; see this MSDN article http://msdn.microsoft.com/en-us/library/system.threading.thread.setprocessoraffinity.aspx).

If you are CPU bound, you might gain some performance by threading. Common tasks that are likely candidates for threading:

-          Particles; if your particles are updated on the CPU and take a significant amount of processing time, they will likely be one of the easiest things to multithread.

-          Collision detection; while this can be tricky to synchronize depending on what you’re it can work well.

-          The sky is the limit when it comes to what you can offload. With enough work you could theoretically offload most any system to another thread. The key is making sure that the performance gains will be high enough to warrant the overhead of managing the thread, and how easy it will be to synchronize data between threads.

On WP7, you are limited to a single core, 1GHz processor. Multithreading is unlikely to see any wins here, as it will just add overhead.

Manually inlining high frequency code

You may get to the point where you still have performance trouble but there are no more big wins left, or all the low hanging fruit has been picked, so to speak. At this point, manually inlining methods that are called at a high frequency could be the next best step. Manually inlining is nothing more than avoiding excess method calls when possible. Take the following piece of code:

foreach(Particle particle in ParticleList)
{
    particle.Update();
}

class Particle
{
    public void Update()
    {
        Position += Velocity
    }
}

There is a small amount of overhead when calling a method. This alternate version will be faster:

void Update()
{
    foreach(Particle particle in ParticleList)
    {
        particle.Position += particle.Velocity; //slightly faster
    }
}

The gains here are relatively small, but can make a difference in with lots of values such as particle engines.

Cache values wherever possible

Optimization, at its core, is just figuring out how to get the same or similar results while doing less work. Caching values is a perfect example of this. When drawing a texture, for example, how many times do you do this?

void Draw()
{
    Rectangle drawingRect = new Rectangle(foo, bar, foobar, barfoo);
    spriteBatch.Draw(Texture, drawingRectangle, Color);
}

What’s the point of recreating the rectangle each frame if the value doesn’t change? Define that outside of the loop like this:

Rectangle drawingRect = new Rectangle(foo, bar, foobar, barfoo);
void Draw()
{
    spriteBatch.Draw(Texture, drawingRectangle, Color);
}

Properties

Properties are roughly equivalent to a JIT method call. And we’ve already established that method calls take a nontrivial amount of time to execute. Therefore, properties are best to be avoided unless necessary.

“But, kind sir, all the C# style guides tell me to use properties! Why would they recommend such a thing if it’s so bad?”

Simply put, most guides I’ve seen which recommend this assume that you are either going for maximum readability and maintainability, and/or performance isn’t of much concern (eg, a winforms tool). And on the PC, you’re almost certainly not going to run into issues stemming from properties, as the latest processor can chew through them with ease. On hardware such as the WP7 or the Xbox 360, every cycle can count.

In other words, if you want to look at pretty code all day, you should stay far away from game development.

Array indexing

Another subtle improvement in tight loops is how you index into an array’s elements. An array index costs about the same as a JIT method call, plus some overhead for bounds checking. Take this code for example:

SomeObject[] objectArray;

Void DoSomeStuff()
{
    for(int i=0;i<objectArray.Length;i++)
    {
        objectArray[i].Position += something;
        objectArray[i].Velocity *= whatever;
        objectArray[i].Counter++;
    }
}

You can cache the variable to avoid this overhead:

SomeObject[] objectArray;

Void DoSomeStuff()
{
    for(int i=0;i<objectArray.Length;i++)
    {
        SomeObject obj = objectArray[i];
        obj.Position += something;
        obj.Velocity *= whatever;
        obj.Counter++;
    }
}

Dictionaries vs Arrays

Dictionaries are great. They are an invaluable coding tool that makes efficiently organizing data easy. However, it is quite possible for them to become a performance bottleneck, as they are about twice as slow as an array index, and can be even slower if you’re unnecessarily indexing into them more than once. Here’s some example code to explain this:

Dictionary<int, Texture2D> textureDictionary;
…

//this is the slowest way to use a Dictionary, as we are effectively doing two lookups for the same object. Slowness!

if(textureDictionary.ContainsKey(textureKey))
{
    Texture2D texture = textureDictionary[textureKey];
    //do something with texture
}

//this is faster as we are only doing one lookup.
Texture2D texture = null;
if(textureDictionary.TryGetValue(textureKey, out texture)
{
    //do something with texture here
}

Vector operations

When possible, use the Vector2.Whatever() methods that pass their arguments by reference and use out to supply their output. This will be faster than using the normal C# addition/subtract/multiplication/division operators. Take this example code:

//Easy to read, but slow!
someVector += anotherVector * someFloat;

//More verbose, yet faster
Vector2 tmp = new Vector2();
Vector2.Multiply(ref anotherVector, someFloat, out tmp);
Vector2.Add(ref someVector, ref tmp, out someVector);

Soon, this will be even faster on WP7: http://blogs.msdn.com/b/abhinaba/archive/2011/04/10/simd-support-in-netcf.aspx

This is a "hands on" hackathon where you will learn from Windows Phone 7, XNA and Azure experts how to build, scale and publish your Windows Phone 7 app or game. If you are just a beginner, or already have apps in the Marketplace this event will should not be missed. BYO Laptop!

RSVP early, space is limited to 300 attendees: http://bit.ly/RegWP7Hackathon [Ed.: The unshortened URL for the event details is here]

(YOU DON'T HAVE TO BE A TECHED ATTENDEE TO COME TO THIS!)

Hopefully, in SharpDX unlike any other DirectX .NET APIs, this code has been written to be consistent over the whole generated code, and was carefully designed to be quite efficient… but still, It has obviously a cost, and we need to know it!

Spoiler: The offerings Microsoft has in store are, by far, slower than SlimDX/SharpDX.

In other news: There is a thread over in the AppBuhAppHub forums praising the XNA MVPs. We here in the barracks fully support that effort – mostly due to the fact that Captain ZSquare has access to various arms here and we lost the keys to lock up the arsenal… – so you might head over to add to the +1 (none of the Google +1 stuff) choir.

Go ahead and read it now.

First, there’s Michael B. “Concise” McLaughlin of Bob Taco Industries fame. Expect even more words coming from this man and his blog (and now his forums).

Next up comes the John “The Pale Impaled” Defenbaugh, joining Jim “The Closer” Perry, armed with his shut gunshotgun the threads will fall left and right like clay pigeons. Luckily he still ain’t havin’ the permissions.

The third one is MIA currently… [Update: OK, our intelligentintelligence services managed to get ahold of his name now, Dr. Minh-Triet TRAN, but not many more details…]

Lets hope thisthese guys can fulfill the demands of the community…

[Update: Moo]

No major damage was done, and no soldiers were harmed in this unfortunate outbreak.

And now the news.

George continues his onslaught of posting all things XNA News by bringing you XNA Notes 012.

Ploobs Game Engine - another open source XNA Engine. The engine boasts a huge list of features which you can see just under the screenshots on the codeplex page.
Unfortunately it’s for XNA 3.1, but it looks pretty, and hopefully wouldn’t take much to upgrade to XNA 4.0. Thanks go to Thiago Dias Pastor for bringing this to our attention. He also made me aware of a downloadable document here which is an extensive explanation of the techniques used in the engine. Unfortunately it’s in Portuguese which limits the audience some what.

Optimizing Bounding Boxes in XNA – Robert Walter brings a decent article on how to optimize bounding box collisions in XNA.

Tower Defense Tutorials -  This website has 14.5 articles on how to build an XNA Tower Defense game. Looks like a nice resource.

Neoforce controls – This is something I completely missed. A skinnable GUI library for XNA 4. Looks stunning, possibly a bit overkill but still … worth a try at least.
Disclaimer : this project is no longer maintained or developed (but it’s open source)

And lastly, some support for a very cool XNA engine.

SunBurn Game Engine is looking HOT! – Here’s some news from the Synapse Gaming team.

SunBurn Game Engine: Full Windows Phone 7 Support

Synapse Gaming’s SunBurn Game Engine has led the pack when it comes to technology for XNA. And our latest SunBurn update solidifies that commitment with full support for Windows Phone 7.

This is not some add-on or a small subset of the engine. Instead it includes all of the features and systems the hardware is capable of supporting, and using the same api, content pipeline, and design as on Windows and Xbox. This allows a game to run across all three platforms without any modifications, while still being able to take advantage of SunBurn's advanced features like deferred rendering, HDR, and more on Windows and Xbox.

Windows Phone 7 features in SunBurn include:

• Diffuse and emissive mapping
• Volume lighting
• Bloom / post-processing
• Baked-down lighting on static objects (see below)
• Composite lighting on dynamic objects (see below)
• Collisions
• Use the same scenes, light rigs, code, tools, and api on Windows, Xbox, and Windows Phone 7

SunBurn 2.0 also includes in-editor baked-down lighting, which generates light maps that render with none of the overhead of the real-time lighting (rendering nearly for free). This makes highly detailed lighting and shadows possible on Windows Phone 7 (which does not support dynamic lighting and shadows).

To learn more, and see SunBurn WP7 games and demos in action, go to http://www.synapsegaming.com/blogs/johnk/archive/2010/11/16/sunburn-2-0-goes-mobile-on-windows-phone-7.aspx