Smoothness

Posted by on Aug 10, 2010 in Dev, iPhone/iPad, Osmos | 5 Comments

Smoothness. If there was one aspect of Osmos that we were psychotically obsessed with during development, it was smoothness. Just like driving on freshly laid asphalt, skating on a rink just after the Zamboni has gone by, skiing through light untracked powder, gliding down a trail on a mountain bike with 10 inches of suspension, or gliding your Mote through the Blobiverse to gobble up an Ovarium, we knew that smooth travel brings joy to the human condition.

We strove for smoothness in our visual design; the slow pulsing glow in the motes, the hypnotic drifting particles inside your player that slowly tumble out into the Blobiverse, the growing and decaying starfield in the background, and gentle visual transitions between scenes. We were careful too with audio. There’s no game event that can cause the music to suddenly stop with a crash like a drunkard stumbling into the record player at a party. We chose an ambient soundtrack without a dominant beat, so that the player doesn’t unintentionally speed up the Mote in response to the music. And to keep the music a part of the background noise of the Blobiverse, rather than just a soundtrack playing along with the game, we had to change the speed of the music when the player changes the simulation speed of the Blobiverse.

Bringing this artistic vision to the iPhone was a tough technical challenge. The phone is powered by a tiny lithium-ion battery about half the size of my thumb, and to make good use of this minuscule power source, the computing and graphics power of the phone are kept low. If either the CPU (computing power for physics simulations, gameplay, sound, and user input) or the GPU (graphics power for drawing the scene) hit their limit, the animation starts to get choppy, like a pot-holed highway in New Jersey. And so began a long two-pronged process of code optimization.

Seeing other iPhone games that have complex worlds full of people, buildings, cars, and guns you may wonder why it would be difficult to animate our 2D retro-style arcade game. The performance secret for a 3D game is walls. The player can’t see through walls, so once a portion of the screen is taken up by a barrier, the computer can just ignore everything that exists behind it. In contrast, everything in Osmos is translucent, giving the soft, glowing, jellyfish atmosphere to the game, and so the computer has to draw everything within the player’s field of view every frame.

After a few months of work, we were starting to be satisfied with the game’s performance on the iPhone, when Apple announced the iPad. We knew this large touch-screen computer would be the perfect device for Osmos. Being lowly Canadians, we couldn’t get our hands on an actual iPad till many months after the U.S. release. In the meantime, we developed Osmos using Apple’s excellent simulator software, but we didn’t know how the performance of the iPad would compare to the iPhone until we could actually run the game on the device. The 2nd generation iPhone had been GPU limited, the 3rd generation had been CPU limited, but we hoped that the iPad wouldn’t be limited at all. But we knew we wouldn’t get a free ride once several developers noted that the GPU on the iPad was somewhat underpowered.

The area of the iPad screen is 8 times larger than that of the iPhone, while the number of pixels on the screen is just 5 times larger. I now need to take a brief aside to laugh at the marketing term HD. HD stands for high-definition, which most people would interpret to mean high-detail, fineness, or in computer terms, pixels per square inch. The iPad has only 5/8ths as many pixels per square inch as the 3G iPhone, which means that all those iPad games that distinguish themselves from the iPhone version with the name HD, are actually lower definition than the iPhone. The iPad has even lower definition when compared to the high resolution 4G iPhone, with the iPad having 1/5 the pixel density. Of course, pixel density isn’t everything, and the iPad is a joy simply because the screen is larger. And I will now guiltily confess that when you install Osmos for iPad, Hemisphere Games also shows the name of the game as Osmos HD. But mom, Billy was playing with the chainsaws first.

Marketing silliness aside, the fact remains that the iPad has to process 5x as many pixels as the iPhone. Our tests indicated that the iPad graphics card was only 3x as fast as the iPhone. So once again, we had to put on our thinking hats, and see what last corners of Osmos we could optimize. The Apple documentation let us know that overlapping transparency is hard on the graphics chip and encouraged us to create opaque, easy to draw worlds, but we really wanted to keep the soft glow of Osmos. Still, it was time to make some concessions for the mobile platform, so we turned on our debugging tools to see what graphical element in Osmos was causing the most overlap. In the following debugging screenshot, black areas of the screen contain nothing at all (easiest on the GPU) dark green areas have lots of overlap (tough on the GPU), and the light green areas have 1 or 2 overlapping elements, perfect for creating that soft glow.

Debug view of overlapping starsDebug view of overlapping stars.

