Quick Tip – disabling optimization without getting yourself in trouble

If you’ve worked on a nontrivial game in C++, you’ve probably run into a situation where you’d like to step through some code in the debugger, but the debug build of your game is painfully slow and debugging in release mode is difficult and time-consuming.

Here’s something you probably know (but if you don’t, it will change your life): you can disable optimization selectively per file, and thus have access to good debug information while not crippling your performance by running in debug mode.

In the Microsoft compiler, you do it this way:

#pragma optimize("", off)

This will turn off all optimization in whatever source file you put it in. (The optimize pragma has some options to make the changes more granular, but I’ve never really had a need for that.)

There is, however, a subtle problem here: it is very easy to forget to remove that one innocuous line after adding it–and end up, in the worst case, shipping your game with optimization turned off for some files.1 It would be nice if the compiler would let us know if we forgot to remove this pragma, right?

What I do is create a no_opt.h header and include it in any files I’d like to be able to step through:

#pragma once

#pragma message("no_opt.h included in " __FILE__)

#error no_opt.h included in release final build; remove.
#pragma optimize("", off)

Replace _RELEASE_FINAL with whatever your “final” build configuration you release to end users–i.e. the configuration that’s build by your build system.2

With that, the compiler will spit out a message for every file that has optimizations disabled. Further, if you don’t notice the message, it will fail to compile on your final build, giving you a second chance to remove the header.

(I’ve only really done this in Microsoft’s compiler personally, but clang and gcc appear to have similar pragmas available, so it should be easy to extend this to them.)

1. If you’re thinking to yourself that you’re not that forgetful and have always remembered to remove it, I’m sorry to report that you’ve almost definitely shipped code with optimizations disabled.
2. This practice may sound strange if you’re not familiar with it, but at least in game development it’s not unusual to have a “release” build and a “final release” build, where the former will enable optimizations and the latter might go further by turning off developer tools, removing symbols, etc.

bytopia (working title)

For the last few months I’ve been working on a voxel-based construction/exploration game in my spare time. Figured it’s a good time to share some of my progress.

A quick video demo here.

It’s all fairly minimalist so far, but the major features:

  • First pass on procedural world generation.
  • Large worlds (currently +/- about 2 million blocks in any direction, including up/down).
  • Day/night cycle with sun and moon, as well as a rudimentary atmospheric scattering approximation.
  • Normal mapping combining surface normals with a bevel effect on blocks to give everything a nice blocky look.
  • Rudimentary UI, including inventory, main menu, HUD, and a debug console.
  • Fairly polished movement controls and physics for the player (this is a big priority for me–games like this often have awkward-feeling movement and I want to avoid that).

A few technical details:

  • Handwritten in modern C++.
  • Renderer based on OpenGL 4.5.
  • Physics (just for cosmetic effect for dropped items etc) using PhysX.
  • Font rendering/layout using freetype2 and harfbuzz.
  • Windows-only so far, but built with ease of porting in mind.