As cutesy as it may be, I’m growing rather fond of my garbage collection count display. I’m especially fond of it because it helped me find garbage collections occuring in places I never expected them to happen. Such as my title screen for example:
Ack! Look at all those garbage cans, I mean recycling bins (reduce, reuse, recycle, folks!)
That’s a lot of garbage collections for a “static” title screen. Now, how to find out what’s causing all that garbage to be created… That’s where Microsoft’s CLRProfiler comes into play. Continue reading
I’ve lamented before about how unfortunate it was that my frametime display allocated memory and would cause garbage collections to occur. Well, I found a simple solution for my memory allocation problem and, if I say so myself, it’s kind of… cute. Continue reading
In a previous post, I talked about how I added basic memory usage output to my frametime debug display. I also mentioned the major problem with that system being that the debug output I used allocated memory, causing garbage collections to occur. This constant change in memory usage naturally made the output hard to read. As I was writing that post, I had an idea for how I could easily solve that problem which I will share with you now. Continue reading
As I mentioned in a previous post, the number of milliseconds needed to render a frame is THE metric for measuring your game’s performance. Since then, I’ve tweaked the code I introduced in that article to further help me detect performance problems. Continue reading
While it’s the big problems in game programming that get all the press, there are plenty of small problems that show up day-to-day. Most of these problems can be solved by an equally small bit of code, it’s just a matter of figuring out what that code should be.
With that in mind, I’d like to share a few bits of utility code that I find invaluable in my daily game making. Continue reading
No bones about it. Video games have a LOT of text in them. From character names to item descriptions to names for screen-clearing special attacks, there is a lot of text that, at some point or another, has to be rendered to the screen.
With XNA, rendering text to screen is a no-brainer. The SpriteFont implementation makes rendering strings to the screen with a variety of fonts trivially easy. There is one problem though: rendering SpriteFonts with DrawText() can be really slow.
TDD (Test-Driven Development) can be great. It encourages you to address edge cases earlier when you have a better grasp of the code you just implemented. It forces you to de-couple classes in ways that allow you to later combine and re-use them in ways that might not have been possible had you developed them using other methodologies.
TDD can also be a big pain-in-the-ass. Isolating logic for testing can be difficult, especially when you need to rely on code that requires complicated external resources: legacy codebases and hardware being the prime examples. The XNA Framework code, with its substantial functionality abstracting the details of hardware on Windows, the Xbox 360, and Windows Phones, falls squarely into both of those categories.
So, does this mean that it’s impossible to use TDD when working with XNA? Hardly. It can be tough, but there are ways to make it easier. In this post, I’ll talk about how I’ve managed to work with XNA while still giving my code the TDD-loving it deserves / needs.
TDD (Test-Driven Development) can be a hard-sell in many work environments. I said as-much in a previous post. The main problem lies in figuring out how to calculate the concrete time costs of TDD versus the abstract (but real) benefits.
While it’s easy to track the costs of TDD with a timesheet recording the amount of time spent writing tests versus production code, measuring the benefits in a measurable way takes a bit more creativity. My approach to measuring the benefits of TDD in my own code is to keep a journal of moments of when I think I have reaped benefits due to TDD. This is, of course, a very anecdotal approach to measuring the benefits, but it does provide a basis for tracking effects of TDD that would normally go unmeasured.
In a previous post, I mentioned the solution I use for performing deep copies in XNA. Recently, while fixing a bug in a recent project, I made a minor tweak to the deep copy function that made a major difference to its behavior.
Okay folks, it’s summer and it’s the perfect time to hit the pool! This being a game development blog, you can probably guess that I’m not talking about the filled-with-water kind of pool, but rather memory pools. Oh yeah, programmer puns. They’re the best, right?
All joking aside, pools of preallocated objects are a basic but very useful structure for controlling memory allocation in games. The basic idea is that, instead of allocating (“new-ing”) an instance of an object just before you use it, you preallocate a set number of objects ahead of time and store them in a list (pool). Later, when you actually need to use an instance of the object, you grab an unused instance off the list and initialize it with the relevant data.