For the past month or two I have been lightly seeding to Cannonade to testers. I have gotten the strong impression that the “fun” of my game was unfortunately getting lost in the low framerate. There is a certain reaction in the human brain that I am trying to evoke by making the blocks explode and collapse in physically realistic ways. However, when the framerate is too low the perception of motion is lost and so is my core game mechanic. I first spent a lot of time optimizing the execution of the Bullet physics engine and found a significant speed increase by tweaking compiler settings. I found that the execution of the physics simulation on iOS devices was very strongly locked to CPU performance. Now the time had come to start attacking the performance of the graphics engine. I was hopeful that I would be able to find even more significant speedups in this area because the graphics engine was custom written by myself and I could also employ device specific optimizations to take advantage of specific strengths or avoid specific weaknesses. Many of the techniques I tried out were nothing that hasn’t already been done before but I thought it would be worthwhile to document my experiences executing them in my specific situation. These are the results of a week and a half of aggressive performance benchmarking, exploration and experimentation. It goes without saying that my results are very data set specific and so they could perform better, worse or the same when applied to a different iOS app.

(more…)

One day while I was hard at work a couple weeks ago I hit a really difficult technical snag. I stood up from my desk, let out a sigh and declared to the other person working in the office that “I’ve lost my determinism!”. He then inquired how I had lost my motivation while visibly wondering if I had used the word correctly. Although I had hit a significant roadblock, my determination to overcome it and make progress on my game was higher then ever. The “determinism” of my game however, had been lost. Now I needed to take it back.

(more…)

A couple of years ago I wrote an article called Neo Geo Cart Conversions which detailed a cool hobby project that involved turning a Neo Geo game called Metal Slug from an MVS (Arcade) version cartridge into an AES (Home) version.  The primary reason for performing the conversion was to save the thousands of dollars it would take get a hold of an authentic AES cartridge and experience the original game at home legally (plus, doing the actual conversion was tons of fun!).  A few years later I decided that it would also be fun to do a write up of my experiences and share my findings for others to enjoy.  Over the years people have occasionally emailed me about the article with compliments and questions about the article.  It has also been especially satisfying to hear about people who have successfully performed their own Metal Slug conversions by following my article.  So far there have been four people that I know of who have done so, the latest of which is Akira Van who sends this image of his finished product:

It just goes to show that despite the end of officially produced Neo Geo carts, the wide and cheap availability of Neo Geo games in virtual console/compilation form and essentially the entire video gaming world moving on that there is still a vibrant and thriving community of enthusiasts and hackers dedicated to this great platform.

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.