True Myst Multi-Ball

A number of years back I watched pretty much every promotional video ever made for every pinball machine. I was not only looking for interesting machines for my collection but I was also looking for interesting features that could be used my own new machine. On feature that seemed interesting was the Myst Multiball feature from Willaims 1993 machine called Dracula.

Williams thought so much of their feature they even filed and received a patent on the design. It's a fairly rudimentary underplayfield ball screw actuator with an electromagnet on the top. It's pretty weak though, after all where is the MYST in this Myst Multiball feature? A little bit of art work on the playfield? Pshaw.

So check my interpretation of true myst multiball!

Solid State Pop Bumper

The Pop (or Jet) bumper is one of the primary sources of action in a traditional pinball machine. A few years back I got to thinking that since it's so mechanical its prone to failure. Why not design a solid state pop bumper with some modern technology? It has no moving parts. That's a big plus for pinball machines that might otherwise need replacement parts on location. I CNC machined an aluminum shape that looked like a pop bumper and accepted a standard rubber ring and pop bumper cap. Inside is an accelerometer. Underneath is an electro magnet. It's very cool to watch work. No moving parts. The ball action is great, very similar to a standard pinball pop bumper which is more Rube Goldberg that anything else ;) That said, it does have a couple of down sides. First, it takes an awful lot of real estate under the playfield. This is especially the case if you're looking at filling a 360 degree area around the bumper with electromagnets. Secondly, and probably most importantly it lacks the human factor pinball feel. It doesn't quite feel as fun as a real pinball pop bumper when you're holding the machine at the flipper buttons. Maybe if it had a thumper motor installed in the cabinet :)

Here are a couple videos of my prototype in action from a number of years back.

Cranking iPhone Performance to 11, Without Inline Assembly

I've been writing high performance code on microcontrollers and digital signal processors for embedded systems since the early 90s. I've made a career in realtime control software, the likes of which you'd see in military tracking systems or even in the computer running the engine of your car.

At GDC Austin 2009, Noel Llopis (@SnappyTouch) gave a compelling presentation entitled "Squeezing Every Drop Of Performance Out Of The iPhone". His presentation provides a wonderful overview of the performance concerns in developing applications for the iPhone. This is good stuff, close to my heart.

Noel also gave a presentation at 360iDev here in Denver entitled "Cranking Floating Point Performance To 11". The core of his presentation revolves around utilizing the vector floating point unit by moving more code into inline assembly.

Here is where our opinions differ. I was on that path too. In the early 90's I wrote about half of my code in assembly language. But by the early 00's it was probably 10% and now it's zero. You see, over the last ten years or so things have changed. The machine instruction sets in modern processors are more powerful than ever. They're also getting more difficult to understand. This is especially the case when it comes to optimization and 'hidden' repercussions like pipeline stalls. Having a pipeline means you can reorder your code in a way that causes either a great performance boost or loss.

A few months back I got together with one of my fellow iPhone developers, former CTO of Tendril Networks. We were working on an audio project to do pitch detect and shift (what some people call "autotuning"). The application required running two FFTs every 20 milliseconds. We were pretty much at the limit of the device's capabilities.

We spent the whole weekend working with the Xcode iPhone debugger, Shark, and Instruments and this was our strategy...

Empirical Compiler Optimization:
1. Measure the performance of the time critical section
2. Adjust the optimization settings of the compiler
3. Repeat

Empirical Code Style Optimization:
1. Measure the performance of the time critical section
2. Adjust the C/C++/Obj C code
3. Review results in the debugger's dissassembler
3a. Look for fewer lines of assembly (which is almost always faster)
3b. Look for fewer library calls
4. Repeat

Why we favor this approach:
1. Learning curve involves only cursory understanding of the VPU assembly
2. More time for developing usability and marketing your application
3. It's much, much, much less error prone than inline assembly
4. Not likely to inadvertently trigger performance problems with pipeline stalling
5. Performance will likely be BETTER than inline assembly in all but the rarest of circumstances

The primary compiler optimization setting tricks (optimizing for speed over size):
1. Dissable Thumb mode
2. Set optimization level to "Fastest -O3"
3. Unroll Loops
4. Other C Flags = "-falign-loops=16"

The primary source optimization tricks:
1. Condense code into smaller chunks that fit inside the instruction cache
2. Use all floating point
3. Don't do indexed array lookups inside a bunch of floating point math (this will stall the vpu pipe)
4. Don't use any division, instead always multiply with 1/x

I hope you're able to use some of this advice in your own applications - and crank it to eleven. :)

(Image courtesy Joseph Tey)

Apple TV takes on Wii

Apple has challenged the smart phone industry with the iPhone. However, I'm not so sure we saw the challenge coming to the handheld gaming
industry with the iPod Touch. Apple didn't target handheld gaming, the market just pushed their products there said Jobs in a recent interview.

Apple will release new Apple TV hardware. The primary addition will be an improved controller. Like the Nintendo Wii controller, and so many Apple products, the new controller will contain an accelerometer. This will speed text entry and add tilt input for applications and gaming. With each passing day iTunes makes more headway with the sale and rental of television, movie, music, and application content for Apple's platforms. Driving applications into the Apple TV is a logical and simple next step. Apple already has a devoted and thriving third party developer base and can shift that development and distribution framework over pretty easily to the Apple TV. We'll start to see Apple TV ports of all our favorite iPhone applications first. The Apple TV will become a serious contender to the console market and the Nintendo Wii, just as we saw the iPod Touch become a contender with the Nintendo DS.

