The YouTube player breaks Sound Shaker because the app recieves an audio interruption event (kAudioSessionBeginInterruption) when the YouTube player opens, but never receives a corresponding event (kAudioSessionEndInterruption) when the player closes. Being a good citizen, the app deactivates it’s audio session (and suspends it’s OpenAL context) when the interruption begins, but the poor little guy never gets a chance to reactivate it again. Not cool.

The YouTube player breaks Field Flier because it creates a new key window when it opens and sets the key window to nil when it closes. When Field Flier goes looking for the key window, it’s nowhere to be found. Oh sure, the app could listen for a UIWindowDidResignKeyNotification notification to reset the key window – too bad the YouTube player doesn’t trigger that particular notification. I’m pretty sure the YouTube player has it’s thumbs in it’s ears going na nana nana na at this point. Again, not cool.

The hacktastic solution to both issues is to listen for a UIWindowDidBecomeVisibleNotification notification on the app’s main window and manually call the interruption listener callback and reset the key window. I put the relevant code in the app delegate, but if your app shows and hides the main window for some other reason, you’ll probably need to get a bit fancier.

Here’s the relevant code in TickleTapToddlerPackAppDelegate.m:

void interruptionListenerCallback (void *inUserData, UInt32 interruptionState ) {
  if(interruptionState == kAudioSessionBeginInterruption) {
    AudioSessionSetActive(NO);
    // suspend OpenAL context here...
  } else if(interruptionState == kAudioSessionEndInterruption) {
    UInt32 category = kAudioSessionCategory_MediaPlayback;
    AudioSessionSetProperty(kAudioSessionProperty_AudioCategory, sizeof(category), &category);
    AudioSessionSetActive(YES);
    // resume OpenAL context here...
  }
}

- (void) applicationDidFinishLaunching: (UIApplication*) application {
  // initialize the audio session and register the interruption listener callback
  AudioSessionInitialize(NULL, NULL, interruptionListenerCallback, self);
  UInt32 category = kAudioSessionCategory_MediaPlayback;
  AudioSessionSetProperty(kAudioSessionProperty_AudioCategory, sizeof(category), &category);
}

- (void)didReceiveWindowDidBecomeVisibleNotification:(NSNotification *)notification {
  // manually call the interruption listener callback
  interruptionListenerCallback((void *)self, kAudioSessionEndInterruption);
  // manually set the key window
  [self.window makeKeyWindow];
}

Since my son Owen was born a year and a half ago, only a handful of great books and tv shows plus a CD or two have become things we love and come back to again and again. So, without further ado, a few of my (and Owen’s) favourite preschool things.

TV Shows

Sid The Science Kid

What I love about this show: The characters have lots of depth and the voice actors do a great job of bringing them to life. The humour and attention to detail make it genuinely enjoyable to watch, the science is fun and accessible and finds the fine line between educational content and something kids would actually choose to watch.

Where to find it:The show airs on TVO (in Ontario) and on PBS Kids in the US. It’s also available on DVD from Amazon.

Word World

What I love about this show: The character designs are brilliant – seriously, how do they make everything out of letters?! Learning about words and reading is worked into the plot in a really, really clever way – in my favourite episode, everyone’s afraid of a Shark, except Duck, because he mis-pronounces it as Sa-Hark.

Where to find it: The show airs on TVO (in Ontario) and on PBS Kids in the US. It’s also available on DVD from Amazon.

Pocoyo

What I love about this show: The simple character designs and plain white backdrop let you focus on the wonderfully detailed movement and sound – every nod, jump and step has a sound that helps tell the story – which is great for kids who haven’t got words yet. Also, I wish Stephen Fry (the show’s narrator) would read me bedtime stories and this is as close as I’ll ever get.

Where to find it: Pocoyo airs on Treehouse (in Canada) and is available on DVD from Amazon.

Kids’ CBC Friends

What I love about this show: It’s Canadian content that isn’t lame! Mama Yamma’s kitchen in Kensington Market feels a bit like the best parts of Sesame Street, the characters are well-written and funny (my personal favourite is the Breakfast Froog’s non-sequitur ribbit) and the hosts aren’t over the top. The Youtube video above really doesn’t do the show justice – Kids’ CBC, get with the times and make your content easy to find, embed and link to!

Where to find it: Kids’ CBC Friends isn’t a show, per-se, but short segments that get played between shows (instead of commercials). Kids’ CBC Friends airs on CBC in Canada (there’s more info on the Kids’ CBC website).

