Mezzanine Stairs

I’ve been stuck on one of the last areas of improvement necessary to bring our browser game to the big screen: frame rate. Pictured above is a comparison of the smooth camera panning we’ve managed to accomplish vs. the original game’s rather choppy presentation.

History

The browser-based versions of World’s End ran at an awkward 28 frames per second (fps). When we started development, asking much more than 24 fps of the Flash plugin was unreasonable. Additionally, Flash consistently ran slower than the target frame rate on Macintosh computers at the time, and to get 24 fps I was in the habit of adding a couple frames per second to force them to reach the desired rate and just let Windows users run slightly fast. In response to complaints about enemy turns taking too long, at some point we added another two fps just to speed up the game in general (along with fast movement), and landed at 28.

We’ve long had a “turbo” mode for testing purposes where the game basically runs at double speed (rushing through cutscenes and enemy turns). Since this was working well for so long, I didn’t expect much trouble achieving 60 frames per second especially now that we’re using hardware accelerated graphics. The new game engine runs fairly smoothly at 60 fps on my computer, but until recently not on Complacent’s. For the past two months I’ve been making incremental optimizations, and wondering if I’ve made a fundamental miscalculation about what it will take to run full-screen and full-frame rate.

Tech

The challenge at hand was to decouple the game’s internal frame rate from an overall faster native frame rate to allow the camera to pan and zoom smoothly without simply speeding everything up. I’d already remade the animation engine, as previously described, so I had manual control of most animations and could simply have them advance more slowly than the rest of the game. There were, however, many more animations left being drawn by Flash natively that I had to take into account and manually control, such as those in menus. Now, my code is aware of all such animations and manually pauses and unpauses them to play properly based on the new frame rate.

Optimization

Above is a screenshot from Adobe Scout, the Flash content profiler, which has been invaluably helpful in finding potential areas of performance improvement. The window on the left is showing a couple seconds worth of the first cutscene. The red line represents 16.6 milliseconds, or the amount of time we have to draw each frame at 60 fps. The blue shows how long code is running, some mine and mostly the Starling framework. Green is CPU-based rendering such as menus with the first dialogue box on the left and the second on the right. The first dialogue box in the game appears in segments, with the “SKIP” button animating on to the screen to grab attention. The shorter, every-other-frame green bars show this animation happening at half the overall frame rate, and the second dialogue box appears all at once on the right.

By shaving off milliseconds and microseconds wherever I could find room for optimization, I was able to bring the frame rate on Complacent’s machine from the mid 40’s to the mid 50’s, only sometimes reaching the elusive 60. We finally figured out that the culprit was his CPU, which was dynamically underclocking itself for power-saving purposes (despite not being a laptop) and for whatever reason simply not giving the game enough processing power to run full-speed. Disabling this feature fixed the problem entirely, but that doesn’t mean I won’t need to deal with the situation where full frame rate can’t be reached. I’ll either monitor the frame rate over time and automatically switch to 30 fps, or find a way to skip frames to keep animations from lagging, but for now I need to move on.

Ultimately, I wound up doing more optimization than absolutely necessary, but there will certainly be some marginally capable hardware out there that will benefit from it. Seeing performance gradually improve was satisfying, but the idea that something was fundamentally wrong was nerve-racking. Oddly, and somewhat reassuringly, the Android version ran well on both of our mediocre phones before any of this latest optimization.

All The Things

In other news, I’m renaming the previous post “All The Pixels” as I’d originally planned because the Adobe AIR engineers at Harman have removed the GPU memory limit, and once we pay them for the latest SDK we will, in theory, be 8K forward-compatible. Testing such a hypothesis is well beyond our reach at the moment, but it’s good to dream.

Up next: “All The Screens”