Blog

Introducing Asounding

While porting the game Tumiki Fighters to the iPhone, I had a hard time with audio. Making background music and sound effects work well together, work well with the iPod playing its music, and handling other things that may happen on the device isn’t a task as simple as it seems at first glance. Turns out I’ve made my own audio engine for this game, and today I make it available to help other iPhone developers who are struggling with audio issues. Introducing the Asounding Audio Engine for iPhone OS.

My first attempt at an easy solution was to use the AVAudioPlayer class to play the background music and SystemSounds to play the sounds effect. This was pretty simple, and worked to an extent. As soon as a couple of sounds started to play however, the background music noticeably gained in volume and got distorted until all sounds effects would stop. This solution proved unworkable.

My second attempt was to use the SoundEngine code from a now-retired Apple sample code. I won’t tell you were to find it because it’s buggy (no wonder Apple removed it), but it was a somewhat better temporary solution than SystemSounds simply because it worked correctly (most of the time) and thus I could concentrate on other things than audio. Once the game was in a better shape, and after collecting a couple of crash logs, I decided that debugging a race-condition in SoundEngine wasn’t something I wanted to try, and decided to move to something else.

At this point, I had already decided to build my own sound engine for managing all things audio in the game. I started from the oalTouch sample code, then grew it to accomodate all my needs. With Asounding you can:

• Play multiple sounds at a time
• Switch background music in mid-game with little or no hiccup
• Fade background music

Then I added some automatic behaviours to:

• Disable background music when the iPod is playing
• Disable audio when the applications gets interrupted, re-enabling it afterwards

In addition, you can choose to disable iPod playback, and you can manually disable background music, sound effects, or all audio from the program (useful to enforce user preferences).

Special care was given to what happens when the user starts iPod playback while the application is running by double-clicking the Home button.

Asounding is now available to everyone as open-source (GPL) and for commercial licensing in closed-source applications. If you are an iPhone game developer, please give it a try and look at how much implementation and debugging time it will save you.

You can see Asounding at work in the game Tumiki Fighters (App Store link).

Porting a game to the iPhone

Soon, a port of Tumiki Fighters, a game from Kenta Cho originally for Windows, will on the App Store. It’s a horizontal scrolling shoot’em-up game where you destroy enemy ships made of small colorful blocks with your own craft made of the same. Why do I talk about it? I made the port. (Update: now on the App Store.)

I was contacted in May by someone called Jeremy who wanted to take Tumiki Fighters to the iPhone and sell it on the App Store. He though I was the right guy for this since I’ve been working a lot with D (the game is written in the D programming language) and Mac OS X a lot. There was also things for which I was not very familiar with but which I was pretty interested in learning (or at least experimenting with), such as:

• Game development
• iPhone development
• OpenGL

For me, this was a very interesting project because I had never worked on a game before (not counting those small old games attempts on a 486 a long time ago), nor did I used OpenGL.

The first problem was getting it compile to the iPhone: there’s no working ARM port of the D compiler and runtime at the moment, and while I could have helped bringing that to life, I decided I already had enough unknowns in the projects and that it’d be safer simply porting the whole game to C++, which turned out to be not so hard (the biggest difficulty was tracking object ownerships to work around the absence of the garbage collector in D).

Then, after converting the game from D to C++, I had to port the thing to the iPhone platform. Tumiki Fighters relied on SLD for accessing the screen and controls (keyboard, joystick), SDL_mixer for sound output, and OpenGL for graphics. The iPhone only has the stripped-down version of OpenGL called OpenGL ES. OpenGL ES works only with triangle coordinates (had to convert a lot of “quad”-based shapes to triangles) and does not support precompiled shapes (known as display lists). So I had to reimplement the graphics within these constrains.

Ditching SDL wasn’t so hard: I based the OpenGL context on the EAGLView sample code, and since I had to redo the inputs anyway (using the accelerometer and screen buttons) it was easier to completely replace SDL for that.

