Archive for the 'Bugs' Category

The Number One Problem With Game Center

January 10th, 2011
Spencer Nielsen Follow snielsen42 on Twitter

The biggest problem I see with the current implementation (iOS 4.x) of Game Center is that there is no way for Game Center users to authenticate themselves to 3rd-party servers. Let me explain from the top. Game Center is Apple’s new games oriented social network and infrastructure on iOS devices. It has a lot of great features like leaderboards, achievements and matchmaking. Once a user creates an account on an iOS device they are perpetually signed in at the operating system level. This is great because it means that all existing and future Game Center games can take full advantage of its features, social connectivity and never have to make users create an account (users HATE creating new accounts) or even sign in again (unless of course they explicitly sign out). From the game developer perspective, Game Center is really awesome. There are a lot of developers (myself included) who do not want to have to:

  • Create a complete login infrastructure
  • Store and handle people’s passwords safely
  • Figure out some sort of account confirmation
  • Implement password recovery
  • Encourage users to start building YET another social graph on your service/game
  • Handle other support related support requests


Neo Geo cart hacking is still alive and well

October 16th, 2010
Spencer Nielsen Follow snielsen42 on Twitter

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.

iPhone SDK, initial impressions

March 8th, 2008
Spencer Nielsen Follow snielsen42 on Twitter

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:

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

The common theme of which projects will and will not run seemed to be that they all used Open GL ES. I eventually stopped to read the description before downloading the example which explicitly states as much:
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.

Of NSServices and lsregister

March 5th, 2008
Spencer Nielsen Follow snielsen42 on Twitter


Launch Services is one of those things that does a lot of magic for Mac OS X but is not really visible on the surface and is somewhat vague and ethereal. Launch Services is responsible among other things, for associating file types with applications, associating icons, associating system services and many other wonderful things that make your experience just work. Fortunately there is a tool to poke at the Launch Services database buried in the system at:


Most notably the -dump command basically outputs the database so that you can see exactly why a certain file type wants to be opened by which app and why certain files get their icons and association hijacked by some other random new app. The -f command will let you update the database with any new changes you have made to an application or bundle.

Some of things managed by this database are the system services that show up in the “Services” option under the application menu (these are outlined in the NSServices array of a bundle’s Info.plist). Language Aid provides one of these as an alternative to the lookup trigger and contextual menu as a way to lookup text. Unfortunately, it appears that just tickling the database with the new information about which options you want available in the menu (dictated by which plugins you have selected), is not enough to rebuild the Services menu. A reboot seems to do the trick, but it would really be nice if I could figure out what causes that menu to rebuild.

Death to [NSBundle pathsForResources*]

August 27th, 2007
Spencer Nielsen Follow snielsen42 on Twitter

Ugh, this bug was so nasty to track down… Apparently if you call this family of methods a couple of times it screws up whether NSBundle can find resources in the future. My specific situation is that I would call this method to find what bundles are in a directory. I would then run it one more time (because that is how the code is laid out). Then when kqueue tells me that something has changed in that directory (because I added a new bundle to the target directory) I call it one more time. It finds the new bundle just fine, but for some reason it completely ignores the stuff in Resources/ when trying to query the contents of said new bundle! I don’t know if this is the result of some errant caching or what but it is consistently reproducible. The old bundles work fine but there is nothing that can make Cocoa see the contents of this new bundle. This is a big problem because it means that [NSBundle loadNibNamed:owner:] now can’t find any nibs in the new bundle (which was what first tipped me off to the problem). In the current Developer Tools Documentation under the entry for [NSBundle pathsForResourcesOfType:inDirectory:] there is a statement:

Note: This method is best suited only for the occasional retrieval of resource files. In most cases where you need to retrieve bundle resources, it is preferable to use the NSBundle instance methods instead.

I hope that is not implying this weird (caching?) behavior. Also, after the damage has been done NSBundle instance methods no longer work either. The solution to this has been to instead use a UNIXy way like scandir() to find out what bundles are in a directory. Not nearly as graceful, but at least I don’t have weird peripheral behavior. So anyway…fair warning to all against using these routines.

Entries (RSS) and Comments (RSS).