|October 31st, 2009|
The story behind our motivations to do the port are outlined in a blog post that Mike wrote soon after we got our first kinda working build running. It has some neat background and traces back how we actually made the decision to do the port. So once we decided to do it we buckled down and got to work.
The first concrete step in any port (after you have established your strategy) is to get the codebase to compile. The code compile bringup effort was substantial but at the time that we started the iPhone port, a lot of the APIs Caster used already had iPhone support in them. iGLU made it so that we didn’t have to re-write hardly any glu code. The trunk of the SDL 1.3 source repository had some initial iPhone support in it which made a lot of setup and interaction work almost out of the box. The last major thing we needed was an immediate mode wrapper so that we could be sure that the initial bringup of the existing source worked first and then afterwards we could do everything the right way. For the time being we completely removed the sound code as we were looking to convert everything over to OpenAL later. There were of course a lot of other little iPhone specific things that also needed to be addressed but they weren’t big issues as far as code compilation was concerned. After a fair amount of work in those areas we got it compile, link and launch.
The issues that we saw upon launch were addressed one by one and it wasn’t long before we actually saw the title screen animation and main menu! At that point we were still working in the Simulator. Amazingly enough we were able to interact with the menu buttons and navigate around the menu system right away. We did a fair amount of work to get things running in landscape mode and then started removing higher level graphical effects that either didn’t work or ones that we knew would be too expensive to implement on the iPhone version initially. We also spent some more work on the Open GL ES immediate mode wrapper with the aim of getting actual gameplay up and running. Initially we used the exact same assets as the desktop version of Caster. We knew that we would eventually need to work on an asset conversion system that we could use to point at the desktop assets and have it convert everything down to an iPhone optimized version automatically. It wasn’t too long before we had our first set of actual gameplay screenshots which was a great milestone! We shoved in some quick and dirty control code so that we could move the camera/character around and observe the (expected) graphical glitches. We had reached this point relatively quickly (about 2 -3 days in our spare time) and we were really stoked that we had gotten the game actually up and running this fast. The next part was going to be getting it to build and run on actual hardware and work to get things running correctly. This was interesting because neither of us had an x86 Mac at the time. We ended up procuring hardware from friends and family and actually developed all the way to the 1.0 release on borrowed hardware.
Once we got the signing keys set up we went straight to work on getting Caster to run on actual iPhone OS hardware. It appeared that we needed signing keys to even build at all against the 2.2 and 2.2.1 SDKs for the device. Getting Caster to actually run on the device was a huge rush and even though it ran at a slideshow framerate we were really excited that our desktop game was now running on this tiny device. The first two major pieces of work that we attacked were getting Open AL sound brought up and starting work on the asset conversion scripts. Getting Open AL going wasn’t too hard because it was structured somewhat similarly to irrKlang which is what the desktop versions ended up shipping with (it was the the last of a couple of different sound APIs that had been implemented over the development life of desktop Caster). There were a few small gotchas but it didn’t take long before we had 3D sound up and running. One thing we found was that when quitting the game while a sound was playing would produce this ugly sounding buffer loop and occasionally the process would crash despite our (to the best of our knowledge) clean teardown of OpenAL. It was easy enough to avoid these problems by sleeping for 3 seconds on exit to let the currently playing audio finish up. We decided to wait on getting music working till a little bit later.