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:
For Kobold Kit (the Sprite Kit game engine) we’re working on Super Stick Spy, a 2D platformer game. Like so many others, we started out using the (Box2D) physics engine that’s so neatly integrated in Sprite Kit to get everything up and running quickly.
But we knew full well that for the final product, we’ll have to scrap the physics engine altogether and follow best practices when it comes to platformer-programming.
Now with the demo version nearing completion (see video) I can tell you in full detail why you don’t want to use a physics engine for a 2D platformer!
Moving Platform Hell
A moving platform with physics needs to be a dynamic body. Don’t even try moving static bodies, at least in Box2D that will end up in jumpy movement of the body. Though kinematic bodies work better (if available).
The player or other game characters standing on a moving physics body will have the platform slide underneath their feet. The characters won’t magically move along with the platform! And there is no feature in the physics engine that lets you set this up. You have to program it to synchronize character movement with the platform they’re currently standing on, and end the synchronization as soon as a character lifts its feet up from the platform.
Which can be a problem for downward-moving platforms as the player loses contact with the platform every other frame, starts falling, and lands right back on the platform. To put it in Homer’s words: “Doh, doh, doh, doh, doh, doh, doh …”. So you need to make the character stick to the platform, yet allow him to fall off of the ledges and jump, and possibly also allow him to be forced off the ground by normal collision events (projectile impact, platform moving through a tiny crevice). Continue reading »
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 »
This is a guest post by Nat Weiss, author of the cocos2d-iphone RPG Game Engine and the cocos2d-x Paralaxer Game Kit. Today he shares his experience working with the two most popular cocos2d game engines, and explains how and where they’re different.
He also needs more beta-testers for his latest game: Awesome Heroes Arena.
Over the last year, my bro Kristopher Horton and I have been developing a realtime Multiplayer-Online Battle Arena (MOBA) game for tablets with cocos2d-x. The game’s called Awesome Heroes Arena and we are finally at the point of taking on beta testers: here’s the beta sign up if you are interested.
Steffen thought it would be interesting if I shared some thoughts on switching from cocos2d-iphone to cocos2d-x. What’s it like? What things do I miss?