Issues with CrashLander Apple example

Many people start with Apple's OpenGL CrashLander source as their jumping off place for iPhone game applications. That's fine, but there are a couple of bugs in the code to be aware of.

First, there is a bug in the OpenAL sound engine wrapper. It's a memory leak. It's been detailed ad nauseum in many blogs, so I'll skip it.

Secondly, the accelerometer sampling rate is 100Hz. Have you ever noticed the myriad of cheap applications that seem to occasionally launch with a non functioning accelerometer? This is why. It seems to hang about 1/10th the time with this rate. Turning the sampling rate down to 20Hz or so alleviates the hangs. It's a strange problem really, clearly not hardware related. Instead it seems related to OS queue overflows.

And finally...
Version 1.8 contains the following code:

if(_position.y + CGRectGetMinY(rect) <= kBaseOffset + (GLfloat)[_textures[kTexture_Base] pixelsHigh] / 2)

The issue with pixelsHigh is that it always returns a power of two. This may work with the small and thin crash landing pad, but people take this code and try to use it as a starting point for their own code. As they add larger images and try to use this code for collision detection of larger images, lots and lots of time starts to get wasted tracking down the problems.

It would be preferable to start people off correctly and use something instead like this:

[self getSize:kTexture_Base].height