Paul Hart

While I’m making good progress with my project, I’m still far enough from completion that I don’t mind trying out bleeding edge versions of the libraries I rely on. In that vein, I’ve upgraded my game to use the cocos2d 0.9.0-alpha library that was announced a few days ago. Here’s my upgrade story.

Do No Harm

First things first, make a backup of the project. In case of emergency, it’s easier to revert the processes undertaken. I simply made a tar file of the project directory and then gzipped it.

Excise The Old Tissue

I deleted the ‘cocos2d’ directory inside my “cocos2d Sources” group of classes (I’d create the project using one of the cocos2d templates). When asked, I told Xcode to move the files to the Trash, not just delete the references.

Introduce The Transplant

Next was copying in the new ‘cocos2d’ directory from the 0.9.0-alpha tarball into the place the old version of the directory inhabited. I stated I wanted to copy the files, not just references, and that I wanted them added to the ‘cocos2d libraries’ subproject.

Administer The Anti-Rejection Medication

At the bottom of the new ccConfig.h file is a commented out line that creates a CC_COMPATABILITY_WITH_0_8 flag. This is required initially, and will make cocos2d create stub classes that use the 0.8 naming conventions but flag their use with deprecation warnings.

Move to Intensive Care and Observe The Patient

Now that the new files are in place and prepared, it’s time for a clean and compile. The result: a whole bunch of warnings as expected, but also a handful of errors. Errors are bad.

Fortunately, all the errors were the same – the compiler was complaining about the lack of a TargetedTouchDelegate protocol. This has been renamed CCTargetedTouchDelegate, so that change was applied liberally through the header files, the compile was fine, but the linker hated me. Turns out that the addition of the files to the ‘cocos2d libraries’ subproject was a mistake. With that checkbox unchecked, the linking went fine.

Fool Me Once…

Okay, so I really wanted to have my cocos2d folder live within the subproject build, not the main project. I deleted that new cocos2d directory again, and before adding it back I set the active project to be the ‘cocos2d libraries’. When I copied the files back into place, I was given the choice of making them exclusively part of that target, and did so. Then I set the active project back to my app, updated ccConfig.h again, cleaned the project, and compiled again. All good.

Removing The Stitches

The setup was all corrected, now I needed to deal with the warnings. Most of these simply required the addition of the new ‘CC’ namespace prefix. A few class names had changed completely though:

• TextureMgr is now CCTextureCache
• AtlasAnimation is now part of CCAnimation
• AtlasSprite is now part of CCSprite
• AtlasSpriteManager is now CCSpriteSheet

Where the class name had changed, there were a few method name changes to go alongside. Animation changes were slightly more involved, but not significantly so. My code now compiled without any warnings. All done, right?

Fool Me Twice…

The last step was to re-comment the line in ccConfig.h that enabled 0.8 compatibility. A clean and compile later, and there’s a ton of errors again! Looks like not everything has a deprecation message yet. These classes included Director, TouchDispatcher, and some animations. The fixes were all class renames, and then it was done.

A Simple Operation

All in all, this was a pretty simple feat to accomplish, though I got a lot of help from the upgrade guide and the community forum.  The cocos2d library is great and I look forward to seeing what new functionality the 0.9 series will bring us.