As for sounds, after various attempts at getting everything right, I finally settled at creating my own audio engine around OpenAL (for sound effects) and AVAudioPlayer (for the music). It turns out that working with audio is one of those really nasty parts of making an iPhone game: you need to be careful about the iPod’s background music (which the user can start at any time by double-clocking the home button), and AVAudioPlayer has the nasty habit of blocking the calling thread for half a second when you want to start a new music. So I’ve built my own audio engine to “fix” all this (and a little more), and I’ll make it available to other developers in a short while.

I’m pretty satisfied with the final result — my client, Jeremy, seems overjoyed to see it finally happen! I hope you’ll like it too; Tumiki Fighters will soon now be on the App Store if you want to give it a try.

Oh, and bravo to Grzegorz Adam Hankiewicz for correctly guessing the game based on the icon alone in my last post. That was quick.

Mystery App

Surprise! For the majority of you who don’t know, I’ve been working on porting a game to the iPhone OS platform. It’s been an interesting experience: dealing with Apple’s cryptographic certificates, play with the accelerometer, converting OpenGL code to OpenGL ES, and the difficulty of handling sounds and music properly on the ubiquitous music plaform that is the iPod. (I’ll have more to say on audio in a later post.) Now, while my client and me are waiting for the app to get approved by Apple, anyone wants to take a guess on what is the game based on the application icon?

Hungarian Notation, the Original

If you’ve been programming on Windows for some time, you’ll know about Hungarian Notation. It’s a convention where you write a few characters in front of every variable name telling you what’s the type of the variable. For instance, the name of a variable of type int would be prefixed with “i”, a pointer with “p”, a pointer to an integer “pi”, etc. Today, this practice is highly frowned upon, even at Microsoft, because it’s mostly useless and error prone. I’ve been surprised however to learn that this is only a bad slip from the original purpose of the Hungarian Notation as it was first invented.

Here’s a nice excerpt from Making Wrong Code Look Wrong (Joel on Software):

Apps Hungarian was extremely valuable, especially in the days of C programming where the compiler didn’t provide a very useful type system.

But then something kind of wrong happened.

The dark side took over Hungarian Notation.

Nobody seems to know why or how, but it appears that the documentation writers on the Windows team inadvertently invented what came to be known as Systems Hungarian

Somebody, somewhere, read Simonyi’s paper, where he used the word “type,” and thought he meant type, like class, like in a type system, like the type checking that the compiler does. He did not. He explained very carefully exactly what he meant by the word “type,” but it didn’t help. The damage was done.

Apps Hungarian had very useful, meaningful prefixes like “ix” to mean an index into an array, “c” to mean a count, “d” to mean the difference between two numbers (for example “dx” meant “width”), and so forth.

Systems Hungarian had far less useful prefixes like “l” for long and “ul” for “unsigned long” and “dw” for double word, which is, actually, uh, an unsigned long. In Systems Hungarian, the only thing that the prefix told you was the actual data type of the variable.

So basically, App Hungarian is useful for differentiating data that the compiler let you mix because they are of the same type but that you shouldn’t mix. Just like keeping your units with you when you write a formula makes mistakes more obvious.

It’s not just for math though.

PHP Markdown use a similar approach

While I’m not sure using a suffix can be said to be Hungarian Notation, inside PHP Markdown many string variables get one: the _re prefix on a variable denotes a whole or partial regular expression. This helps make sure that no character pass unescaped through the regular expresion parser.

The net result is that it’s easy to spot errors. For instance if I see this in PHP Markdown, I know there is a problem with the $token variable which gets embedded in a regular expression while not being converted to one (notice the abscence of a _re suffix):

preg_match('/^(.*?[^`])' . $token . '(?!`)(.*)$/sm', $str, $matches);

In this case, the solution is to call preg_quote on the token in order to make it safe to pass to the regular expression parser.

It’s interesting to note that with languages that allow you to define your own types and overload operators — such as C++, C# and D — you could define your own types and make the compiler flag any mismatch for you. The required effort for defining new types (and all their interactions) instead of using a simple naming convention may not always be worth it however.