I’ve always been fascinated with game industry stories. From the first day I started in the business, I’ve always been eager to hear anecdotes from other people that had seen and heard so much. Many years on now, I’ve some of my own stories. Some of which I’m actually part of myself. It’s kind of surreal to feel like I’m on that other side of the fence now.

Recently I picked up this book again: “Masters of Doom”, by David Kushner. It’s the third time I’ve read through it. Nuts eh? I don’t think I’ve ever read any kind of book that many times over. It’s just a very well told account of id Software‘s birthing, and what happened to the key employees up until around 2003. I’ve recommended it to several people over the past couple of years, since I first picked it up. In fact it was suggested to me in the first place by a coder colleague here at Neversoft.

I think what had me going back to it again, was how inspiring a story it is. From being a kid who downloaded the Wolf3D shareware originally from a BBS, and picked up the Doom the same way. The stories in the early half of the book are amazing to me. These people created their own genre, they created groundbreaking tech. To a kid fascinated with videogames, and computer programming these people were my gods!

As someone now who’s all grown-up, and has coming up to a decade of time in the industry under my belt. These stories still resonate with me, they’re extremely inspiring, and make you believe that there’s still room for innovation in the future. I think these days with conservative big-time publishers, you only see that innovation in the indie scene. I really can see something very special coming out of that section of the industry soon.

 

What else is out there?

Well, that’s what prompted this post really. There really isn’t anything that comes close to this book right now. There’s a real gaping hole here for this stuff. You might say that people interested in the inner workings of the games industry are a very small group. But really, I don’t think this is the case. Even if you remove the gaming part completely, it’s a great account of a technical-led success story. I’m sure books about Steve Jobs and Bill Gates fly off the shelves. I can’t see why the same can’t be true about this material either.

There are a couple that I managed to find that I thought could be good reads. The first one looked initially very promising, but on reading the Amazon reviews I was greatly turned off. The book in question being: Rogue Leaders: The Story of LucasArts. I adored playing the old point-and-click LucasArts adventure games, so reading about these seemed a real treat. The reviews however mention that these games are only discussed very briefly, and in no sort of detail at all. So not my cup of tea, I’m not much of a Star Wars fan.

The second book I actually did pick up, and have got just over halfway through. It’s SmartBomb. It’s been a bit of a slog and I think I’m going to give up on it now. The story about how Atari started was a high-point, interesting stuff that I’ve not heard about before. But on the other hand you have a poorly-researched version of how id Software got big, and lots of fluff about gaming tournaments and CliffyB’s visits to trade shows.

The id mistakes were odd. They mentioned their key titles which “started it all” were “Return to Castle Wolfenstein, Doom, and Quake”… Doh! To spare their blushes though, they do refer to the correct name “Wolfenstein 3D” later on in the chapter. The other doozy I remember was saying that they were told to “make three games, we’ll give away the first two for free and sell the third”. They then referred to that as being Shareware. That’s probably how my mum would try and describe how Shareware works, if in some bizarro-world she was researching a book like this.

The CliffyB stuff could have been so much better if they had talked some about how he got into the industry in the first place. I still have no idea if he ever wrote code himself. I mean take Sid Meier, he actually coded Civilization as well as designing it. Not that it takes away from his designer skills if he’s not a coder. I’m just curious, I enjoyed ‘Jack Jackrabbit’ back in the day. In the book his early days are relegated to one sentence that mentions he sent off a floppy disk in a ziploc bag. MobyGames actually says he did some games before Jack, but his role isn’t clear. At least one seems to indicate he did the whole thing himself. Anyway, this is a far more entertaining CliffyB story. Even though it is completely made up.

 

Engerlund, Engerlund!

As I tend to do when I write these blog posts, I’m going off track. The real point of this post, and the namesake of the post itself is about British game developers. Why is there absolutely nothing written about them in books? I also feel whenever I read any sort of modern game website about the ‘good old days’; it’s always just Atari, Nintendo and the Apple II. There was another golden-age of gaming, from the mid 80′s through to the early 90′s. This one occurred and originated in Britain. Take the Spectrum, the C64 (and the Amstrad!). Then you’ve got the Amiga, and in turn some PC and console conversions of the same games. There’s so many good games for those systems. Nowadays though whenever a modern site like Kotaku gets misty-eyed, it’s like these games never existed.

Elite? I don’t think I’ve met an American who knows what that game is. Manic Miner? No chance.

Manic Miner is a good one to pick up on. It pre-dates “Super Mario Bros.” on the NES by almost two years. Whilst it’s missing the scrolling element of Mario, it was at the time a revelation in the British home computer market. The author, Matthew Smith famously dropped off the face of the planet after the follow-up: “Jet Set Willy”. He apparently joined a commune in The Netherlands, and stayed there for a number of years. Take a gander at this YouTube clip for some nostalgia. The gangly-guy on the new “Doctor Who?” is the Matt Smith eh? No, Mr. Manic Miner is the Matt Smith, and always will be.

• Elite. Just mentioning this one again. Braben has his own company now, curious as to why Ian Bell didn’t join him. The game itself was a groundbreaking use of procedurally-generated worlds on a huge scale.
• Mythos Games. Laser Squad, Lords of Chaos, and the X-COM/UFO games of course. Turn-based strategy joy.
• Imagine. No really outstanding games I remember, but there’s a very interesting backstory about how piracy killed the company.
• Codemasters. The Darling brothers, and the Oliver twins. Redefined the pricing model for games at the time, selling (mostly) quality newly developed games at budget prices.
• The Bitmap Brothers. Speedball and The Chaos Engine. Outstanding art-style. Best looking games out at the time.
• Psygnosis. Nuff said. They are now SCEE Liverpool.
• Rare. Killer Instinct, Goldeneye 64, Donkey Kong Country. They used to be ‘Ultimate: Play The Game’. Sure there’s a good story there. Throw in some ‘Mr. Pants’ and it’s gold.
• Molyneux and Bullfrog; Syndicate, Populous, Dungeon Keeper, Magic Carpet. All groundbreaking, classic games.
• The GTA guys up at Rockstar North. Tie in the DMA design days too, and you’ve quite a story. Lemmings is an all-time great.

Anyway, just some food for thought. There’s a gap in the market here for someone willing to put in the research time. Can’t see why it wouldn’t sell well. The GTA stuff would probably sell it in the States!

A few weeks ago I mentioned on twitter that I was working on an Amstrad CPC emulator, written in XNA. There are plenty of the things for the PC and various other consoles, but not one for the Xbox 360 yet. So it seemed a cool little exercise to undertake.

A long time ago, I wrote one of my own for the PC. The website I setup for it is still live, here. I developed it initially around 1997. Back then I’d pretty much just gotten it to be able to boot, and be able to type things on the keyboard. I revisited it a few years later when I needed something flashy for my portfolio, around the time I was trying to break into the games industry. With that version I managed to get a handful of games running nicely.

Little bit of history

I used to be really into the emulation scene back in the day. The first one I stumbled upon was on a BBS, some random BBS I found in the pages of Computer Shopper (wow, that mag is still going!). My father used to go to his work to wash his car on the odd weekend here and there. I used to use his Apple Mac computer when he was doing that, was one of the old Mac Quadras. This would have been around 1993 I think, so I’d have been a spritely twelve or thirteen years old at the time!

Anyhow, I’d use some terminal software on the Mac, downloading various interesting programming bits and bobs via the trusty ZMODEM protocol. One weekend I was stunned to see something called CPCEMU. This was the first Amstrad emulator ever to see the light of day. I didn’t even know such a thing was possible at the time; I’d pretty much figured that it could well be a joke download. So after copying my weekend’s haul to a floppy as per-usual, I was excited to give it a try.

This software and much of the rest of the stuff I downloaded was PC-only. I didn’t have a PC at home at the time; I’d just use the ones at my school during lunchtimes. It was really cool to see the emulator fire up on that PC at school. Unfortunately though the Amstrad ROM wasn’t included in the package, so all that worked out of the box was a single sample game written to interface directly with the hardware. That year I remember my ‘big’ Christmas present was a 3.5” disc drive for the Amstrad, primarily so I could dump the ROMs from the machine so I could get the emulator working! What a nerd.