Music

The only music that’s become a staple in our house is Sing-A-Longs & Lullabies for the Film Curious George by Jack Johnson. The album has a good mix of accoustic songs and fun bluesy stuff (like the adaptation of Three Is A Magic Number about the three R’s). The lyrics are geared towards kids without being eye-gougingly repetitive, so listening on repeat is no problem.

Books

The Amazing Machines Truckload of Fun
by Tony Mitton and Ant Parker

What I love about these books: The words-to-pictures ratio is just about perfect – one or two short sentences per page – which means you can read everything before flipping the page! The text on each page reads like a poem and is fun to read just for the rhythm and the way it rolls off your tongue. If I had to pick just one, I’d have to go with Dazzling Diggers.

Haiku Baby
by Betsy E. Snyder

What I love about this book: The beautiful illustrations and pretty little poems are fun to read over and over. Hands down our most-read book.

Yes Yes! A Box of Board Books
by Leslie Patricelli

What I love about these books: The text on each page is so simple, it means you get to make up a story to go along with the illustration (umm… no, no hitting other kids with hammers?). Simple illustrations on plain backgrounds keep the distractions to a minimum. It’s a toss-up between No No, Yes Yes and Yummuy Yucky for which one gets read the most.

Here was my original code, which leaks if an error occurs in the initWithData:error: method:

- (AVAudioPlayer *)audioPlayerWithContentsOfFile:(NSString *)path {
    NSData *data = [NSData dataWithContentsOfFile:path];
    return [[[AVAudioPlayer alloc] initWithData:audioData error:NULL] autorelease];
}

If an error occurs in the initWithData:error: method (say because the file is missing), it returns nil. If it returns nil, autorelease gets called on nil, not on the AVAudioPlayer object, and the AVAudioPlayer object gets leaked.

Here’s the leak-free version:

- (AVAudioPlayer *)audioPlayerWithContentsOfFile:(NSString *)path {
    NSData *data = [NSData dataWithContentsOfFile:path];
    AVAudioPlayer *player = [AVAudioPlayer alloc];
    if([player initWithData:audioData error:NULL]) {
        [player autorelease];
    } else {
        [player release];
        player = nil;
    }
    return player;
}

The leak-free version stores the pointer returned by alloc, rather than the pointer returned by initWithData:error:. That way, whatever happens, the player can still be released.

Here’s the important bit from our texture loading code:

if(image = [UIImage imageWithContentsOfFile:aPath].CGImage) {
  width = CGImageGetWidth(image);
  height = CGImageGetHeight(image);
  data = (GLubyte *) malloc(width * height * 4);
  context = CGBitmapContextCreate(data, width, height, 8, width * 4, CGImageGetColorSpace(image), kCGImageAlphaPremultipliedLast);
  CGContextDrawImage(context, CGRectMake(0.0, 0.0, (CGFloat)width, (CGFloat)height), image);
  CGContextRelease(context);
  glGenTextures(1, &name);
  free(data);
}

I have literally no idea how malloc works, but from what I gather it doesn’t clean out the memory that it allocates. For some reason, the memory allocated for textures smaller than 64 pixels by 64 pixels has a bunch of garbage in it, which shows up as artifacts in the texture. Switching from malloc to calloc, which explicitly sets all the bits in the allocated memory to zero got rid of the problem.

Here’s the working code:

if(image = [UIImage imageWithContentsOfFile:aPath].CGImage) {
  width = CGImageGetWidth(image);
  height = CGImageGetHeight(image);
  data = (GLubyte *) calloc(width * height, 4);
  context = CGBitmapContextCreate(data, width, height, 8, width * 4, CGImageGetColorSpace(image), kCGImageAlphaPremultipliedLast);
  CGContextDrawImage(context, CGRectMake(0.0, 0.0, (CGFloat)width, (CGFloat)height), image);
  CGContextRelease(context);
  glGenTextures(1, &name);
  free(data);
}

Happy texturing!

@jasonkrogh asked what kind of units Box2D uses. Here’s the relevant bit about units from the Box2D manual:

Box2D works with floating point numbers, so some tolerances have to be used to make Box2D perform well. These tolerance have been tuned to work well with meters-kilogram-second (MKS) units. In particular, Box2D has been tuned to work well with moving objects between 0.1 and 10 meters. So this means objects between soup cans and buses in size should work well.

When you’re working with on screen objects like balls and squares, what’s important is that the units are not pixels.

@satefan asked:

