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.
Continue reading →

LIke the scaffolding around an under-construction building, it’s important to have the right structures in place to aid your work even though you won’t need them once the job is done. In the case of games, this takes the form of the various bits of functionality used to debug games as they’re being built.

In the hope that they prove useful to other XNA developers, I’d like to introduce a couple of GameComponents that I use to provide debug functionality for my games: LineBatchComponent and ScreenLogComponent.
Continue reading →

Last week, I put effort into making modern, full-color rendering look like an old TV. This time around, we’ll go even further into the past and make the screen resemble an old, faded photo. To produce this effect, I use a pixel shader to apply a sepia tone to the image as well produce a vignette effect by darkening the edges of the image.
Continue reading →

Modern pixel shaders have given game developers tremendous capabilities with which to improve the visuals of their games. They’ve also given developers the ability to make their games look WORSE. That’s okay though, when it’s on purpose.

For this week’s post, I’ve put together a pixel shader that takes a normal full-color game and renders it like a black-and-white screen with lots of static. Continue reading →

When it comes to handling physics in 2D games, few libraries come with the pedigree of Box2D. For implementing piles of rigid bodies behaving realistically in collisions, it is an ideal tool. On the other hand, when implementing character movement in a platforming game like Super Mario Bros, it can take quite a bit of tweaking to get the behavior to feel right.

That being said, it is certainly possible to setup Box2D bodies in such a way to create a high-quality platforming experience. Here’s a description of the setup that’s been working for me so far.
Continue reading →

It’s certainly possible to have too much of a good thing. In this generation of HD TVs and game consoles, that too much of a good thing can be pixels. If you take some of the great pixel art of old and display it 1:1 on a modern screen, the art ends of being tiny. In order to fully appreciate the pixel art, you need to scale it up.

There are many ways to accomplish this sort of upscaling and, while they may have the same end result, they are not always the same in terms of performance. With that in mind, I decided to write some code and try out some of those methods for myself and see how their relative performance compares.
Continue reading →

When trying to optimize your sprite engine and reduce the time needed to draw a frame, optimizing texture size and texture batching are all well and good but they won’t do much good if you’re simply trying to draw too many sprites at once. In order to maximize performance, it’s important to be able to quickly determine which sets of game objects actually need to be updated or drawn on any given frame. With a large, heavily-populated game world, only submitting to the GPU objects that will actually be on the screen can reap enormous performance gains.

One of the most common methods to determine which objects occupy a particular area of the game world is to implement a spatial index. There are many different algorithms that can be used to implement a spatial index, but in this post I’ll cover one of the simplest: a Grid index.
Continue reading →

Here’s an interesting tidbit I ran across in an App Hub thread about xna spritebatch performance: scaling down sprites can cost performance. A lot of it. While drawing a large texture scaled down will probably be faster than drawing that large texture at its full size, the difference between drawing a large texture scaled down versus drawing a smaller texture at its native scale can be surprisingly large. One of the examples in the thread showed that the framerate tripled when switching from drawing 256×256 textures at 0.125 scale versus drawing 32×32 textures at 1.0 scale.

With a performance difference that big I just had to see it for myself, so I decided to whip up a little experiment to try it out. Continue reading →

Last week, I talked about measuring performance. Now, I can tell you why.

Before doing any sort of performance optimization, it’s important to have an accurate benchmark so you can make sure your optimization actually works. Now that I have my measurement system ready, I can talk about optimizing performance. The optimization for this week is speeding up sprite batch rendering by packing your images into one texture.

App Hub has a good sample illustrating how you can import multiple images into the XNA content pipeline and pack them into a single texture at build-time. I decided to take a slightly different approach by writing code that would pack multiple Texture2Ds together at runtime. Continue reading →