Normal view of starfield.All that empty space was weighing down the GPU.

It was quickly apparent that our background star field was using up all the graphics power. In the PC version, the stars are created randomly at varying sizes to try and cover the background space of the Blobiverse. For the mobile versions we generated a grid and tried to distribute the stars evenly, while being careful that the visual effect didn’t look like a grid. The resulting stars look a bit flatter than the PC version, which had us disappointed for a while, until we regained some perspective and remembered that we were trying to run Osmos on a phone. The new stars made Osmos run twice as fast, which was a very exciting optimization.

Intelligent distribution causes far less overlap than random placement.Intelligent distribution causes far less overlap than random placement.

The new starfield looks remarkably similar to the old one and runs at twice the speed.The new starfield looks remarkably similar to the old one and runs at twice the speed.

Why did Apple, with the physical space and much larger battery reserves of the iPad, use an underpowered graphics chip? Well, the cynic in me suspects that they want you to buy another iPad when they release the next generation and describe the graphics card as being x-times faster. But given how important a successful launch of a tablet computer needed to be in an unproven market, I suspect the true answer reason is heat. A powerful graphics processor uses a lot power, generating a lot of heat, creating much discomfort in your lap.

In the end, we were very pleased with the buttery smoothness we could drag out of miniaturized low power devices. There’s still a few tiny hiccups and jerks that our OCD personalities would love to see disappear, but perhaps we’ll have to wait for the next generation of high technology to emerge from Apple.

5 Comments

  1. Pat
    August 10, 2010

    The mobile version really doesn’t look that bad. Side by side, you can notice a difference, but for the performance its not really that big. Amazing job!!

  2. Richard
    August 11, 2010

    Thanks for this. I’m just coming to grips with implementing some shaders for a 2D game on the iPad and, as they say, misery loves company. I guess the manufacturer’s philosophy relies pretty heavily on the deferred rendering architecture to stop overdraw in 3D scenes but it doesn’t help at all when you are using lots of alpha blending. I’ve played Osmos on iPad and it was indeed very smooth, even when I zoomed right in on my mote. From the picture above it looks like that is indeed one of the most fill rate demanding areas.

  3. Edmundito
    August 15, 2010

    Pretty cool behind the scenes post for us techies, thanks! I think the game looks great on my iPhone… it does capture the feel of Osmos quite right despite the changes on the little graphical details. And it’s by far one of the most polished game experiences I’ve seen on the phone.

    And now out of curiosity, I will bombard you with some questions. :) Did the game have to be completely rewritten from scratch for iOS when being ported from the PC? Was there a chance to save some of the core code or did you guys end up rewriting everything in Objective-C? If not, which portions were completely redone and which parts were you able to migrate?

  4. Dan Morelle
    August 16, 2010

    What an eloquent and entertainingly written piece that could easily been boring to a non-programmer. I like your game and will enjoy it more now as I’ll appreciate the attention to detail.
    Osmos feels organic, which is testament to your technical mastery. Bravo.

  5. Curmudge
    August 22, 2010

    We were able to reuse a lot of our PC code base. Objective-C lets you freely mix in C and C++ modules. Our physics engine was ported almost entirely untouched from the PC version. We used OpenGL as the base of our graphics and OpenAL for our sound engine, both of which are supported by the iPhone (though the iPhone only supports OpenGL ES, a light version that has a few missing functions and some shallower matrix stacks, and the OpenAL code isn’t hardware accelerated so we had to revisit some of our sound processing.)
    Most of the Objective-C code is in the places where the game is in closest contact with the the device; launching and initializing the game from disk, responding to touch events, pushing the final rendered scene to the screen, and device interrupts like phone calls and low memory warnings.
    It was a great help first porting the code base to OS-X from PC, as the iPhone API is very similar to the OS-X API. It also really got me familiar with the parts of code that would need to be changed for each platform.
    Most of the work was in designing for the small screen and optimizations. For the screen, we had to reduce a lot of the text and on-screen displays so it didn’t look cluttered. And Eddy did a heroic amount of work making sure the game still felt fun by tweaking all the levels for the 480×320 screen.
    For optimizations, it was a lot of inspection using the profiling tools and eking out a frame or two of performance improvement wherever we could. When we first had Osmos running on the device, it took 50 seconds to load and ran at a lurchy 10 frames per second. There was no magic run-faster switch, but a hundred minor optimizations earned us a smooth game in the end.