A lot of my work I’m doing on Masteroid right now is not sexy. I’ve worked a bunch on tools over the last week and, as I wrap that up, my attention is turning to performance.

I see some developers having complex discussions on the fastest way to loop through an array and other highly-academic topics. But, in my practical experience after years of gamedev, I see these as the primary performance bottlenecks where light optimization can yield huge results:

  1. Collision, number and complexity of tests
  2. Object instantiation/destruction
  3. Render breaks

In this post, we’re primarily talking about render breaks. First of all, render break is not used much as a term outside of the FlatRedBall (FRB from now on) game engine community. But the concept applies to any engine. A render break is when the GPU has to stop what it’s doing and switch states before it can continue rendering. Render breaks most often occur when the GPU has to switch textures or blend states.

For example, if you have a platforming level with a blue sky background, a cloud, a brick platform and a character, the GPU will render the scene something like this:

  1. Load the blue sky texture
  2. Render the blue sky background
  3. Unload the sky texture
  4. Load the cloud texture
  5. Render clouds
  6. Unload the cloud texture
  7. Load the brick texture
  8. Render platforms
  9. Unload the brick texture
  10. Load the character texture
  11. Render the character
  12. Unload the character texture

The text in red above highlights unnecessary render breaks. The GPU had to stop drawing pixels to the canvas and swap textures. This is relatively slow. In the example above, if clouds can exist both in front and behind the platforms, you could have MANY more render breaks to swap back and forth.

Since the dawn of videogames, gamedevs have dealt with this by “spritesheeting” or “texture packing” their sprites – essentially packing multiple sprites into a single texture and defining bounds for each sprite. With spritesheeting, the GPU no longer has to swap textures. It is now drawing a small part of the texture in memory to the screen.

As both the developer and the artist on most of my projects, I draw all of my sprites on a single sheet from the beginning of the project. I either use texture coordinates or animation chains in FRB to define the individual sprites in the spritesheet.

Fonts are where this falls down. I use Angelcode’s popular Bmfont tool to create bitmapped fonts. This tool generates a fnt file that describes each character. It also generates a png. FlatRedBall makes it super easy to use bitmap font tools natively in the engine itself, in Glue (FRB’s project layout tool), and in Gum (cross-platform UI tool).

The problem with this is that the png files for those fonts are a separate texture. UI has a lot of layers with button and panel backgrounds, fonts, icons, etc. Those layers result in huge numbers of render breaks as the GPU swaps between font textures.

One quick and easy hack for this is to simply drop the png into the top left corner of your spritesheet! The fnt file specifies character coordinates from the top left so as long as the font is the first thing in your spritesheet you’ll be good to go. Then you can edit the png filename in the fnt file to point at your spritesheet and font rendering will not require a texture swap.

But what if you need more than one font in your game? That’s where things get tricky. If you want a font that is not top-left-aligned you’ll have to edit the X and Y value for every character in the fnt file to adjust for the offset (see example above). I knew this would work conceptually but I had never actually tried it because, as far as I know, no tooling exists to help edit all of those offsets.

So I made one.

It turns out that actually loading a fnt file into a runtime object is a pain in the butt. But, if you look at the file above, all we really need to do is add to the x or y value of every line based on our offset.

I already had a little console app that does things like pack game data into a .dat file. I added a crude menu with some prompts that allow you to add x and y offsets to all of the values in a font file using Regex. Then I copy/pasted the png files (very precisely, this is important!) into photoshop, measured the offsets and updated the fnt files.

I can’t publish my whole tool because it does a bunch of game and context-specific stuff that would probably just be confusing. The meat of the whole thing is this crude, but effective, regex:

I haven’t done an exact count but this will likely remove 30+ render breaks from my sector screens when the station menu is up and maybe as many as 8 when it’s not.

Commit 498c5a3.

Categories: GameDevMasteroid

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts


SpaceGameJunkie Gameplay Lessons

I’m super thrilled that SpaceGameJunkie (SGJ hereafter) featured Masteroid on their blog, including a 20 minute gameplay video! I have done tons of personal playtesting as well as letting my friends and kids play the Read more…


Masteroid v0.2.0 Release Notes

This is the first release in what I’m calling the “Factions” build. This release focuses on increasing the depth and gameplay opportunities with factions in Masteroid. The player can now receive missions from factions once Read more…


v0.2.0 Mission Implementation

This weekend was an important one for game progress. Since the last release I’ve been working hard on this idea of a “missions” system that will give players more to do, and more purpose, in Read more…