Around the time I’d also written in to the only remaining Amstrad CPC magazine in production: Amstrad Action. They had some feature where they asked readers to write in with any sort of Amstrad-related article, and they’d print them up in some sort of ‘readers articles’ feature. This never actually happened though unfortunately; they never did run any reader articles. I’d written one in about CPCEMU, whilst it never appeared I did get a mention in the magazine. After a little googling, I managed to find it:

Amstrad Action – #104 – May 1994 (click for larger image)

Brought a smile to my face seeing it after all these years!

Other emulators

There were a number of other emulators I ‘followed’ back in the day too. GenEm; the first SEGA Genesis / Megadrive emulator out there, was one in particular. Was really something to see it improve over time. From humble beginnings where only a handful of early-era games are only playable. Through to audio emulation working (the Genesis/MD has a second processor; a Z80 funnily enough, which is primarily used for audio in games). Around this time was an explosion in emulators in general, for all sorts of other videogame systems of similar eras. There was a bit of a race between coders to get their emulator to be the most fully featured, with the highest game-compatibility rate. Competition drives technology, I guess?

Some other ones I remember too were KGEN and DGEN. But the real leap at the time I recall was Genecyst. It was really leaps and bounds above the other ones out at the time. The same guy (or group) that coded it also wrote the impressive Callus, and NESticle. Both landmarks at the time, particularly Callus which I think was the first Capcom arcade emulator that ran at a playable speed.

The UI for Genecyst, all emulators for the era were in DOS. Unlike most, this one had a GUI too

I also remember Executor well too, an Apple Mac emulator. This one took an interesting approach of not making use of any System ROMs at all. They essentially reverse-engineered the Mac. The emulation effectively emulated the services/OS calls that the system ROM would have provided. This I think was more of a legal choice than a practical one, but it must have been an interesting technical challenge. They updated it pretty often, it seemed like every week there was a new one to try that had a new slate of improvements. Unfortunately it was a paid-for emulator. I think it had a time restriction on it, it worked for ten minutes and then quit out. That was a rarity back then in the emulator scene.

Screenshot of Executor in action

As I was looking for stuff for this article, I was surprised to see that it’s now open-source. I think now there’s probably several other Mac emulators which take the more traditional approach, and have a near 100% compatibility with a real 68k-era Mac. I wonder how well it sold throughout its lifetime?

An XNA CPC Emulator

Christ; I do go on like an old woman, don’t I?

The point of this article was meant to be about the Xbox 360 version of the emulator I’m working on. I did most of the work for it over a weekend, about a month ago. The missus was away for work, and I had a nice block of time to tackle it. I essentially just used my previous emulator I wrote a few years prior, in plain C. I rewrote it in C#, in a much more OO-way.

It was as a pretty straightforward process. As I’d done with my older emulator, I took the Z80 CPU emulation from an existing source. Someone has already coded a ZX Spectrum emulator in C#, so I took the CPU code from there. The Zx360 project. I had to make a few modifications though. One was based on how memory is accessed on the CPC, to handle the ROM and RAM banking. The other was for the way interrupts are handled. I know very little about the Spectrum, but it seems like they do behave pretty differently in that regard.

So, dusting off the cobwebby corners of my mind, I got to implementing all the various bits of hardware of the machine. Using both my old source, and the Unofficial Amstrad WWW Resource for reference. The code quality was like night and day compared to my old plain-C implementation. That’s I guess what thirteen years experience will help you out a bit with! It a joy to debug too; all the little components of the machine browsable in the Visual Studio debugger, in a nice OO-d tree!

I worked on the actual XNA-specific parts last. Getting the screen drawn, and getting input working that is. It’s just as cool as I remember when you get that startup screen rendering the very first time. This old thing:

XNACPC bootup, the Amstrad CPC 464 startup screen

I then went on to get snapshot (.SNA) support working so I could load up memory snapshots of games. That was awesome to see as well. It had the exact same level of compatibility as my older emulator. I was a little worried the new Z80 core code could have some bugs or issues, but it seems solid now. So anyway, the same games that ran fine worked fine on this too. But of course the same ones with issues, also had issues on my new emulator too. Once I’d played a few games on the Xbox itself, I took a break from the project for a while.

The classic ‘Roland in Time’ running on XNACPC, on an Xbox 360

A bit later on

What I really wanted to add was proper audio support. I dabbled for a while using XACT; playing a sound and messing with the pitch and volume of it. But it had pretty hideous results. It was encouraging to hear the tunes in there somewhere, but it really didn’t work well at all. What led me to stop bothering with this method was news that XNA 4.0 has nicer audio support. Specifically the class DynamicSoundEffectInstance. This class allows playback of raw audio data, not just samples. Exactly what an emulator needs.

The other avenue I wanted to make improvements on was to how I emulate the video hardware. My older emulator took a very naïve approach. It didn’t make any effort to emulate vsync, hsync or tie in the CPU interrupts with any of it. Over the past few weeks I’ve had some time here and there to mess with this stuff, and attempt to get something better working. I’m pretty pleased with the results. I managed to get split-screen working. Which means ‘Sorcery’, one of the classic CPC titles is now fully playable and looks just like the original.

Sorcery on XNACPC – A CRTC-splitscreen game

I’ve still a way to go though. My CRTC and video emulation isn’t quite up to par with some of the more accomplished emulators already out on PC. Well, that’s an understatement; it’s truly awful compared to most of those emulators! But it’s something I can improve at my leisure.

I plan to release the source code for the emulator, specifically once I’ve got my video code a little more stable. Whether that’s a matter of weeks or months, I don’t know. I’m pretty busy at the moment with work, so it may take a fair while. I’d probably expect it to be after XNA 4.0 is released too, since I’d probably get some crude level of audio support in once it’s out. I’d dabble with the CTP version that’s out now, but I’m really targeting Xbox which is not supported just yet. Yes, I could write the code on PC. But I really like firing up the emulator on the Xbox, and seeing the cool stuff running on there first. I can be patient…

I’ve still a few more XNA articles I’ve been planning to write. The next one was to involve some threading code, and in the process of creating the article I hit upon something that I found concerning.

The title of this article pretty much gives it away before I can casually introduce it; the property method Thread.CurrentThread is slow on the Xbox. Specifically it’s slow compared to running the same code on a Windows PC. I’d imagine the same applies to the other Compact Framework platforms too; the Zune and Windows 7 Phones. But I can’t say for sure.

Bone-headed code

I stumbled upon this whilst trying to profile some of my code for a future threading article. I had two different techniques I was comparing, and I couldn’t for the life of me understand why one was an order of magnitude slower than the other. It just didn’t make any sense.

What I’d done in one of them was to assume that Thread.CurrentThread is cheap, and simply returns some kind of easy to grab variable. This isn’t the case. I can illustrate by showing you the exact piece of code that was slow:

for ( int i = 0; i < MAX_THREADS; i++ )
{
    if ( m_data[i].m_thread_id == Thread.CurrentThread )
    {
        return m_data[i].m_data;
    }
}

Then I changed my slower technique to ‘match’ the faster one, by prefetching the current thread:

Thread thread_id = Thread.CurrentThread;
for ( int i = 0; i < MAX_THREADS; i++ )
{
    if ( m_data[i].m_thread_id == thread_id )
    {
        return m_data[i].m_data;
    }
}

Yes, seems a no-brainer doesn’t it? In most cases it does make sense to prefetch variables like that, but I’d been a little silly and assumed there would be negligible difference from not doing so. I’d had some harebrained ideal that the optimizing compiler and the JIT-er would effectively make these two bits of code the same. On my Windows PC build they actually do execute in almost the same amount of time, certainly not different to the same degree as on Xbox.

It makes total sense that it doesn’t get optimized on either platform though. If you look at Thread.CurrentThread in the .NET Reflector, it calls an external DLL function. The compiler (or JIT-er) can’t be expected to think that the return value of that function will be the same for each iteration of the loop.