Tiki Bar Sneak Peek

Sales on spirits in the USA are up 2% this month. Let's celebrate by getting angry at the bartender for serving slowly!




BTW, if you're from Bacardi Rum and want to license this gem for iPhone and iPod Touch please let us know! ;)
Coming soon... to... http://itunes.com/app/tikibar

Location aware leaderboards for iPhone

The original iPhone SDK shipped with a game called Crash Lander. The game's high score system used the NSUserDefaults preferences system to store and retrieve scores. Upon game completion, a name and score were entered into the non-volatile preferences system. This high score table and players names persisted between application runs. What's interesting is that all the user names and scores are stored. It's incorrect to assume that many people are playing a single iPhone. It's as if this we were all standing in line, dropping quarters an 80's arcade game!

The iPhone is a Generation M device. If you're building an application for Generation M you should assume there is only one person playing on that machine. You're mobile, you have a location engine, you have internet connectivity - use them.

Unlike when the iPhone SDK came out there are now serveral projects that will handle the server side and in many cases much of the client side of the equation for you. Features include geotagged scores, awards and achievements, online/offline management, Facebook / Twitter integration and scalable servers. Most services use Google App Engine or Amazon S3 server services.

Most services are currently free. It's unclear how they will eventually be monetized, and as such one can only imagine there is some risk in integrating them and then having them later disappear.


http://devsupport.agon-online.com/
Polished interfaces, supports landscape.

http://code.google.com/p/igetscores/
Very simple, you'll have to handle all the UI.

http://www.cocoslive.net/
Fairly simple, you handle most of the UI.

http://www.z2live.com/
Supports voice-chat too?

http://www.openfeint.com/
Feature rich, and polished interfaces.

Your approximate wait from this point in line is...

14 days
Interesting this exists now, albeit somewhat hidden.
http://developer.apple.com/iphone/news/appstoretips/

Apple App Store Review Times

We've been waiting for the latest Abby Crabby update for just about three weeks come Saturday. We received the dreaded "Requiring unexpected additional time for review" email from Apple within the first week.

Since the 3.0 OS update review times have grown from just under a week to three weeks. Apple is getting buried under the weight of their own review process. There are over 50,000 applications in the store now. Imagine the work load on the Apple review team when nearly all of them update all at once with 3.0 bug fixes and feature enhancements. Imagine what happens around Christmas 2009 or when there are over 100,000 applications in the channel.

Are you the recipient of a "requiring unexpected additional time for review" email from Apple too? Unfortunately this is always bad news, but it is rectifiable. It means your application has failed part of the first line of qualifications and wound up in a bucket. Did you know there are full time employees at Apple who's full time job it is to review applications that "fall into these buckets"? I know because I just spoke with one in Cupertino today. Interestingly it may not be something in the update or even the software that's got you but something in your old description! Make sure your description does not mention anything about demos, charity, future features, giveaways or alike.

Tiki Bar

Our upcoming iPhone game is called TikiBar. We're pretty excited about it. It's inspired by Ore No Ryomi. The game engine and tile atlas have really come along. There is simply too much graphics and animation going on in TikiBar to use the engine we used in Abby Crabby and Spell Flyer.


Did you know a game doesn't just go from storyboard to completion? We have to iterate and refine both the art and the game play. It's one of those "it takes 90% of the time to complete the last 10% of the work" kind of things. But it's worth it! People notice what's missing, not what's there. Without refinement, you wind up with something that was rushed out the door, not fun, interesting or dynamic.

The art is part of that refinement process and it has also been coming along for TikiBar. Included here are some development shots of the backgrounds in upcoming TikiBar game for iPhone.

iPhone OS 3.0 OpenGL Bug

We ran into a weird OS 3.0 bug. The bug causes the display to become corrupted. As you can see in the screenshot, it's stretched vertically, but mirrored horizontally. The bug only crops up on devices with OS 3.0. And only on the 2nd generation iPod Touch and the new iPhone 3GS.

With the release of the iPhone 3GS Apple now has five devices in the product line. We've been using OS 3.0 since it was released to developers back in March. We've been testing our products against 3.0 since then. What wasn't obvious to us, probably isn't obvious to much of anyone, is that bugs can crop up in only a few of the devices. Just because something works on most of the OS 3.0 devices doesn't mean it works on all of them.

Thankfully the market segment affected by this bug is pretty small. Only 1/30th of all iDevices are iPhone 3GS. And only 30% of iPod Touch users have upgraded to OS 3.0. Google for the references if you're curious.

It took us a while to figure this out. It's an unusual bug. No one in Apple Developer groups seems to have ever seen it. Anyway, it turns out you cannot rotate the OpenGL view on 3.0. It simply doesn't work on all five devices in Apple's lineup. Instead you have to rotate each OpenGL frame as you draw it.

We corrected the problem and there was an update submitted today to the Apple App Store for Abby Craby.