Blue Lotus Blog

I have spent quite a few hours with the iPhone SDK now and must say that I am quite impressed. The experience of bringing some of my code written for Mac OS X over to the iPhone with no changes and having it just work is quite a pleasant experience. I REALLY enjoy being able to use Objective-C 2.0 synthsized properties and fast enumerators in my code (garbage collection would have been nice but hey, this is a mobile device). I maintain Tiger support for Language Aid and develop purely for Leopard in Razor and it is kind of an interesting mix of both to code for the iPhone. I am really excited to to flesh out a game I have been thinking of for the iPhone that would take advantage of a lot of its unique features.

So the posted requirements say that this beta version of the SDK requires an Intel Mac but so far I have not run in to much trouble developing with it on my G5 (the only Intel mac in the house right now is a Core Solo mini which is already pulling duty as a source server, build server, DVR and media center). Inspecting the simulator and the xcode plugins show that they are all universal binaries. The only gotcha that I ran into is that I had to make sure that in my build settings that the “Architectures” setting is set to “Native Architecture of Build Machine” so that the binaries produced are ppc so that the simulator (I have heard a surprising number of people errantly referring to it as an emulator) can load and run them. For some reason this reset itself to i386 one time and I had to track it down to that setting.

Other small quirks that may or may not be related to me running on ppc are that it seems like every 10th click event or so on the simulator window seems to fall through and hit the window behind it. Also, for some reason the simulator is also not responding to the “Rotate” commands whereas it would correctly respond on my Intel mini. Of the example code on the developer website there are a lot of projects that will not run in the simulator due to a pragma that intentionally errors itself out if built targeting the simulator:

#if TARGET_ASPEN_SIMULATOR
#error This application cannot be run in the Aspen Simulator. Please change Active SDK to “Device” and ensure a device is connected.
#endif

Simply build the sample using Xcode and run it on the device (OpenGL ES is not supported in the simulator).

It is inevitable that I will plunk down the $99 to be able to perform remote debugging/use Instruments/use Shark with a real iPhone. However, for now while I am busy bringing up the core game engine and getting used to the new platform, the simulator is doing just fine.

After a long time tweaking and puttering with the physics engine I think I have finally gotten close to the kind of settings that are needed for the kind of simulation that I want (dContactApprox is the flag that finally fixed a lot of my problems). I have also introduced projectiles into the mix by adding the “Shell” class. The Shell class is actually just an Actor and is treated the same was as any other tank or other object in the game. It just so happens that tanks create shells and they initially have a great force exerted on them.

I have also put a lot more work into NSObjectInspector (probably to be renamed in the future) so as to be able to support more debugging of the plugins at runtime. I am getting the hankering to spin it off as a general debugging tool for developers because it is just so darn useful.

The idea behind NSObjectInspector is that when you debug a program sometimes you want to just change a value in an object while you are debugging your program at runtime instead of recompiling or writing some sort of user interface to interact with an object’s value. Because the Objective-C runtime affords us a lot of information about what instance variables an object has or what methods it has implementations to, we can provide a general class that can inspect other objects and provide a user interface with which to poke at them with.

Currently it provides interfaces to object instance variables, accessors (method or method pairs in the form of -(void)setMethod:(type)a and -(type)method) and commands (methods in the form of -(void)method). It currently excludes anything in the class NSObject and well known methods that have substantial peripheral effects such as -(id)init, -(void)dealloc and -(void)finalize. Currently supported values are any sort of number type and ids of type NSString. Eventually I plan on creation of class specific exemption lists as well as control hookups.