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 »
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.
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 »
Continue reading »
It’s only a start to better explain how KoboldTouch compares with cocos2d-iphone.
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.
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:
(+) compatible with all iOS devices
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 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.
- About the Test Project
- Comparing the Devices (iPhone 3G, iPod 4, iPad)
- How image formats influence loading times
- Re-visiting CCArray Performance
- Cocos2D: How children count can affect performance
- Cocos2D: How long it takes to create nodes
- A word of caution for the Tilemappers
While writing the Learn Cocos2D book I was surprised to find that Cocos2D’s CCSpriteBatchNode was only able to increase the performance of several hundred bullet sprites on screen by about 10-15% (20 to 22.5 fps). I wanted to re-visit that scenario for a long time because as far as I understood, the more sprites I was drawing the greater the impact of CCSpriteBatchNode should be.
But even Cocos2D’s own sprite performance tests (compare columns 9 and 10) revealed a performance difference of under 20% (39 to 42 fps). It’s only when all sprites are scaled and rotated, or most of them are outside the screen area, that sprite batching seems to have a bigger impact (25 to 60 fps). Surely that scenario is not applicable to most games. So I started investigating.