Gavin Pugh - A Videogame Programming Blog

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 »

Well, my posting on here has hit a bit of a lull. Overwork isn’t my excuse this time, since my last post things have been pretty crunch-free at my day job.

I think I’ve just chilled out a little more at home, not so much coding. Been actually playing games a lot more than usual; enjoying “Fallout: New Vegas” right now, and played a ton of “Dead Rising 2” as well. To hark back to an old blog post I made here about Dead Rising; I can confidently say that Blue Castle Games did a great job on it, you guys do indeed rock!

Recently I did just move my blog to a new domain. I felt the old website name “Music To Make Games By…”, and it’s really long domain name wasn’t to my liking. The original aim for my blog was to talk a lot about the Guitar Hero games I’m working on. That sort of thing is pretty difficult to do though. For obvious reasons I can’t talk about games that aren’t announced yet. Also, to talk about anything with any sort of meaty ‘behind the scenes’ content I’d need to run it by Neversoft first. So yeah, all that fell by the wayside and I mainly ended up covering my foray into XNA and C#; with a few distractions on the way.

Read more »

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.

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 »

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!

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 »