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.
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
If you’re making games, it’s pretty much a requirement that you know your frames-per-second at any given moment during development. Even more valuable than your FPS is knowing how much time it takes you to draw a frame. This article by Robert Dunlop does a wonderful job of explaining why you should prefer frametime over FPS as a performance metric.
So, now that you’re convinced that you want to know your frametime, let me show you how to calculate it and put it up on the screen. Continue reading