For my little demo I set the dimensions of the world to 320 meters wide by 480 meters high. This seems to work fine and I don’t have to do any coordinate translations. Just curious… was there a reason why you decided not to do this?

The short answer: the physics won’t look right because your bodies and shapes will be much larger, heavier and faster than Box2D is expecting. Here’s what the manual has to say:

Being a 2D physics engine it is tempting to use pixels as your units. Unfortunately this will lead to a poor simulation and possibly weird behavior. An object of length 200 pixels would be seen by Box2D as the size of a 45 story building. Imagine trying to simulate the movement of a high-rise building with an engine that is tuned to simulate ragdolls and barrels. It isn’t pretty.

Let’s do the math for the the balls in the example game on the iPhone. If we set the world size to match the screen, then the world would be 320 meters across, 480 meters tall and 1 pixel on screen would equal 1 meter in Box2D. If the ball had a diameter of 64 pixels (which is does), it would have a diameter of 64 meters in the physics engine – that’s pretty small on screen, but more than six times the size of Box2D’s recommend 10 meter maximum.

Here’s an example of where this becomes a problem: Box2D has setting for the maximum velocity any body can have and the default value is 200 meters per second (you can see all of Box2D’s settings in b2Settings.h). Because things are so big, they’re also very heavy (think about how much a 64 meter wide ball would weigh!). To make them move, you have to crank gravity way, way up and apply a lot of force. You quickly run into the limit and everything ends up moving around at the same speed (which looks terrible, trust me). Rather than fiddling with the (many) settings, the best thing to do is a simple translation between screen coordinates and world coordinates:

// MyGameViewController.h

#define SCREEN_TO_WORLD(n) ((n) / 30)
#define WORLD_TO_SCREEN(n) ((n) * 30)

In the macros above, 30 is an arbitrary value. The idea is to choose a value that will convert the size of an object in pixels to a value that falls in the 0.1 meter to 10 meter sweet spot. By dividing the ball’s 64 pixel screen diameter by 30 in the SCREEN_TO_WORLD macro gives it a diameter of 2.13 meters in the world. What is a relatively small object on screen is now a relatively small object in the world – it also weighs less, so you can use smaller forces and don’t run into the maximum velocity limit.

Just make sure that any time you set any linear value (position, size, force) in the world, convert from screen coordinates to world coordinates. When you read any linear value from the world, convert from world coordinates back to screen coordinates. I like to use custom accessors to make it easier:

// Ball.m

- (CGPoint)position {
  if([self body]) {
    return CGPointMake(
      WORLD_TO_SCREEN(body->GetPosition().x),
      WORLD_TO_SCREEN(body->GetPosition().y)
    );
  } else {
    return CGPointMake(
        WORLD_TO_SCREEN(bodyDef->position.x),
        WORLD_TO_SCREEN(bodyDef->position.y)
    );
  }
}

- (void)setPosition:(CGPoint)aPosition {
  NSAssert(![self body], @"Cannot set position");
  [self bodyDef]->position.Set(
    SCREEN_TO_WORLD(aPosition.x),
    SCREEN_TO_WORLD(aPosition.y)
  );
}

Here are the slides and the source code for the example game I’ll be using in the presentation. I’ve included two versions of the slides, a short version that I’ll be using tonight, and a longer version that covers collision detection and using the accelerometer. The source code includes everything described in the longer version.

• Slides (Long Version)
• Slides (Short Version)
• Example Game Source Code

