Daniel Sperl, developer of the Sparrow Framework, recently posted a performance comparison on the Apple Developer forum where Sparrow ran 2.5 times faster with MRC code than the version upgraded to ARC.
A curious finding though it seemed very far off from real world observations. Being a synthetic benchmark no less. I decided to do a similar test based on the same code comparing cocos2d v2 and v3.
Fortunately cocos2d-iphone v3 has made a similar switch from MRC (v2.1 and earlier) to ARC (v3 preview). Unfortunately the internals of cocos2d also changed to some extent, for example custom collection classes written in C were replaced by Core Foundation classes. I don’t have a full overview of the changes, but at least the renderer doesn’t seem to have changed in any significant way. Yet.
So while comparability is good, it’s not like Sparrow where truly the only changes made were converting the code from ARC back to MRC. Take the following benchmark results and comparisons with two grains of salt and pepper on the side.
ARC vs MRC
The original benchmark done with Sparrow has seen MRC perform 2.5 times better than ARC in a synthetic “draw as many sprites as possible until framerate has dropped consistently below 30 fps” test:
How do you measure the popularity of a game engine and compare it with others?
Reminded of the TIOBE Programming Language Index and the Transparent Programming Language Popularity Index I couldn’t find a comparable site measuring game engine popularity.
So I sat down and concluded that I can do a simple manual test rather quickly. These are the measurements anyone can take easily:
- Forum topic, post and member counts (if available)
- Stackoverflow.com and gamedev.stackexchange.com tag counts
- Google search query results
Popularity of Cocos2D Variants
Let’s begin by comparing the popularity of the various Cocos2D variants. The difficulty here lies in properly excluding all the other cocos2d variants. That cocos2d-iphone is commonly referred to as just “cocos2d” makes it difficult to measure just the cocos2d-iphone popularity and to remove that number from all other engine variants.
I tried to overcome this by including or excluding specific tags in Stackoverflow and Gamedev searches:
- cocos2d-iphone: [cocos2d-iphone] or [cocos2d] -[python] -[java] -[javascript] -[c++] -[html5]
- cocos2d-x: [cocos2d-x] or [cocos2d] [c++] -[python] -[java] -[javascript] -[html5]
- cocos2d-android: [cocos2d-android] or [cocos2d] [android] -[cocos2d-x] -[c++] -[python] -[objective-c] -[html5]
- cocos2d-javascript: [cocos2d-js] or [cocos2d-javascript] or [cocos2d] [javascript]
- cocos2d (python): [cocos2d-python] or [cocos2d] [python]
- cocos2d-xna: [cocos2d-xna] or [cocos2d] [xna]
- cocos2d-html5: [cocos2d-html5]
- cocos3d: [cocos3d]
- kobold2d: [kobold2d]
- cocosbuilder: [cocosbuilder]
Stackoverflow.com tag search results:
Okay, let’s try that again with cocos2d-iphone removed so the other variants can be compared in relation to each other: Continue reading »
Or so goes the argument. Still.
I wish Apple would just pull the plug and completely remove MRC support from LLVM. I’m getting tired, annoyed and sometimes angry when I browse stackoverflow.com and frequently find MRC code samples containing one or more blatant memory management issues.
Before I rant any further, this article is about testing the performance difference of ARC vs MRC code. I provide some examples, and the updated performance measurement project I’ve used before for cocos2d performance analysis, and the results of the full run at the bottom. I also split it into both synthetic low-level tests and closer to real-world algorithms to prove not one but two points:
ARC is generally faster, and ARC can indeed be slower - but that’s no reason to dismiss it altogether.
Measuring & Comparing Objective-C ARC vs MRC performance
Without further ado, here are the results of the low-level MRC vs ARC performance tests, obtained from an iPod touch 5th generation with compiler optimizations enabled (release build): Continue reading »
I’m currently working on a new tilemap renderer for KoboldTouch.
I now have an early version that’s fairly complete and does most of what cocos2d’s tilemap renderer can do. Pun intended: yes, cocos2d’s tilemap renderer really doesn’t do all that much: load and display tilemaps with multiple layers.
In fact my current implementation is one step ahead already:
KoboldTouch’s tilemap renderer doesn’t require you to use -hd/-ipad/-ipadhd TMX files and the related (often hard to use or buggy/broken) TMX scaling tools. Just use the same TMX file designed for standard resolution, then simply provide just the tileset images in the various sizes with the corresponding -hd/-ipad/-ipadhd suffixes. The tilemap looks the same on a Retina device, just with more image detail.
Performance Comparison
Anyhow, I thought I’ll do some quick performance tests. I have a test map with 2 layers and a tiny tileset (3 tiles, 40×40 points). I’m comparing both in the same KoboldTouch project, using the slim MVC wrapper (named KTLegacyTilemapViewController) for cocos2d’s tilemap renderer CCTMXTiledMap. Continue reading »
I posted a KoboldTouch vs cocos2d-iphone architecture comparison chart to the KoboldTouch product page.
It’s only a start to better explain how KoboldTouch compares with cocos2d-iphone.
KoboldTouch Mini-Game
I’m now working on a KoboldTouch mini-game to showcase the KoboldTouch workflow and features. It’ll be the basis for the KoboldTouch Introduction Tutorial.
I’ll post a video presentation of the project and key points once it’s done. If you’re interested you can follow KoboldTouch development via PivotalTracker.
The mini-game project is also very important to “eat my own dogfood”. Even just a simple game made several things that didn’t feel right obvious, and presents opportunities for improvement.
I’m happy that the KoboldTouch users requested this simple game tutorial.
Excellent Growth
Speaking of members: leaving aside the initial 2-day launch rush, on average two new members sign up every day.
If KoboldTouch continues to grow at this rate, it will have 100 members before Xmas! That would be a major milestone I did not expect to achieve before February/March!
You can help KoboldTouch by taking 5 minutes of your time to complete the Cocos2D Developer Survey. I’ll post the results in a week and what they mean for KoboldTouch.
I’m looking for a good Text Editor for Mac OS X that supports Lua (preferably without installing any additional files). And I also want the editor to support autocomplete (aka code completion) for the Lua language, as well as being able to extend the autocomplete keywords.
Much to my dismay this narrowed down the field quite a bit. Therefore I created this list with short (and subjective) reviews of Text Editors for Mac OS X which you may find a good extension to Wikipedia’s Comparison of text editors.
But first, I want to be sure we’re all on the same level when we talk about the autocomplete feature. This Qt Creator video with Thorbjørn Lindeijer (of Tiled Map Editor fame) shows you what this feature is all about (beginning at 0:15).
I wanted to find the text editor for Lua that suits my needs. Since there are so many text editors, I quickly dismissed those editors that didn’t support autocomplete. And those whose Lua support needs to be installed manually also took a backseat rather quickly. By all means: please do correct me where I’m wrong, inaccurate, etc. I’m also open to discussing the inception of a flame war, if deemed helpful. 
This quick comparison sheet gives you all the info to decide whether to use Cocos2D 1.x or Cocos2D 2.x. Contrary to most programs, a higher version number doesn’t infer “better” or “more”. There are pros and cons for both versions.
At the time of this writing the decision really only boils down to whether you want to use shaders and whether you must be able to deploy your app to 1st & 2nd generation devices. See for yourself, it’s that simple:
Cocos2D v1.x(+) compatible with all iOS devices |
Cocos2D v2.x(+) OpenGL ES 2.0 shader programs |
All other differences to this day are minor, and most new features and bugfixes have been migrated back and forth between versions. For beginners I strongly recommend using v1.x as there’s a lot more documentation available for this version. Those who have no interest in writing shader programs can also safely use the v1.x branch without missing out.
I took Mike Ash’s performance measuring code from 2008 with the improvements made by Stuart Carnie in early 2010 and turned that into a performance measuring project for 2012.
I know it’s still 2011, consider this a forward-looking statement. In any case, the test project is available for download, ready to run, includes Cocos2D v1.0.1 and is relatively easy to modify for your own needs. This project is also available on my github repository where I host all of the iDevBlogADay source code.
Since numbers are so dry and hard to assess, you’ll find the rest of this post garnered with charts and conclusions based on the results obtained from iPhone 3G, iPod 4 and iPad.
