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
Donald Knuth said it best:
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
Every programmer knows this in their head, but getting that through to their heart can be surprisingly difficult. When it comes to applying lessons like the one above, it’s easy to find yourself in the middle of a conflict between doing what you know you should do and doing what you want to do. Continue reading
Any technically-inclined person on the net should be familiar with the acronym RTFM which stands for the phrase “Read the Freaking Manual” (the non-family-friendly version is more colorful, of course). It’s the standard response to a question that you think wouldn’t have been asked had the asker read the (freaking) manual in the first place.
For the programming set, a natural variant for RTFM is RTFC, “Read the Freaking Code”. For any given program, the source code is, by definition, the most accurate description of how a given program will behave. Barring inaccurate comments and misleading variable names, source code is the only form of documentation guaranteed to be 100% accurate. What keeps source code from being great documentation is that it is so hard to read. It’s so hard in fact that:
Most Programmers Can’t Read Code
Programmers can’t read code? But isn’t that their job? Strange as it may seem, it’s true and there are reasons for this. Read on to learn more. 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.
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.
This week on Game Dev Without a Cause, we’re going deep. Deep copy that is! Okay, you really have to be a programmer to find that all appealing.
You may not need to do it often, but when you do it’s really useful to have an easy deep copying solution on hand. As simple as it is conceptually, it can be surprisingly difficulty to find a general-purpose way to perform deep-copies on arbitrary collections of data. It can be especially difficult with XNA because the Xbox 360 doesn’t have the full set of features available to the Windows version of the framework. Sure, it’s easy enough to write deep copy logic for simple structures, but who wants to be stuck updating Clone() functions or the like every time they add a member to a particular class.