• Remember that somebody else (who may not know all the ins and outs of XCode) will be working on the project with you. Take the time to keep things neat and organized. Create a Classes folder with all your source code and a Resources folder with nib files, images, sounds, etc. Keep the organization of the project and the organization of the files on disk as close as possible, it’s less confusing for everyone. Give all of your files consistent descriptive names. Delete files that aren’t being used anymore (Tip: Make bundles for any resources that don’t need to be compiled, like images and sounds. XCode doesn’t keep track of the contents of bundle files, which means when you add/remove/rename files in the bundle XCode will automatically see the changes so you don’t have to remember to add and remove them from the project). Simple stuff, but it makes a big difference.
• Pushing updates to the App Store is a proven way of improving a game’s visibility, so make sure the project and the code are easy to update. Remember to slow down and do things well.
• Use Foundation and UIKit classes wherever possible — it helps keep user interface elements consistent and it’s easy for another developer to quickly see what’s going on and make changes without learning another 3rd party framework. For example, use a UIView with UIButtons for game screens. The exception to the rule here is the game engine itself, where the benefits of using OpenGL or other open source code are worth the trouble.
• Use Interface Builder wherever possible — this goes hand-in-hand with the last point. Using UIKit classes and Interface Builder makes it easy to adjust the layout of screens, labels for buttons, etc. without hunting through the code. Remember, the person making the adjustments may not be a programmer.
• Use UILabels for interface text, rather than embedding text in images. Keeping text out of images makes the project much easier to update and localize. Using native text for everything also helps keep things consistent visually – your high score screen is going to need dynamic text and the app will look better if it matches everything else.
• Memory management is very high priority on the iPhone. Use as little memory as possible. Don’t load things into memory until you need them. Release things from memory when you’re done with them. For example, rather than loading all of a games screens when the app launches and keeping them in memory for the life of the app, load each screen when it’s going to be shown and release it from memory after it’s hidden.
• Test the app regularly in Instruments during development to find memory leaks and avoid wasting memory:
  • Check using Leaks — This will help you find good, old-fashioned memory leaks.
  • Check using Object Allocations — An object in memory may not technically be a leak, but if it doesn’t need to be there it’s wasted memory. When you’re playing the game, are any of the objects associated with the other screens in memory? When you’re showing the game over screen, are any of the objects associated with the game engine in memory?
  • Check using Memory Monitor — Apple doesn’t specify a hard limit on the amount of memory an app can use, but the general consensus is that 15Mb to 20Mb is fairly safe. If your app is using 25Mb of memory you should be concerned. If your app is using 45Mb of memory you have a very big problem.
  • Check OpenGL Texture Memory — OpenGL on the iPhone has a soft limit of 24Mb for all textures. If you go above the limit, there’s a massive performance hit. See: How To Check iPhone Texture Memory Usage With Instruments
• Follow standard Objective-C naming conventions. They’re different from other languages, so take the time to read up on them. See: Coding Guidelines for Cocoa, Cocoa Style for Objective-C: Part I, Cocoa Style for Objective-C: Part II
• Put the dealloc method at the top of the @implementation block for every class you write. dealloc is the most important method in every class, so show it some love.
• Use accessor methods for everything — it’s the best way to avoid simple memory management bugs. Use accessor methods within classes, too. You can define private accessor methods in a category at the top of your implementation file. You can redefine a readonly property in the public interface as a readwrite property in the private category.
• Mark properties as nonatomic unless you have a good reason not to.
• Use square bracket syntax (i.e. [self foo], [self setFoo:@"bar"]) instead of dot syntax (i.e. self.foo, self.foo = @"bar") for accessing properties. Using one syntax keeps your code consistent, and makes it easier to see where you’re accessing a property of an Objective-C object as opposed to a member of a C struct or C++ class (which use dot notation).
• Avoid subclassing UIViews. Build the view hierarchy in Interface Builder and put your logic in a UIViewController. If you have a lot of UIView subclasses, you should be concerned.
• Remember to mark properties as IBOutlets and methods as IBActions wherever it makes sense.
• Organize related methods and properties into groups in the source code (i.e. the UIViewController subclass for a game screen might have groups like button properties, action methods and overridden UIViewController methods). Mark the groups in both the header and the implementation using #pragma mark Label. Organize methods within a group alphabetically. You’ll spend a bit of time organizing things and a lot less time looking for things.
• Use NSAssert() liberally. If you intentionally stop the app when something unexpected occurs, it’s easier to find where the problem started and fix it. It takes a bit of time to write the assertions, but I guarantee it takes less time than tracking down a bug later on.

The list above is by no means definitive, but it covers the basics. Let me know if I’ve left out anything obvious, or if there’s something that rubs you the wrong way. I’m always happy to learn a better way to do something.

The instructions below assume you’re a registered iPhone developer and have:

• Mac OS X 10.5
• XCode 3.1.2
• iPhone SDK 2.2.1
• Box2D 2.0.2
• A valid app id and development provisioning profile that you can use to build the project for a device.

So, for my future reference and yours….

1. Create a new XCode project. I’m creating a View-Based Application called MyGame on my desktop.

   

   

2. Open the terminal and export Box2D 2.0.2 from the Box2D svn repository into your project folder:
   svn export https://box2d.svn.sourceforge.net/svnroot/box2d/tags/Box2D-2.0.2 ~/Desktop/MyGame/Box2D-2.0.2
3. Right click on MyGame under Groups & Files and choose Add > Existing Files…

   

4. Browse to the your project directory, select the Box2D-2.0.2 folder and click Add.

   