So, how slow is it?

My first port of call after I realized the big timesink, was to directly compare the performance between the Windows PC build and the Xbox 360 build. My test code was as follows, a loop accessing Thread.CurrentThread a million times:

Thread thread = null;
for ( int i = 0; i < 1000000; i++ )
{
    thread = Thread.CurrentThread;
}

Here’s how long it took on each platform:

Calling Thread.CurrentThread on the Xbox 360 is over five hundred (500!) times slower than on PC. That’s not good! The PC I’m using is nothing special, it’s a three year old Core Duo ‘1’ laptop. So I’m not running some ridiculous PC rig to see these large differences in speeds.

For the code I was working on, I modified it to call Thread.CurrentThread once at the start of my worker thread. I then pass this Thread object through to the other methods that I used, which are called often within that worker thread. So where these methods used to call CurrentThread multiple times themselves before, they no longer needed to. The Thread object for this worker thread was simply passed around instead. The code doesn’t look quite as nice of course, but it’s hardly a disaster.

The particular test I was doing with that worker thread code ran over one hundred times faster with that change made. This was still a bit of a micro-benchmark though, calling some small pieces of code a ridiculous number of times… Regardless, I was just trying to battle-test something that I’d want to use in practice. Using Thread.CurrentThread was an integral part of that.

What I ended up doing was having the facility to optionally pass in a Thread object if the user has one. If they didn’t, it would end up resorting to the slow Thread.CurrentThread instead. This seemed like an ideal solution.

CurrentThreadLite

When looking at the CurrentThread property accessor in .NET Reflector, I traced through to the DLL function which is ultimately called:

public static Thread CurrentThread
{
    get
    {
        return PAL.Threading_Thread_CurrentThread();
    }
}
 
[DllImport("mscoree", EntryPoint="#210")]
public static extern Thread Threading_Thread_CurrentThread();

Listed alongside this particular function was this other similarly-named one; CurrentThreadLite:

[DllImport("mscoree", EntryPoint="#211")]
public static extern IntPtr Threading_Thread_CurrentThreadLite();

That’s interesting. It returns a different type, an integer pointer a opposed to a Thread object. But for my purposes I just wanted to uniquely identify a thread. If it’s faster, then it’s ideal for what I need. The suffix ‘lite’ sounds promising!

I tried to see what .NET code actually uses it, it’s these methods:

At least within the .NET executable that I was inspecting. There are probably other .NET library methods that make use of it. I’m not too experienced with the reflector, so I’m totally unsure of a good way of finding them.

Lite execution

So I was curious about whether this ‘lite’ version was faster than the ‘full’ version on Xbox 360. A google search yielded an extremely small number of results for CurrentThreadLite, and variations of it. I figured as part of this small article I may as well have a little go at seeing if it does perform better. It may help someone else out in future who stumbles upon this page.

The main problem though is that there’s no direct accessor to it. Nothing at all. The StringBuilder object makes use of it to maintain thread-safety on its mutable strings, which I’ve touched on in previous articles. Using the same method I described in this article, I can grab the private member that stores the ‘IntPtr’ thread.

This does mean that I’ll be adding the overhead of both reflection, and likely some allocations within StringBuilder too. Given the limited set of methods I have to play with, I doubt I’ll end up with anything workable within a game. This really is purely a bit of an educational investigation now, unfortunately there’s not going to be anything that I’d consider usable.

A crude performance test

I picked out one StringBuilder method which calls CurrentThreadLite: Append(String). You can see the source to this method here:

http://labs.developerfusion.co.uk/SourceViewer/view/SSCLI/System.Text/StringBuilder/

The .NET library code though calls a method with a different name than the reflector tells us. The prototype of which is:

[MethodImplAttribute(MethodImplOptions.InternalCall)]
static internal extern IntPtr InternalGetCurrentThread();

I think I can safely assume this just calls through to CurrentThreadLite.

Anyway, if I pass ‘String.Empty’ as a parameter to Append() it’ll end up doing very little work. But CurrentThreadLite will be ran though, so it’d be a good indicator as to whether it’s faster to execute than the ‘full’ one.

Here’s the code I’m testing with, same one million-times loop as before:

StringBuilder string_builder = new StringBuilder();
for ( int i = 0; i < 1000000; i++ )
{
    string_builder.Append( String.Empty );
}

Here’s the results:

So it’s over ten times faster than the ‘full’ CurrentThread property accessor, the one I tested further up this article. That’s pretty cool! It makes sense that StringBuilder would use this over CurrentThread, if it were available. If they didn’t, any mutable change to a string would be ten times slower than it is now. That said, it still lags a lot behind PC; being around fifty times slower than that platform.

To reiterate though; unfortunately there’s no exposed direct access to CurrentThreadLite. As far as I can tell there’s no workable way of making use of it. I’d love someone to tell me otherwise though, it’d be awesome if I could use it.

StringBuilder though is still pretty slow on Xbox 360

In a previous article, I profiled some string manipulation code I’d written. Even though I was implementing alternate methods to what StringBuilder provides, in the end I still called their Append(). So I’d be incurring the hit from calling CurrentThreadLite too. It probably explains why the Xbox was running over ten times slower than PC.

I wonder if I can use reflection to grab the raw char[] data, and the string length. Then as long as I keep my code thread-safe by other means, I could work directly on the char[] buffer and concatenate strings myself. This would effectively do away with the overhead of checking what the current thread is, which is within all the existing StringBuilder mutable methods. Even though CurrentThreadLite is seemingly no slouch, it’s still not exactly cheap.

Something to think about… If it brings performance of StringBuilder in line with PC, then it certainly seems worth it. Whether it’s worth it for an XNA game though is arguable. Still, I found it interesting looking into this corner of C#.

References

• http://labs.developerfusion.co.uk/SourceViewer/view/SSCLI/System.Threading/Thread/
• http://labs.developerfusion.co.uk/SourceViewer/view/SSCLI/System.Text/StringBuilder/
• http://msdn.microsoft.com/en-us/library/system.threading.thread.currentthread.aspx

So, another entry in this StringBuilder and garbage series… This time I’m exploring the Format() method, and implementing a new alternative that does not generate any garbage. The existing AppendFormat() method on StringBuilder generates a significant amount of garbage.

So in what way does the .NET one generate garbage? Well, the parameter type is ‘object’, so you’ll get boxing and unboxing of value types. Since integers and floats are pretty oft-used with Format(), that’s not good news. With CLRProfiler I also see temporary allocations made in ‘String::ToCharArray()’, and ‘String::CtorCharArrayStartLength()’. There’s also more garbage if you use more than three arguments; for that it requires a temporary array to be created.

All in all, it’s not a pretty picture if you want to avoid garbage collections in your game.

Variable arguments

The AppendFormat() method takes a string parameter, then a series of parameter arguments. The amount of these can vary, and they can be of a different types too. So how best pass these in? Well, there are a number of different methods. Take a look at the ones StringBuilder provides as standard:

• StringBuilder AppendFormat( string format, params object[] args );
• StringBuilder AppendFormat( IFormatProvider provider, string format, params object[] args );
• StringBuilder AppendFormat( string format, object arg0 );
• StringBuilder AppendFormat( string format, object arg0, object arg1 );
• StringBuilder AppendFormat( string format, object arg0, object arg1, object arg2 );

Each of these uses object params. Object params are subject to boxing and unboxing with value types. Since I’d want to pass integers and floats through, this isn’t good. The other thing I noticed was that array parameters using the ‘params’ keyword cause a temporary allocation too. Even without using the object type, take this simplified example:

public void TestMethod( params int[] args );

Any call to this method generates garbage. The ‘params’ keyword essentially converts any params you might specify into an array. The array of integers in this case is allocated as a temporary and then destroyed. The same thing happens when using class types too, not just value types. A different tact is required here.

