Firstly - we have to consider the platforms:

XBOX:

With the 360, the ONLY option for indie games is XNA. While support from Microsoft has been spotty at best, a few people - myself included - make a decent living from this platform alone. Even just as a platform to toy with to show your friends code running on consumer hardware, XNA on Xbox is valuable. Is it dying? Well, we are likely to see the NEW Xbox (720, loop, whatever) Holiday 2013. That's nearly 2 years away. And the 360 wont die instantly - in fact, its likely for people who cant afford to upgrade - indie games may be the only outlet of new games after a while.

Its possible the new Xbox will run XBLIG games - and possible that you'll be able to publish new XBLIG games but in all likelihood it'll be a new SDK.

WindowsPhone:

Microsoft has already announced the death of Silverlight pretty much - and in the same announcement has either said WP8 will  support new XNA apps - or wont. It's hard to truly read between the lines. What we DO know is that everything in the store right now will run on WP8. There is also a good chance that WP8 will not be rolled out to the old devices, meaning you've got a captive market.

Windows:

This platform is the home of most of the paranoia - yet its the easiest to answer. Windows 8 will not support XNA within the metro environment. Does this mean XNA is dead? Anything but. Firstly, XNA on PC can only be compiled for x86 (not ARM) meaning all machines capable of running it will have desktop mode. Desktop mode will always support XNA - for the same reasons it will always support VB6 and so on. The PC is an open platform and thus you cant place limits on what it can run.

The concern is more that, as its not supported under Metro, it cannot be sold under the new Win8 store. This doesn't mean XNA is more dead - it just means its not more alive. However, just because Microsoft hasn't given us the tools to make XNA run in metro doesn't mean they wont exist. Because native development is possible - and how open windows is - there is no limit to what you can do - and there are several teams working to bring XNA to metro. The earliest we are aware of is the ANX Framework which is a port of XNA to DirectX11 - and openGL for Linux. Also announced recently is that MonoGame will be working towards a metro version.

If this new store is of no concern to you, such as you wish to release for free, or on another marketplace such as Steam or IndieCity then the changes (or lack there of) in Windows8 are of no concern at all - XNA is as valid a platform as it was with Windows 7, Vista and XP.

There is also Shawn H's new toy - DirectXTK - created with Chuck Walbourn - a few little toys for c++ that are based on XNA ideals - so you can make the move to Metro smoother for yourself while learning a new language.

iPhone:

Iphone? Yes, thanks to MonoTouch, c# apps can be run on ios, and thanks to the open sourcproject MonoGame , porting XNA apps is a lot less work than you imagine. The MonoGame port gets stronger and stronger every day, with 3D support being added recently - and new platforms being added frequently. iPhone seems to be the primary platform for the MonoGame and probably the healthiest platform if you intend to at least cover costs. the iPhone is actually a platform where XNA support is getting STRONGER rather than weaker and there are some rather interesting facts. Due to the apple app store rules, c# cannot be JIT on the iPhone - it has to be compiled. This means XNA code on the iPhone runs fast. REALLY fast. Much faster than the same code on WP7 for instance. There were some early concerns about some small print in the developer T&C's but apple has reverted these meaning using c# for iOS development is fully legit.

Android:

As above, MonoGame is allowing XNA dev on android.  While not as mature, progress is being made fast and is worth consideration.

MacOS/Linux:

Both MonoGame and ANX are targeting these platforms. ANX seems to be more solid graphically, MonoGame more solid in the nitty-gritty stuff.

Playstation Vita:

Sony's Playstation Suite is a c# (mono based) platform for indies to create games on the PSV and 'Plasystation' android devices. While nothing concrete yet, since it supports c# already, using MonoGame or something similar wouldn't be a huge stretch. Its early days yet, but its certainly on the radar.

So what does it all mean?

If you a WP7 developer, your future is unknown. If you develop for XBOX, the future is uncertain but you've got at least 2 years of marketplace left. However, XNA is far from dead - in fact, if you're willing to stray from MS platforms  - or at least non MS versions of  XNA at least - its more alive than its ever been. Us developers - especially in the XNA community do like a bit of doom and gloom but its just not warranted. MS may not be supporting XNA directly for a while, but its got a lot of legs left in it.

Not only that, if you are starting out, XNA is an amazing platform to cut your teeth on - and what you learn is applicable on pretty much every other platform out there.

Sgtconker.com will be covering all of the above tech and will cover issues of porting, multiplatform development and the like. XNA isn't at the end of its life, its just growing up and leaving home.

Some of you may know me already, many will not. I cut my teeth in XNA programming with an XBLIG app called 'ezmuze', which I followed up with the super successful 'ezmuze+'.  In that time I went from decent zero to hero somewhat, so I think I'm rather well positioned to know what articles the noobs need and also, what the pros need too.

I hope under my command, the site will shake its reputation for not so many updates. I hope to expand the scope slightly, with tutorials and news on alternative XNA platforms such as monoGame, technologies such as DirectXTK (the spritebatch like c++ libs from Shawn H) and maybe even a little bit of WinRT/Metro.

My expertise are most certainly in the audio realm so I will be looking to others for other articles as you can only discuss iPad ports and DSP so much. If you want to contribute, please contact me with an article.

Hopefully we can restore Sgt.Conker to its former glory and help and inform a few people along the way.

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:

[code]

interface ISomethingOrOther

{
void Something();
}

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

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

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

[/code]

-          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:

[code]
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" },

}
[/code]

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:

[code]

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;
}
}
}
}

[/code]

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:

[code]

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

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

[/code]

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

[code]

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

[/code]

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?

[code]

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

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

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

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:

[code]

SomeObject[] objectArray;

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

[/code]

You can cache the variable to avoid this overhead:

[code]

SomeObject[] objectArray;

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

[/code]

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:

[code]

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
}

[/code]

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:

[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);
[/code]

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.