5. Make sure the Copy items into destination group’s folder checkbox is unchecked and click Add.

   

6. Expand the Box2D-2.0.2 group and delete everything except the Include and Source groups. Whether you move the files to the trash or just delete the references is up to you.

   

   

7. Expand the Source group and delete the Makefile.

   

   

8. If you haven’t already, set the app id (in Resources/Info.plist) and the Code Signing Identity in the project build settings (in Project > Edit Project Settings > Build). Make sure you have Device 2.2.1 and Debug selected in the menu at the top left corner of XCode (anyone know what this menu is called?). Finally, build the project (Command-B).
9. Open up the build results (Command-Shift-B), and you’ll see a whole bunch of errors, along the lines of:

   error: 'finite' was not delcared in this scope

   

10. Open the project build settings (Project > Edit Project Settings > Build) and find the Other C Flags setting. Add the following flag, which tells Box2D that it’s being compiled for the iPhone so that it knows where to find the standard C++ libraries.

    -DTARGET_OS_IPHONE

    

11. Build the project again (Command-B). It will build cleanly, but we’re not quite out of the woods yet.
12. Open MyGameViewController.m and add the following line at the top of the file:

    #import "Box2D.h"

    

13. Build the project again (Command-B). Yay, more errors:

    error: initializer element is not constant

    

14. Select all of the .m files in your project (yes, all of them).

    

15. Click the Info button in the toolbar, go to the General tab and find the File Type dropdown.

    

16. Change the filetype from sourcecode.c.objc to sourcecode.cpp.objcpp. This tells XCode to compile the files as Objective-C++ (mixed Objective-C and C++ code) instead of plain Objective-C code.

    

17. Build the project again (Command-B). That’s it!

So there you go, you’re ready to start using Box2D on the iPhone. Just remember to change the file type from sourcecode.c.objc to sourcecode.cpp.objcpp for any .m files you add to the project.

When developing iPhone games, one of the biggest performance optimizations you can make is to use OpenGL ES for rendering (instead of CoreGraphics or UIKit). For a 2D game like Arctic Shuffle, this means loading all of the animation into Open GL as textures, and drawing them onto simple rectangular shapes.

There are two caveats to this approach. First, disk access on the device is dirt slow, so you can forget about loading textures on the fly – all of the textures need to be loaded before gameplay begins. Second, OpenGL ES on the iPhone has a texture memory limit of 24MB. If you try to load more than 24MB of textures (including any buffers, like the framebuffer), the device has to start swapping them in and out of memory, and you go over a performance cliff, so to speak.

With that in mind, it’s very helpful to know how much texture memory is being used by your game – this is where Instruments comes in (the instructions below assume that your device is plugged into your development machine and you already have a working debug build of your game on the device).

1. Open Instruments (/Developer/Applications/Instruments.app) and choose the “Blank” template.

2. In the bottom-left corner of instruments, click on the gear icon, then choose Add Instrument > Memory Monitory. Click the gear icon again and choose Add Instrument > OpenGL ES.

3. Click on the OpenGL ES instrument’s info icon, and make sure that GARTResident Object Size is checked.

4. Choose the device and application you wan to check. My device is named Barracuda and the application is ArcticShuffle2.

5. Click the record button. This will launch the application on the device, and start monitoring it’s memory and OpenGL ES usage. The GARTResident Object Size column shows the amout of texture memory used, in bytes. Divide that by 1024 (i.e. amount / 1024 / 1024) to convert the number to megabytes. Notice how the Frames Per Second drops dramatically while the textures are loading.

Happy Optimizing!

tell application "Finder"
	if not (exists disk "betsy") then
		mount volume "afp://luke@127.0.0.1/betsy"
	end if
end tell

Here’s how to do it…

Paste the above AppleScript code into the Script Editor (/Applications/AppleScript/Script Editor.app), then chose File > Save As… and save it as ConnectToBetsy.app. Make sure to choose Application instead of Script as the file format.

Then, add ConnectToBetsy.app to your login items. Open System Preferences > Accounts, select your account and choose the Login Items tab. Click the + icon at the bottom to add a new login item, and browse to ConnectToBetsy.app.

That’s it, you’re done! The next time you start up your computer, it will automatically connect to the network drive (It’ll ask you for your password the first time. Just make sure to check the Remember my password checkbox so it won’t ask you every time). If the network drive ever gets disconnected, you can just double click ConnectToBetsy.app and presto, you’re reconnected.

Enjoy!