There were two approaches I explored to support a variable set of arguments, without generating garbage. One of these I went with and will explain now, the other one I explain later on this article in the ‘Things to try’ section. The approach I chose uses generics, and unfortunately a method is required to be implemented for each number of parameters I’d want to support. Other than that though, it’s a really good fit for this problem.

The implementation

So, there are two main problems to solve here:

• Support a variable number of arguments of arbitrary types
• Be able to use these types, perform any conversion required and concatenate them onto a StringBuilder

For the former, I’m just using generics. For each number of parameters I need to support, I’ll need to write a new method. This multiple versions of the same method, but with a different number of parameters isn’t too pretty. It reminds me of C++ template abuse, stuff like the sig_slot library.

But here it gets the job done, and it’s kind of your classic C# stuff in a way. There’s no support for default parameters in C#. So for different arguments you generally have to have wrapper methods to support different sets of parameters.

Casting generics is not like C++. My first thought was something like:

static public void FormatArgument( StringBuilder string_builder, T arg )
{
    if ( arg.GetType() == typeof(int) )
    {
        int int_arg = (int)arg;
        string_builder.Concat( int_arg );
    }
}

But the straight casting like this is not allowed. There does seem to be a couple of methods to convert types though. At least these were the two I found, both these examples are with integers:

• Convert.ToInt32( arg )
• Arg.ToInt32( System.Globalization.NumberFormatInfo.CurrentInfo )

Both have their downfalls. Convert.ToInt32() generates garbage, which makes it unusable for my purpose. The latter one though doesn’t generate garbage, but it is only available on types that implement IConvertible. Fortunately all the types I wanted to use (string, int, float) all implement IConvertible. However some other types that would be nice to support, such as Math.Vector don’t. I went with this method, and in turn had to limit the arguments to IConvertibles using the ‘where’ keyword.

