Gavin Pugh - A Videogame Programming Blog

On and off during the last month or so, I’ve worked toward finishing a project I wrote about last year. It’s an Amstrad CPC Emulator, written in C# using the Microsoft XNA library. I’ve written plenty about the background and motivation in the previous blog post. This post is just here to announce the finished product, and touch a little on the things I’ve worked on recently.

The picture above is from Hewson’s “Nebulus”. Now that the emulator has a pretty complete feature set; games like these are very playable now. It makes a world of difference having the audio fully working now, for example. It also is great to finally be able to play at the original, full frame rate on Xbox 360. Surprisingly the 360 had trouble emulating this seemingly primitive machine!

Anyway, after the jump is a video showing the emulator in action on the 360…

Read more »

So yeah, this is another post detailing a change made in the latest version of XNA.

This one was inspired by some comments on a previous blog post of mine: “StringBuilder to String with no garbage”. A developer named Matt, who was targeting Windows 7 Phones, pointed out that this particular trick with reflection was not working. He’d get a ‘FieldAccessException’ when attempting to access the internal private System.String object.

I’d just got round to installing the Windows Phone stuff to check this out, and indeed this is the case. I tried various different flags in the GetField() call, but had no luck in getting it to work. I tried setting up a trivial case with my own class containing a private ‘System.String’ and had the exact same problem.

Read more »

I initially begun writing this particular article back in April. Back then with XNA 3.1 to play with, there was actually a method of ‘thread-local storage’ for Xbox. With the release of XNA 4.0, this last remaining native method was removed. The [ThreadLocal] attribute though was added to the Compact Framework, but it seems to be a stubbed non-functional attribute on Xbox 360.

So, where does that leave us? There is various ways you can manually code up a thread-local storage solution. The whole crux of it is data-retrieval and storage on a per-thread basis. The most immediately obvious way to go is just some sort of associative container, a Dictionary<> of some sort of thread ‘id’ mapped to the data you wish to store.

Read more »

Continuing on from my last XNA post, I had a go at using [ThreadStatic] on the Xbox. Specifically this attribute was not available with XNA 3.1, but was introduced in the new 4.0 version.

At first glace it worked fine, I threw in the same code I’d used on Windows. Unlike under 3.1 it compiles without issue. However, the attribute appears to actually do nothing it all. It behaves just like the attribute wasn’t there, just like a regular plain static variable.

I found this issue from attempting to use [ThreadStatic] within some code I had written for a future article here. The code was to profile various methods of implementing Thread-local storage on the Xbox 360. Switching the code to add a test case for [ThreadStatic] worked fine at first, but I was seeing very odd profile numbers coming back from it. On closer inspection in the debugger I could see that the TLS values weren’t thread-specific, they were getting written to at runtime by other executing threads.

Read more »

A few months back I was partway through an article about XNA. I was going to cover how to implement efficient “Thread Local Storage” on the Xbox 360. Back in Game Studio v3.1 I found that the [ThreadStatic] attribute was not supported on the Xbox, and the only workable methods out of the box were the Thread.GetData(), Thread.SetData() methods. Those methods aren’t good performance-wise, so I proceeded to look at more efficient alternatives.

That article was going to detail the solution I came up with, and currently used in my engine. However upon revisiting the work recently and upgrading to the new v4.0 XNA, I found that I had some compile errors. Specifically ‘System.Threading.LocalDataStoreSlot’ was now missing, it’s that slow method of TLS I was using to benchmark against. So I commented that code out. I then figured why not for the hell of it try to enable the [ThreadStatic] code, that I had #ifdef’d to the WINDOWS build. Lo and behold, it now compiled on Xbox 360!

Read more »

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.

Read more »

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.
Read more »

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.

Read more »

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.
Read more »

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.

Read more »