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.

Game Jam Framework

Over the past year or so I’ve done several game jams and really enjoyed it; I’ve based each of the games on a simple set of C++ library code I’ve been working on. I’ve kept intending to switch to Unity, but it never ends up happening; truth be told, although I can get a lot more done with Unity, I just have a lot more fun working in plain C++ with my own systems, and each accomplishment just feels so much more earned when I’ve done it more or less from scratch.

To that end, I’ve been working a bit on improving the framework code (‘engine’ is far too generous a word) that I’ve been using for the jams and for other hobby projects, including the GPU Game of Life and Pacman parody projects I’ve posted here, as well as all of my Ludum Dare and Indie Speedrun entries so far.

I’ll post about my progress here occasionally as I work on it. It’s not likely to be hugely interesting–more just a chance to get some thoughts down as I’m working on it. This first post is a summary of what I’ve got so far. Be ye fairly warned: much boring nerdery lies ahead–

My guiding principle in working on this has been to make it as simple and pleasurable as possible for me to write small-to-medium-sized projects; much of what I’ve done has been focused on that goal. There are a lot of things I’ve done that are tremendously inefficient. Some of them I intend to optimize, but others I’ll likely leave as-is for maximum flexibility. After all, the projects I’m creating with this aren’t going to be tremendously complex. Performance is a minimal concern, while ease of development is crucial.

A few of the more notable features:

  • A resource loader front end inspired by XNA’s that’s designed to make it as easy as possible to load resources. The implementation is internally clunky, but the interface makes loading resources into a handle (including reference counting, avoiding duplicate loads, support for resource load parameters like shader macros, etc.) as simple as this:
    auto example_tex = resource::load<texture*>( "textures/example.dds", optional_parameter_blob );
  • Basic 3D support, including a model loader built on top of the Open Asset Import Library, and a basic forward renderer with ambient, point, and directional lights (currently using Mikkelsen’s Torrance-Sparrow implementation).
  • A fast sprite renderer, using texture arrays and structured buffer instancing to blast potentially thousands of sprites onto a frame at high framerates. It’s in the early stages and is missing a lot of functionality, but it’s already really fast. (I know I mentioned I don’t care much about performance, but this is a situation where I thought being able to draw truly extreme numbers of sprites at once could be interesting for a jam. Plus, it was just fun to write.)
  • A basic input wrapper to make reading single keystrokes, held buttons, and mouse movement easy.
  • Simple FMOD wrapper (sound playback, streaming music).
  • A math library wrapping DirectXMath (the XM* functions) in easy-to-use classes (with operating overloading where natural).

A lof of the above still needs some work, and there are some major features on the todo list:

  • Gamepad support using XInput.
  • An input mapping system to map raw keyboard/mouse/gamepad input to in-game actions more naturally.
  • A tiled deferred renderer (ported from another hobby project I did in 2012).
  • Eventually, hopefully integration with Box2D for 2D physics and PhysX for 3D physics.
  • Screen space effect chain (at least HDR/tonemapping/bloom, motion blur, depth-of-field, color grading).
  • Some kind of basic animation support–at least rigid-body animation to start.

My mercurial repository for the engine code is public: http://bitbucket.org/otresnjak/eph-engine. I’ll continue to update it as I add new features. It’s missing the front-end code you need to actually compile/run; I’ll make that repo public as well once it’s a little prettier.


Week 9: GPU Game of Life


For my ninth weekly project, I’ve created…life!

Although it was originally computed by hand, Conway’s Game of Life has been implemented as software so many times over the past 44 years by so many people that I’m not sure doing my own version even counts as a creative project, but somehow throughout my decades of computer programming I’ve never built one, so I’m doing it anyway.

This particular version is implemented almost entirely on the GPU–the CPU provides the initial state and can turn more cells on to keep the game going, but otherwise all computation is done in a compute shader. (Compute shaders are kind of brilliant for this, as the Game of Life is practically the definition of an embarassingly parallel problem.)

I render live cells in red, and have dead cells fade gradually in green instead of disappearing. This makes it easier to see structures forming and vanishing. The initial condition is just created by randomly drawing pixels all over the buffer, and you can add more at any time by holding down the Enter key.

One thing I found particularly interesting is how many gliders tend to emerge from these completely random starting conditions! With the green trails behind them, they’re very visible. You also get a lot of small, stable structures as well as simple oscillators. (Phase-2 oscillators are almost impossible to see in this simulation, unfortunately, because it moves so fast it makes them look stable.)

Click here to download the program (update: added some DLLs it was missing). It’s a Win32 executable and requires a D3D11-compatible video card (anything even remotely recent should work). There’s some on-screen help-text that explains some other controls you can use.