That’s about it for the nitty-gritty on some of my decisions. The rest of the code is just a classic char-by-char over the formatted string. It’ll look for the ‘{‘ open curly bracket character and then use the Concat() methods from my previous article to push in the parameters. So, here’s the code:

StringBuilderExtFormat.zip

Performance

I was definitely curious as to how my code performs. There’s certainly more scope for optimization, but I’m not keen on spending time on it unless it’s something to worry about. Using the Stopwatch class I measured the runtime of this piece of code:

string_builder.ConcatFormat(
    "Test {0:0.0000} Test {1:X} Test {2} {3}",
    3.45111111f, 0xBEEF, 12345678, "Hello World" );

A nice taxing formatted string with varied parameters. Here’s a table of the performance figures, they are measured from a loop calling this method 1,000,000 times.

 
For both times and garbage, smaller is better!

The notable thing is that the native AppendFormat() performs the same when optimized or not. I’m not entirely familiar with the in’s and out’s of .NET assemblies just yet. But I do wonder if I could put these routines in a separate library. Then whether I can set things up so that they are jit-ed, regardless of whether my main code module is ran in the debugger or not. Not something I’m too interested in right now, but just throwing it out there. I’m sure google is my friend on this one!

Anyhow, I’m happy that on the final build of the game I’ll have better performance than the stock .NET method. Also with significantly less garbage of course. There’s plenty of scope for optimization on my methods too, they’re pretty much a naïve first-go in all cases. With a little time and effort I think a good chunk could come off these times. Knowing it performs well though is good enough for me right now, I’ll give it more attention down the road if I need to.

Things to try

A Format() that does everything?

Obviously the version I’ve written doesn’t offer anywhere near the same fully-featured functionality as the stock .NET Format(). I don’t envision myself needing any more features for a game though to be honest. If I did come across something I wanted it wouldn’t be too much of a pain to implement I’m sure. But, take a look at the .NET docs, and the AppendFormat() source code:

http://labs.developerfusion.co.uk/SourceViewer/view/SSCLI/System.Text/StringBuilder/

The AppendFormat() in StringBuilder is the one that is also used by System.String and I’d assume the rest of the .NET code. Using this source and any documentation for the formatting specifiers, it’d be possible to implement the same level of functionality but using my techniques to avoid garbage. Quite a task though I’d think!
 

Supporting arbitrary parameter types

Another thing to give a go, is a second method of variable arguments I played around with. A method that doesn’t use generics, but instead uses a base class. For an example, here’s a method prototype with two arguments:

public static StringBuilder ConcatFormat( this StringBuilder string_builder,
    String format_string, FormatArgument arg1, FormatArgument arg2 )

The ‘FormatArgument’ class is an abstract base class. What you’d do is implement subclasses for each supported type, i.e.:

public class FormatArgumentInt : FormatArgument

Then have a virtual method for appending the type into the StringBuilder. The crux of this whole technique is in the use of implicit constructors. So that depending on the argument you specify to ConcatFormat(), you’ll get it converted into a new FormatArgument type. Here’s an example:

public static implicit operator FormatArgument( int value )
{
    FormatArgumentInt arg = new FormatArgumentInt( value );
    return arg;
}

Hey, this example allocates a temporary class therefore generates garbage when used? Indeed it does, but you can use a pool container to deal with this. Pre-allocating all of these and dealing out pool items when they’re created solves the garbage issue. You’ll also need to manually dispose of them and add them back to the pool.

It’s a lot of work. The big upside is that you can support any types, such as Math.Matrix and Vector. It’d be cool to be able to use those if you’re using Format() for debugging. In my experiments though, performance wasn’t too hot, it was in the region of 1.5-2 times slower than the generics method I detailed earlier. The code also becomes a lot more unwieldy; the generics method looked like a work of art by comparison!

Maybe there’s a way of using the generics method on arbitrary non-IConvertible types? Without incurring garbage on the conversions too of course.
 

Printf

I like the positional arguments of C#’s Format. C/C++’s printf() stipulates that the argument list has to be used in the same order that the params are specified in the formatting string. This makes the .NET way useful for localizations particularly, where something like:

Player {0} got {1} points!

Could become:

Allez {1} punts spiele {0}!  << Just a made-up foreign language

Essentially the translation requires those parameters to appear in a different order. With printf() it’s painful to do this correctly.

That said though if you’ve used printf() for over a decade like I have, switching to Format() might not be quite as fun. So why not implement printf() in C#? It’s really only a minor modification over the code I provide above. I was a little tempted myself, but I really want to stick with doing things the C# way for now.

References

• http://msdn.microsoft.com/en-us/library/system.iconvertible.aspx
• http://msdn.microsoft.com/en-us/library/system.convert%28VS.71%29.aspx
• http://blog.stevex.net/string-formatting-in-csharp/
• http://www.codeproject.com/KB/cs/Csharp_implicit_operator.aspx

In my previous coding post, I spoke about some issues with converting a mutable StringBuilder string back to a regular ‘string’ object without generating garbage. Well, specifically without requiring an unnecessary heap allocation. One thing I hinted at was that StringBuilder has a number of other methods which generate garbage too. In fact, there are a lot of important fundamental methods which do, which are difficult to live without.

As I’ve mentioned before, worrying about this sort of thing may not be necessary for the game you’re working on. It’s much more of a concern on Xbox 360 than PC, due to the poorly performing garbage collector on 360. If your game isn’t something that’s going to remotely push the hardware, or be impacted by dropped frames, then you really don’t need to worry. This article is just for those who may see this as an issue, and want to explore ways to eliminate this particular method of generating garbage.

Problem StringBuilder methods

So, here’s a table of all the methods StringBuilder has. My test case used a StringBuilder constructed with an initial capacity of 1024 characters. This is plenty for anything I threw at it, so any garbage I found with CLRProfiler was not something associated with reallocating the StringBuilder internal string. In the cases where there’s garbage generated I’ve commented with the most interesting or appropriate function in the callstack. In many cases it’s just exactly the same method, but with the function signature reported by CLRProfiler.

* Technically you could describe these as not generating garbage, simply allocating a new string for the client to use. Certainly for the latter of these it makes sense, the term garbage is a little incorrect. But for the former, hence my previous article, it’s unnecessary and can be avoided with a little work.

The common theme for garbage here is type-conversion. Anything that isn’t a string or char type is pretty much guaranteed to generate it.  ‘bool‘ is an oddball I think probably because it inserts string literals: ‘false’ and ‘true’, so no conversion is needed. The other peculiar one is the Insert( int, char ) one, it generates garbage when logically it doesn’t really need to. Oddly the .NET library source code says it calls Char.ToString() on the char parameter. Possibly just an oversight in the library?

The reasoning for the type conversions generating garbage, is that they return a temporary string converting that type to a string. This string is then fed into the StringBuilder, and then discarded. Whilst it could have been done in-place, I think the reason why it isn’t is to support CultureInfo modifiers on the conversion. Where that conversion could take place in a different way based on the passed in CultureInfo. StringBuilder internally uses CultureInfo.CurrentCulture.

I think the implementation chosen was for simplicity and clarity of the type conversions. Writing a system to perform these type conversions in-place and have the flexibility of what CultureInfo offers, would have likely made the code significantly more complex. I can understand their reasoning completely.

Appending numeric types without generating garbage

For this article I specifically wanted to detail a replacement for those type conversion methods. These are ones you’d definitely need for a game, for at least your HUD readouts. Since these could be updated every frame, using the garbage-churning .NET library methods isn’t going to be pretty.

The replacement methodology I used was pretty simple; a number of methods don’t generate garbage, so use those to build up the string. This effectively means implementing an itoa() in C#, a conversion of an integer into string form. Floating point numbers too being handled in much the same way. My implementation is via C#’s extension methods. So the new garbage-free versions of Append() can be called directly on a StringBuilder object, as if they came with the original framework.

Here’s the code for download:

StringBuilderExtNumeric.cs

Since Append() is already taken, I chose Concat() as my alternative. There’s additional functionality over what’s offered by default in StringBuilder, to aid formatting of text. For floats you’re able to specify the amount of decimal places. For all numeric types you can specify the amount of padding, and the padding character used (most likely zero or space). Lastly, integers can be output with a specific base value, so your code could output hex, binary and octal if so desired.

Here’s a short made-up example of it’s usage:

StringBuilder m_hud_health_string = new StringBuilder( 64, 64 );
StringBuilder m_hud_ammo_string = new StringBuilder( 64, 64 );
 
private void UpdateHUDStrings()
{
    // Note: It's sensible to create a wrapper for Concat( string ), which just calls
    // Append() to avoid mixing these method names. When JIT-ing, it would be inlined.
 
    m_hud_health_string.Length = 0;                    //< Clear the string
    m_hud_health_string.Concat( GetCurrentHealth());   //< This method returns an int
    m_hud_health_string.Append( " / " );
    m_hud_health_string.Concat( GetMaximumHealth());   //< This method returns an int
 
    m_hud_ammo_string.Length = 0;                      //< Clear the string
    m_hud_ammo_string.Concat( GetBulletsInAmmoClip()); //< This method returns an int
    m_hud_ammo_string.Append( " ( " );
    m_hud_ammo_string.Concat( GetNumAmmoClips());      //< This method returns an int
    m_hud_ammo_string.Append( " )" );
}

But, what about Format(), I hear you cry? It can sometimes be easier to format more complex strings, and can result in much cleaner code than multiple appends/concats. Well, I have a garbage-free one of those too. I’ll cover its implementation next time I write about C# here.

Some other things to try

The code I’ve written probably (definitely) could be optimized further. In case you need to do this, or if you’re just curious and want to play around, I’ve got a few ideas of things to try:

• Different code for the oft-used base ten. You’re now modulo-ing and dividing by a constant, and passing one less parameter around. You can also just add characters by using ( ‘0’ + value ), instead of using the static char array. The static char array is just used since the hex ‘A-F’ don’t follow ‘9’ in the ascii table.
• Try using a static char[] array to generate the string you’re about to append, and just call Append() once on the StringBuilder. StringBuilder keeps itself thread-safe and has other overhead on most of its members. So I think this would result in a speedup, by just making one mutable interaction with the StringBuilder.
  Keep in mind that you’ll want to make this array a [ThreadStatic] (thread-local store), so that you can use the code on multiple threads without issue.
• Take a look at these two websites for some more ideas:
  Coverage of some common C implementations, along with some performance comparisons.
  A bit of a different approach using C++, potentially may throw up something applicable to C#.

Another thing worth considering is to wrap up the StringBuilder into a new type. Maybe a struct is a good idea, to save making another heap allocation when creating them. The reasoning behind this is to hide away the garbage-generating methods. So all you’re exposing are the safe, garbage-free methods. It also saves you having to awkwardly come up with a different method name, such as ‘Concat()’, like I did. Another win for this methodology is that you could write operator overloads to support ‘+=’, to perform concatenations too.

References

• http://forums.xna.com/forums/p/16395/87923.aspx
• http://www.jb.man.ac.uk/~slowe/cpp/itoa.html

Back when I last had a little spurt of writing in this blog, I really wanted to talk about ‘Pathologic’.

An awesome, unique PC game certainly unlike any other game I’ve played before. Its survival horror pushed to extremes. The development house is based in Russia; Ice Pick Lodge.

I’ve much respect for the game, I tip my hat to a fantastic achievement. My sole disappointment was just that only few people got to experience this gem. Maybe when I play through a second time as a different character: ‘Haruspicus’, I’ll get the gumption to write about it to convince the small readership of this blog to give it a try. Knowing that day will likely never come, please read this review:

http://www.rockpapershotgun.com/2008/04/10/butchering-pathologic-part-1-the-body/

It’s what led me to give it a try in the first place. It’s an old game, so go easy on the graphical criticism… Speaking of which!

Deadly Premonition – A ‘B Game’, as in ‘B Movie’?

Aye, not the prettiest game on the eyes given we’re talking an Xbox 360 game. But really, it’s another time to ignore that. How I link this to Pathologic isn’t too direct, the games share some similar elements in how they expand the survival aspect of gameplay. They’re both very unique games, very different to the usual AAA fare.

The fuss over its review scores is what led to me noticing the game. I suspect all the furor over it has led to it getting nice sales. Oh, by the way; did I mention that Deadly Premonition is a new release and priced at only $20? Unfortunately European guys, it’s not released out there yet and the US version is apparently region-locked. It’s quite a shame.

What I’m about to write about is free of spoilers. With a game like this I really wanted to avoid reading too far down into reviews. I’ll respect anyone reading this by attempting to just lure you into buying it and not ruin any of the nice surprises in the game. I haven’t got too far into the game, I’m only a little after the investigation of the crime scene. Probably only three to four hours in.

First Impressions

When I first fired up the game it was what I was expecting. Nice initial cutscene to set the mood. The devs have their names flash up during the opening sequence too, kind of like COD4 in a way. I was a little surprised to see that the devs are all Japanese; I didn’t remember reading that in the reviews that I skimmed. Things fall into place now; I can’t see a Western dev attempting a game like this. It’s ‘M-rated’ too. If this were a big budget game I’m sure the publishers would have them water it down to a ‘T-teen’ rating, and market it as a CSI-style game. Thank god that didn’t happen! I’m real curious as to how long the game was in development, does anyone know?

My first warning when picking up the game is that you will be a little frustrated with how gameplay starts out. It’s not long before you’re dealing with combat. Yes, there is combat in this game but it doesn’t seem to be the main focus of the title at all. If you get the game and give up whilst you’re in that first part of combat; you’ll be missing out for sure. Persevere.

Also, one big tip I can give which didn’t seem to be mentioned in the manual, nor on-screen is that holding ‘B’ and another face button together will speed up the text scrolling. You can also press start to skip any scrolling text. The game has a number of rough edges which frustrate me as a coder. The sort of things that if I were set loose on the code for a week, I’d have fixed immediately. Here’s a few that come to mind:

Minor annoyances:

• Animations such as opening doors begin to feel too long, and are unskippable.
• Cutscenes can’t be paused, or at least I haven’t found a way how. The guide button doesn’t pause them unfortunately.
• The pause menu is a little clunky and slow
• The world map doesn’t zoom out far enough. It also doesn’t appear on the HUD during combat at all, which is frustrating.
• Saving is a little arduous. If autosave is enabled, when I use a telephone to save the game, I shouldn’t get a bunch of confirmation UI screens.
• Collision. A couple of times I’ve got caught on a ninety degree concave edge of a room. The player control should be a little more forgiving and push you around if you’re close to the edge.
• They spell ‘Turkey Sandwich’ as ‘Turky Sandwich’[sic] at one point in the game! Unforgivable!

Wow! I’m doing the game lots of favours here eh? Who’d want to play this mess? Well, the game is a breath of fresh air in 360-land. It’s awesomeness I simply do not have the superlatives for. Here are some things I think rock about this game:

Premonition of greatness:

• Voiceovers. These really shine. Compared to say the Bethesda games: Fallout 3 and Oblivion… There’s so much charm to it, and it really highlights how soulless the VO on those games sound sometimes (they’re great games of course, just one criticism I have of them). The game treads a fine line between comedy and horror, and the style fits it extremely well.
• The music. It’s fantastic! It’s simple stuff and I haven’t heard many different tunes but the cues alongside the cutscenes, and the way it sometimes drowns out the dialog… It just feels right. The main protagonist is a little ‘special’, so I see it as him drifting off into la-la land when it happens.
• The story. It’s a pretty gripping one. Despite the bat-shit insaneness where the game steps into comedy, the storyline is always intriguing. You actually care about what happens, and moreso you’re wanting to see what the slightly insane twists on what’s coming next could be.
• Survival elements. I like that you need to make sure that your car has topped up petrol. I like that you need to sleep and stave off your hunger. Apparently too you have to change clothing as the days progress otherwise people start to think you smell. I liked the similar mechanics in Pathologic too. Where on something like GTA: San Andreas they can become annoying; here these mechanics suit a survival horror game perfectly.
• Open-world gameplay. Near the beginning of the game you’ll meet up with some locals who want you to drive them somewhere. You can leave them at any time, and when you meet up with them again later they’ll be pissed at you for leaving them waiting. The cutscene transitions during open-world gameplay are pretty cool too, big thumbs up.
• It’s GTA meets Resident Evil, meets Maniac Mansion, meets CSI, meets Criminal Minds (unsub!), meets Spaced, meets Twin Peaks. What’s not to love about that?
• Laughter, fun, entertainment. It’s easy to forget sometimes that games can be fun! Take some serious gruff-voiced guy, who’s built like a brick-outhouse. Navigate him through a repetitive dull environment; it’s what the kids seem to like now. The vibe of this game is different, wholly unique; it’s something I’d recommend to anyone who thinks that games are an artform.

One third and final list now. From what I remember of when I skimmed reviews, there were a number of things that were mentioned as negatives that I really think are no big deal at all. Granted I’m only a small portion through the game, but I have encountered and seen pretty much all the things that have been complained about. Whether the charm lasts is another matter, but I feel like I’ll get my money’s worth out of this game for sure.

Don’t you love journos?:

• The graphics. C’mon, this is a budget title. The characters in my opinion are above the quality of most PS2 games. The outside environments probably on par with early PS2-era games, the interiors look much better. Go have a wank over the latest Final Fantasy if pretty scenery is what does it for you.
• The combat, the camera, the controls. They take a little getting used to; by the second section of combat I was a dab hand with the FBI issue shooter. The complaints here are probably because the controls don’t match the ‘generic third-person game’ controls. Whatever; it’s not hard to get to grips with them.
• The sparse environment. There are actually a lot of residents in Greenvale. The story though is of a town which had a boom a few decades back due to a buoyant lumber trade. The town now is relatively empty since those days. The hospital is too big for what the town needs; the hotel is almost empty. Sounds perfect for survival horror?
• Terrible writing, terrible story, terrible voiceovers. You must have really missed the point.

So there, go play it. It’s only $20!  If you don’t like it, go trade it for a grey and brown shooter; there’s plenty sitting in Gamestop.

In my day job I’m a bit of a stickler with memory. I’m at times approaching borderline OCD I think with budgets and fragmentation. Having a good handle on memory usage on a game is very important; once you start pushing a console’s limits you can cause a lot of headaches down the road if you’re not mindful of things like memory budgets. Forgetting about fragmentation until it’s a big problem is also a bad idea. Once you’ve started bad practices like this on a game, they tend to snowball and you’re in for a hard uphill battle once they become a problem that needs fixing.

With working in C# and XNA now, the big enemy on the memory front isn’t really fragmentation or running out of available memory. The Xbox 360 has plenty of memory for any project I’d try and tackle myself; coder art for the win! The problem is one of performance, more specifically the lack of performance of the garbage collection system. Garbage collection on the 360 isn’t as full featured as on the full .NET Framework on Windows. It lacks the ‘generational’ model that the full Framework offers, meaning a full collection is performed whenever the system deems it necessary to do one.

Having random CPU spikes in your game is a nightmare. More so that in the case of garbage collection on 360 there’s little control other than being able to invoke a collection yourself manually. If you’re generating garbage at runtime during gameplay, you are going to see spikes in your frame times. With just a little garbage generated, and if your game isn’t CPU-bound, you may be able to get away with not giving this any attention. However given my nature with this sort of thing, I want to run a tight ship with this being a potential future headache if I don’t do so.

That said, I think for any sort of menu system I’d have, I’d probably be happy to let it generate garbage and then just call GC.Collect() when we go back to gameplay. Giving it a different treatment entirely to how I’d handle the regular runtime gameplay of the game. It’s all about where it’s important to concentrate efforts to avoid garbage.

Profiling

For profiling any garbage my game might generate I use CLRProfiler for Windows. It gives a nice in-depth analysis of memory usage, it’s pretty much invaluable for dealing with garbage collection problems. It’s almost worth keeping your game always running on a Windows target just so that you can make use of it!

On 360 I use the ‘Remote Performance Monitor’ that comes with the Game Studio SDK. It’s nowhere near as detailed, but it does give a good indication of the severity of any garbage collection issues with your game. Discussing how I use these tools is beyond the scope of this blog post, Google is your friend.

The String and StringBuilder problem

The StringBuilder class in C# is the preferred way of working with string manipulation if performance is important. You can avoid it entirely, but you’ll be very likely to end up generating garbage at runtime if you’re exclusively using the string type.

For example, avoid using the ‘+’ operator to concatenate strings. Strings in C# are immutable, meaning they cannot be modified. If you perform this kind of operation, your resultant string will be allocated on the heap. It’s very easy to generate lots of garbage with this sort of code. Something like this monstrosity, which could be run every frame:

string show_world_details = “[ FPS :” + GetFPS() + “ P1 Health:” + GetHealth() + “  ]”;

StringBuilder allows you to work with a mutable string. It provides functionality to concatenate other strings, and other types onto your mutable string. Many of the functions of StringBuilder are completely garbage-free. Many however are not. I’ve a future post in the works which will cover that particular problem in more detail. For now, concatenating other strings onto the StringBulder is garbage-free. So that’s the method I’ll stick to for the sake of this post.

What I wanted to discuss was the conversion of your built up StringBuilder to a string type. There are many functions within the .NET library which only take strings as parameters. Thankfully on the XNA side, the DrawString() rendering routines do take a StringBuilder argument natively. However other functions such as those that write debugging output to Visual Studio or the console, only take string parameters. So in walks StringBuilder.ToString()…

ToString() code

So does calling ToString() generate garbage? My first expectation was that of course it would, it’d just copy what the string is into a new immutable string object created on the heap. This however is not the case, or at least sometimes it isn’t the case. To avoid beating around the bush here I’ll show you the actual source code of the ToString() method:

public override String ToString() {
 
    String currentString =  m_StringValue;
    IntPtr currentThread = m_currentThread;
 
    if (currentThread != Thread.InternalGetCurrentThread()) {
 
        return String.InternalCopy(currentString);
 
    }
 
    if ((2 *  currentString.Length) < currentString.ArrayLength) {
 
        return String.InternalCopy(currentString);
 
    }
 
    currentString.ClearPostNullChar();
    m_currentThread = IntPtr.Zero;
 
    return  currentString;
}

Bit hairy, no? InternalCopy() is the function which will allocate a copy of the string on the heap and return it. The function can actually return the internal string without making any copies. Specifically the first time it’s called, and if the string makes use of at least 50% of the StringBuilder capacity. The ‘m_currentThread’ member being set to zero will effectively mean that the next time any sort of mutable operation is performed on the StringBuilder; be it clearing the string, or appending to it. The StringBuilder will allocate a new string on the heap. Each of the mutable methods of StringBuilder check the ‘m_currentThread’ and ensure that the StringBuilder owns the particular string. The way ToString() works, it’s effectively giving away ownership of that string and will start with a fresh one on the next mutable operation.

The reasoning behind this thread noting, as well as keeping the String returned by ToString() completely immutable, is to keep StringBuilder thread-safe. There’s comments within the code that detail the potential race condition that could occur, which I have omitted above. You can see them in full here.

The other reason for making the copy is in the case that the user is making inefficient use of memory. If we’re only using a tiny portion of the StringBuilder capacity, the .NET authors deemed that it’s more efficient to return a copy instead of making reference to the full big string.

If I want to re-use a StringBuilder object, say for some kind of readout I might want Visual Studio to display in the debugging output window. I’m out of luck garbage-wise. I may avoid generating a copy of the string the first time I call it, but if I’m reusing the StringBuilder, it’s going allocate a new string on the heap for me when I call the next mutable method on it.

The solution

What I wanted was direct access to the string that the StringBuilder works with. Doing this on Windows with ‘unsafe’ code is most likely straightforward, but I want to target 360 so that’s a non-starter. On the 360 you’re bound by the shackles of the Compact Framework, if it’s not in there, you can’t use it.

Thanks to this article though, I was able to track down a method to be able to access that internal string object which the StringBuilder works with. It’s effectively doing something the .NET library authors don’t want you to do, grabbing that private member (oo-er). Thankfully this also works on 360!

Here’s the code:

string my_string = (string)my_stringbuilder.GetType().GetField(
    "m_StringValue",
    System.Reflection.BindingFlags.NonPublic |
    System.Reflection.BindingFlags.Instance ).GetValue( my_stringbuilder );

Reflection isn’t too pretty, eh? But here it’s a nice devious means to an end. Reflection isn’t too hot performance-wise, so I’d recommend grabbing the internal string just the once for the StringBuilder you’ll be working with. Stash it away as a member of a class or something, and you’ll then have the string to pass along to whatever function you wish. Now we’re no longer worrying about the ToString() generating garbage for us; success!

Here’s a bit of sample code:

StringBuilder my_stringbuilder = new StringBuilder( 32, 32 );
string my_string = (string)my_stringbuilder.GetType().GetField(
	"m_StringValue", BindingFlags.NonPublic | BindingFlags.Instance )
	.GetValue( my_stringbuilder );
 
my_stringbuilder.Append( "This " );
my_stringbuilder.Append( "Is " );
my_stringbuilder.Append( "A " );
my_stringbuilder.Append( "Test!" );
 
// my string will be "This Is A Test!"
Console.Write( my_string );
 
// This second append would have resulted in a new heap allocation
// if I'd used ToString() above.
my_stringbuilder.Append( " Yay!" );
Console.Write( my_string );

I’d advise creating your StringBuilder objects with the two integer parameters contructor. As well as preallocating the string, you’ll also be putting a cap on the capacity:

// Creates an empty StringBuilder with a minimum capacity of capacity
// and a maximum capacity of maxCapacity.
public StringBuilder(int capacity, int maxCapacity)

Meaning it’ll never grow in size, or make any more heap allocations after it’s initially constructed. If that were to happen, the string object you grabbed is no longer linked to the StringBuilder. You’d need to redo the reflection call to grab the new string that the StringBuilder owns.

So by using that constructor, this means if you grab the internal string you’re guaranteed to keep the reference to the StringBuilder’s mutable string forever. The one key exception here though is if you work with the StringBuilder on another thread. In that case, you’ll be subject to the same issues as before.

I’ll revisit StringBuilder here again in future, to cover some of it’s other shortcomings with regard to generating garbage.

References

• http://www.codeproject.com/KB/dotnet/strings.aspx
• http://blogs.msdn.com/shawnhar/archive/2007/07/02/twin-paths-to-garbage-collector-nirvana.aspx
• http://blogs.msdn.com/netcfteam/archive/2006/12/22/managed-code-performance-on-xbox-360-for-xna-part-2-gc-and-tools.aspx
• http://blogs.msdn.com/stevenpr/archive/2004/07/26/197254.aspx

During development, generally your testers will be running a version of the game that could be a number of days old.

By the time you’ve got back bug reports there is likely to have been significant progress on the game since. There’s every chance during interim development that bugs could have been fixed before QA found them. Also, the goalposts could be moved; some aspect of the title may have been significantly changed and that bug report you got no longer makes any sense.

For these reasons it’s imperative that when you get back bugs, you know what version of the game they were running. There’s a number of ways you can address this:

Version Numbering

• Can be in various forms. Could possibly be a hard coded string, some piece of built data, or the version number built into a PC executable header.
• Many PC applications shipped just use simple version numbering to denote their builds. You still see a lot of “beta version 2.0.1.1123″ style versioning on commercial software sitting out on webpages.
• Manually updating the minor revisions each time is an easy thing to forget. It is possible to set up most development environments to auto-increment this number. If there’s no native support, it can usually be hacked in as a pre-build step.

Source Control Revision

• There’s dozens of different pieces of source control software. With the majority of them it’s possible to synchronize to an explicit revision of the source tree. The revision number a game was built from can be used to identify a build.
• As a pre-build step it is possible to automatically embed this revision number into the game.
• Some source control software doesn’t have any sort of global revision numbering. Visual Sourcesafe springs to mind; that one only logs revision histories on a per-file basis. A single revision number to identify a particular build of the game is not possible. For Sourcesafe though it is possible to apply a label to the whole source tree. That could be done with each significant test build, with a version number of some kind.

Date/Time Stamping

• Simply the date and time at which the build was created. Similarly to the source control methods, you can easily pinpoint exactly what code and data made it into the particular build of the game.
• It falls down a little if your source control still accepts submissions, and you have other users submitting code whilst a build is being created. When cross referencing the date and time you actually built the game, it could appear that some changes got in that actually didn’t. This is no big deal if you lock out your source control whilst making a build for testing, or if you only have one person on the project.
• Don’t use the timestamp of the executable itself! Aside from easily being able to be overwritten (the create and modified dates could be blitzed over for example, with particular unzipping or CD burning software). On the Xbox with XNA it’s not actually possible to inspect the executable’s date using the System.IO calls.
• It is generally possible in most development environments to embed the current date and time into code. In C# this is actually possible in a very nice, clean manner. Updated intelligently each time you build an executable.

With your average XNA game you’ve got no QA department to rely on. Most testing would probably be done by the developers, and their friends and family. The easier and more transparent this identification-marking is, the better.

Automatic versioning in C#

C# does provide automatic versioning in the form of an implicit change to the assembly version. For a newly created XNA project you’ll have an ‘Assembly.cs’ file. At the bottom is the version number:

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version
//      Build Number
//      Revision
//
[assembly: AssemblyVersion("1.0.0.0")]

If you change the line to the following instead:

[assembly: AssemblyVersion("1.0.*")]

The last two numbers in the version will now be automatically filled in when the assembly is compiled. The numbers it fills in with are based on the current system date and time. So by doing this you’re effectively able to timestamp the built date of your game into the version number of the assembly. Both PC and Xbox are able to grab this version number, so it can be displayed within the game or on any sort of ‘game has crashed’ screen you have.

The first two numbers, the major and minor version can still be used for their usual purpose. If you’re so inclined.

The ‘build number’ and ‘revision’ portions of the version can be grabbed and converted to a C# DateTime class, with the following code:

private DateTime DateCompiled()
{
    // The assembly version must have the last two numbers removed and replaced with *
    // It should look something like this: 
    // [assembly: AssemblyVersion("1.0.*")]
 
    //Build dates start from 01/01/2000
    System.DateTime result = DateTime.Parse("1/1/2000");
 
    //Retrieve the version information from the assembly from which this code is being executed
    System.Version version = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version;
 
    //Add the number of days (build)
    result = result.AddDays(version.Build);
 
    //Add the number of seconds since midnight (revision) multiplied by 2
    result = result.AddSeconds(version.Revision * 2);
 
    //If we're currently in daylight saving time add an extra hour
    if (TimeZone.IsDaylightSavingTime(System.DateTime.Now, 
        TimeZone.CurrentTimeZone.GetDaylightChanges(System.DateTime.Now.Year))) 
    { 
        result = result.AddHours(1); 
    }
 
    return result;
}

Courtesy of this post from dotnetfreak.co.uk of equivalent VB.NET code.

So, this is what I’m going with to tag my game builds. It covers me for what I need, and requires zero maintenance.

Note:

It is mentioned on a number of webpages that the ‘build number’ and ‘revision’ numbers don’t update on each build. It’s said that they only update each time you actually start the Visual Studio application.

However, I haven’t found this to be the case with Visual Studio 2008. Both the PC and Xbox XNA projects update this just fine. I can edit any .cs file in my project, and the game gets a new timestamp. I believe that the posts about the bad behavior were with Visual Studio 2005 and 2003.

XNA content pipeline files though, do not affect the timestamp at all. This makes total sense though, as the binary xnb data files aren’t part of the actual executable assembly.

References:

• http://dotnetfreak.co.uk/blog/archive/2004/07/08/determining-the-build-date-of-an-assembly.aspx
• http://stackoverflow.com/questions/324245/aspnet-show-application-build-dateinfo-at-the-bottom-of-the-screen
• http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.assemblyversionattribute.aspx

So, I alluded to the fact I wanted to begin writing about XNA in my last post. Over the Christmas break I began getting to grips with C# and XNA, and wrote some code to have a go at prototyping a game idea I had. I think it’s pretty cool that you can execute your code on a retail 360 as well. It’s not quite as nice as using a devkit with native code, but it’s pretty close.

Note to Microsoft: Make it easier to launch the XNA connect app from the dashboard. I know it’s not meant to crash, and it doesn’t that often. But I’ve been attempting some dodgy things and I’ve had it fall over several times. It would be great if it appeared at the top of your ‘Game Library’, as the XNA apps themselves do. For the connect app I have to always scroll to the ‘community games’ section and pick it from there.

Environment

Anyway, I thought the best place to start would be to describe the environment I’m working with:

• I’m targeting both 360 and PC for the moment, but there’s every chance I might drop one platform in the future. I have no plans to write anything for the Zune.
• I’ve setup two extra build configurations in addition to the existing ‘debug’ and ‘release’. One named ‘final’, which would be the intended executable for the final version of the game to be dished out to the public. ‘release’ is the configuration which would have optimizations enabled; but would still have some debugging code which I wouldn’t want in the final game executable. ‘release’ would also enable assertion code, which is omitted completely in ‘final’. The second new configuration is ‘profile’, which is the same as ‘final’ for all intents and purposes, but compiles in profiling code. I wrote my own basic profiler, as I had nothing but trouble with nprof on PC.
• I have the code in two portions: I have a library in which I put what I’d deem as my ‘engine’ code, the stuff in there is (relatively-speaking) clean and what I’d want to keep if I scrapped a game idea and went with something else. The other portion is the game-side code, here I’m less fussy about organization whilst I’m just prototyping some ideas. Any code samples I put on this site though will be in a simple form which just an executable target, no libraries.
• The code I do post will be namespaced ‘Cute’. Why? Well, I’m focusing on doing a graphically primitive cutesy style game, with bright colors and simple geo. I’m no artist. Rather than come up with some other namespace for code I put here, I’ll just post the one I use.

Build Configurations

So, on to the build configurations. Here’s an explanation of each, and the extra compilation symbols I define:

Debug: Code optimization is turned off, TRACE and DEBUG are defined. The same as a new project in devstudio would be for it’s debug configuration. I also define the symbols ASSERT and PROFILE for this build. This would be the build I’d drop down to diagnose any problems that were tricky on a release build, due to the code optimizations.

Release: The same as debug, except with code optimizations turned on. TRACE is defined only on Xbox for debug output (see later note), DEBUG is not defined on either platform. This is generally the build I work with most. It runs at a good frame rate, I have assertions and profiling. As mentioned I’d only drop down to the debug build to work more accurately with the debugger.

Final: This is the ‘shipping’ build. Compared to release, the ASSERT and PROFILE defines are removed. Essentially all development ‘fluff’ is out the window; the executable is expected to behave perfectly. The frame rate should also be somewhat better than release too because of this. Though right now given the early stage of my work, there’s really no difference to see just yet.

I define a FINAL symbol here as well, in case I want to conditionally compile in or out pieces of code specifically for this build.

Profile: For this build I use the same setup as final, but with the PROFILE define enabled. I lose the overhead of assert checking from the release build, so have pretty similar performance to my final build. However my profiler is usable, so this build is perfect for testing any optimizations I might perform on the game. I also enable TRACE on Xbox, which is explained a little later.

I’ve shoved some screenshots at the bottom of this post, for clarity too.

Defined Symbols, Debug Output on 360

ASSERT and PROFILE defines? I’ll post in future covering how I use those. It’s pretty straightforward what they do when turned on and off though.

I define the symbols just a tad differently on 360 though. The Xbox 360 only has working debug output with the TRACE or DEBUG defines turned on. Here’s a table showing the debug output functions that are available, and how they behave on the two platforms:

PC

360

So, the defines differ on my 360 build. I have TRACE enabled on my release and profile builds, so I can get output. My profiler though, I hope to eventually get to render to the screen. Instead of it just dumping captured data in text form to the debug window. So I may be able to disable TRACE on my 360 profile build at some point in future.

On PC I route my printouts through System.Console.Write, on XBOX through System.Diagnostics. Trace.Write. I have a locally namespaced function that behaves correctly for both platforms. Yes, I could just have TRACE defined on the appropriate builds for parity… But I just don’t trust that it has zero other detrimental effects on performance.

Phew…

That’s it for the moment. Dry preparation is out of the way, this is more of a primer than anything. Something I can link back to in future to explain my #ifdef madness. Somewhat more useful stuff to come next…

Oh, here’s those configuration screenshots I mentioned:

PC: Debug, release, final, profile.

360: Debug, release, final, profile.

That said, I’ve started to code a little in my free time. I got a block of time over the Christmas break and I decided to have a good go at doing some stuff with XNA and C#. Was a good experience, I feel a lot more comfortable with C# now. I’ve learnt to live with some of the annoying differences between it and C++. I code in the latter every day for my day job; for another language that’s so close to it, it takes a bit of a leap to leave the old ways behind.

So, hopefully I’ll give this blog a bit of a new lease of life soon with some tidbits from my XNA adventures. I’ve got a couple of ‘in-progress’ articles going already.

Anyway, Metallica…

The last time there was rumblings of a Metallica game was back in 2003:
http://cube.ign.com/articles/422/422960p1.html

… and I would know nothing about such a game at all of course… *whistles*

Damage Inc. [Metallica car combat title] (PC/PS2/GC/XBOX, Climax/VU Games)*

http://www.destructoid.com/surfer-girl-is-back-with-a-cancelled-game-list-50625.phtml
Seems like a very long time ago now… I’d like to say more about it, but it’s probably not a good idea.

Like Aerosmith last year, my involvement is pretty minimal; I’m working on something else right now. The Metallica game is based on the World Tour engine, so all four instruments are playable. Unlike with the Aerosmith game, where you were limited to just guitar and bass.

As per usual, with the press-situation for these sorts of things I really can’t say anything in more detail. It looks fantastic and I think the fans are going to be dead impressed with it.