I assume we’re all eagerly awaiting for cocos2 v1.0 and to be given a download link to click on. The year 2010 started so promising, with v0.9 going through beta during end of 2009 and beginning of 2010. This v0.9 never came out of beta but was re-labelled as v0.99 and released as final version in February 2010 (if I remember correctly, it was either due to the amount of changes or the closeness to v1.0 that it was labelled v0.99). At this point I was thinking that by the end of spring, at the very least, we’d have a final v1.0 of cocos2d.
But 8 months later we’ve just seen v0.99.5 beta 3 release but no v1.0 in sight yet. I’m growing impatient. I’m wondering what the holdup is? The version labels seem to grow longer and longer, as if the labels were trying to prove the point that you can still have an infinity between 0.99 and 1.0 - if you only add enough digits and other stuff after the decimal sign this could go on forever.
So, please, for the love of god, just label it v1.0 already and lets get on with regular 0.1 steps from then on!
Just out of curiosity, I made a quick spreadsheet and hacked the average time between updates in, and it told me that according to this year’s release schedule v0.99.7 will be released on December 24th, 2010 and v1.0 sometime May next year. If version number updates continued at this rate, don’t hold your breath for v1.1 before the second half of 2012.
It’s just a silly estimation based on average days between new versions and their respective version numbers, so don’t take this seriously, or the wrong way. I’m merely growing annoyed and concerned how cocos2d progress has not been reflected in the version numbers in all of 2010, and how version numbers have grown out of proportion and anything I can relate to. Not that it’s any of my concern, but I do believe that doesn’t do cocos2d a good service to continue to label new versions like “0.99.5 beta 3”, and it certainly doesn’t help to portray it in the right light if you compare it to the progress other engines have made over the same period of time - if only in version numbers.
It’s almost as if going “v1.0” meant that cocos2d would be losing its virginity, and that being a life-changing event it shouldn’t happen without about a year of dating, right?
Right?
Well, for what it’s worth, I would suggest taking on the pretty-much-standard versioning style: major version dot minor version dot bugfix/hotfix (non-breaking) releases dot build number. Then go back to the regular release cycle with about two months for each 0.1 step, regardless of what the major number is.
I mean, a major version number change should still introduce something awesome, or useful, or practical, or helpful - in that case just skip the remaining 0.5 or so ahead and bump the major version right away. Personally, if HD support is in and points instead of pixels (what a concept) then that would be it for me. That would be a good v1.0. Get it done and all the bugs fixed, and label it v1.0 so we can all start looking forward to more reasonably labelled releases. Really, it just doesn’t matter that much if you change the first frickin’ number from 0 to 1.
Personally, I would have preferred if cocos2d were now closing in on v2.0. That would be about the version we might be at if the rate from 0.5 through 0.8 had continued at the past update rate. And a v2.0 would be absolutely justified for cocos2d, and I suppose a lot of people would feel much better working with a v2.0 than the current unstable 0.99.5 beta 3.
I hope we won’t see this happening again when cocos2d tries to get pregnant, and labels itself something like “v1.98.7 beta 6 final alpha” around that time to reflect the process, or progress, or lack thereof, or hormone levels, or morning sickness intensity, or whatever.
It’s a frickin’ version number, that’s all that it is!
And it needs some serious increasing to catch up with its level of maturity. Think about what that means to how cocos2d is first perceived by an outsider.
Heck, Unity is now at v3.0, SIO2 is racing towards v2.0, Shiva is close to v1.9 and even the slow-to-release-updates iTorque has gotten to v1.4 by now. Cocos2d is still afraid to go even v1.0 and it’s a shame, because it hurts its reputation, it doesn’t do itself justice, it’s likely to be perceived as being behind the pack and it doesn’t look good in terms of actual progress being made, regardless of the actual work that’s been done this year.
Chapter 14 - Game Center
This chapter will revolve all around Apple’s Game Center technology. Especially peer to peer networking is very interesting. The idea is to create a small multiplayer room using the Isometric game built in Chapter 11.
I actually had to buy a new iPod Touch 4 to be able to test all the new features. I was blissfully unaware that the more exciting features aren’t available on my iPhone 3G. Darn, technology moves so fast.
Summary of working on Chapter 13 - Pinball Game
I think it’s an amazing game, and I’m happy that several commenters, Twitterers and people I know in real life (you know, those you can actually touch while you’re talking to them) mentioned a pinball game as a possible example. Come to think of it, a pinball game is just great! It’s almost a sandbox that you can add more stuff to it and experiment. And it allowed me to use VertexHelper, which I haven’t been able to mention in the previous chapter.
Also, I’m a big pinball fan. Well, I used to be a computer pinball game crack. Have I ever mentioned that I was a beta tester for Balls of Steels, the pinball game from Apogee/3D Realms? When the shareware table was officially released, the highscore I achieved held the #1 spot for roughly 6 months in the worldwide leaderboard. And I basically stopped playing this game session after about 12 consecutive hours, just because I didn’t see the end of it. I always had the extra balls maxed out and I was still on my first ball. I just got bored.
Anyhow, it was great fun to actually build a pinball table myself. I can now appreciate more than ever how complex it is to create these beasts, be it for real or as a computer simulation. My respect to all game developers who ever built a pinball game, most importantly: the developers of the Pinball Dreams/Fantasies/Illusions series created by DICE, the developer of Epic Pinball James Schmalz and of course the creators of the Balls of Steel game Wildfire Studios.
Of course, when you read this chapter you’ll learn more about the prismatic and revolute joints of Box2d as well as joint limits and motors, among many other things. I’m also excited to see some of the readers turn this baby into a really good pinball game. I admit, this version, it don’t look too good. But as it is, it’s fully functional and incredibly cool for the short time frame I had to develop it in.
Just a quick note: the single most requested respectively criticized part of my book was in Chapter 4 where I’m introducing the moving spiders. The @interface code was missing from the book as well as the line in the init method calling one of the new methods. These are added now, so the code works directly from the book. It should be in the next chapters & code update (but don’t ask me when, I don’t know either).
Thanks for letting me know about it, and in general for all the great feedback! What amazes me most is that there wasn’t a single person saying that the book isn’t good, or not good enough, or could be so much better if only … Normally one has to expect at least a certain percentage of responses to be less than happy, but no, every single one was positive, even those with criticism. And a few very overwhelmingly appreciative. I can’t say thank you enough for all of that praise, it’s been a great source of inspiration and motivation, especially at the times when I was super-busy and working 14-hour days for a week. Thank you! 
Amazon Book Reviews
I thought it’ll be great to see some of the cocos2d book reader reviews appearing on Amazon. If you’d like to write a review, I’d really appreciate it, because right now there are none. Here are the links to the cocos2d book for every Amazon store worldwide:
Amazon.com (United States)
Amazon.ca (Canada)
Amazon.co.uk (United Kingdom)
Amazon.de (Germany)
Amazon.fr (France)
Amazon.co.jp (Japan)
Please mention that you read the book in its Alpha form. I don’t want anyone to think that the reviews are hoaxed because they came in before the book came out. Not everyone may be aware of Apress’ alpha program, and pre-release reviews are often viewed with skepticism.
Btw, Amazon.com lists the book’s release date as December 30th. Right now that’s just a rough date, like I said earlier, the goal is to get the book out in time for Xmas. Hopefully even several weeks before Xmas.
Chapter 13 - Physics Game
After the introduction of the physics engines Box2d and Chipmunk, this chapter will focus on one physics engine in greater depth by making a physics game using Box2d.
What kind of game? If you have an idea real quick let me know, because I haven’t decided yet. I was thinking about a space game with gravity but also a bit like Pinball, or more like a Sandbox game with some optional goals. Or something else entirely. The only caveat is: it has to be do-able in less than a week while also writing the chapter and I should be able to illustrate some details about the physics engine! That’s no mean feat.
Summary of working on Chapter 12 - Physics Engines
I basically split this chapter in half and gave each of the two physics engines, Box2d and Chipmunk, a good treatment. Initially I started with the templates provided by cocos2d, just to get all the code together and not having to talk about setting up the Xcode project. I quickly realized that the application templates are inadequate, erroneous and outdated, probably because they have barely been maintained as both Box2d and Chipmunk matured. They seriously need a refresher, and I was thinking that maybe I’ll turn the two projects for this chapter into cocos2d application templates for physics engines, replacing the current ones and using my Xcode template project, so that I don’t need to go in and change them every time cocos2d gets an update.
Anyway, both physics engines got their treatment and I built the same project for both. So now you can actually compare them, side-by-side, be it performance or behavior or just plain coding style or number of lines.
Unfortunately, there’s a lot to talk about even for just doing the basics. I got both projects to the point of adding more boxes to the world, then adding rudimentary collision detection and a simple joint example with 4 bodies strung together. There wasn’t enough space for more. But I did foresee it which is why I planned in the Physics Game chapter as a follow-up. Let me know real quick if you have an idea for a simple physics game, or send me a link to an existing game on the App Store. Ideally within the next 24 hours.
My Opinion
I once again realized why some developers may be preferring Chipmunk because it is more “direct” and easier to pickup, as in you just add a new callback method and that’s that. I can see that but it’s very misleading. Chipmunk is making me cry by throwing all those one-letter e, u, i, f, m, p, etc. fields at me, so I’ll have to remember that u is for friction, for example. I’m not a machine! And because you can’t hide private fields in C those are exposed as well, adding to the confusion. I found myself having to look up a lot of things frequently in the Chipmunk manual. The bad thing is, it’s a manual, and not an API reference - but I keep having to use it like it were an API reference by using search a lot. Box2d provided a much cleaner API and both a manual and an API reference, which made it a lot less painful to figure things out, to look things up.
People’s arguments about which physics engine is better often runs along the lines of language, features, performance, memory footprint and what not. But if I have to choose, I’d say both are fairly complete and mature physics engines, so for me the choice is really about API design and documentation. And in that area, Box2d is the clear winner in my book. Of course, I kept a neutral tone writing the book, I don’t want to bias anyone because at the end of the day, the important thing is that you can make a great game with both engines, and not everyone is familiar with C++ and that’s a very daunting language to learn.
Coconut College is a new cocos2d Tutorial website that looks really promising. Right now there seem to be only 3 tutorials online but I really like the writing and the layout (albeit the layout is a bit too wide/big for my taste). Kudos to whoever made it. Don’t forget, you remain elusive until you add a “About me” page. Comments would also be nice. Hint, hint. 😉
WasabiSoft published a very insightful 3-part guide for supporting your App Store customers, and serving them right:
Support Series Part I: Top DON’Ts for your App Store support link
When TechnoKinetics mentioned on Twitter he was annoyed with cocos2d, I wanted to know why. It turns out it was the change away from NSMutableArray to CCArray in cocos2d which required him to update his codebase after he upgraded to the latest cocos2d version. He called it a “seemingly insignificant” change. At the time CCArray was introduced I didn’t think much about it but now I wondered, how significant or insignificant is it?
As far as I looked, there were only vague results published and the cocos2d forum thread ends with Pearapps asking for a performance test, so I believe there are no CCArray performance test results available. The conversation also lead me to this NSArray vs. C-Array performance comparison. To my dismay, it is comparing apples with oranges, as the NSArray had to wrap and unwrap the floating point values into NSNumber objects, so the results are terribly skewed in favor of the C-Array. Since this article was referred to in the CCArray cocos2d forum thread, it made me skeptical about the initial performance tests putting ccArray (the C implementation which is wrapped by CCArray, mind the case) at 3.7 times faster, or just plain text “very very faster”. I’m an engineer and not a believer, such “much faster” statements always make me very skeptical (how much is “very”?). I thought I should put in some time to generate some actual numbers.
Test Setup
I decided to take parts of Mehmet Akten‘s array test code (eg. measuring the time), then use all available array types in a way that is most common to cocos2d: storing pointers. I wanted to do a little more real-world-ish test. Internally cocos2d uses CCArray to store the children of a node, which are pointers. Without the boxing & unboxing of NSNumber we can better compare the results of how the individual array types perform. So I derived my own testing project to figure out how fast read access is between a C-Array, CCArray, NSMutableArray and NSArray by looping over each element in the array, retrieving the element (a CCLabel) and changing its tag property, just to give the loop something to do. I’m wary of the compiler possibly over-optimizing the loop if it doesn’t do anything. I’m also wary of any caches (whichever the iOS devices may or may not have) affecting the test, so I made sure that the item count (50,000) was large enough to not fit into any caches.
Code that is measured for for loops:
|
1 2 3 4 5 |
for(int i=0; i<NumItems; i++) { CCNode* node = [c2Array objectAtIndex:i]; node.tag = i; } |
Using fast enumeration:
|
1 2 3 4 5 |
int i = 0; for (CCNode* node in nsMutArray) { node.tag = i++; } |
Using CCARRAY_FOREACH fast enumeration:
|
1 2 3 4 5 6 |
int i = 0; CCNode* node; CCARRAY_FOREACH(c2Array, node) { node.tag = i++; } |
Sequential Read Performance
The results: a mere 10% read access performance increase for CCArray compared to NSMutableArray when using a for loop (2nd and 3rd column from the right in the chart below). And a tiny, negligible improvement when using the CCARRAY_FOREACH keyword compared to NS(Mutable)Array’s fast enumerator for(CCNode* node in array) to iterate over the array. Both these results are in the same ballpark with the C-Array, and I was pleasantly surprised to see the CCArray and NS(Mutable)Array all perform basically the same as the C-Array when using fast enumeration, with CCArray just a tiny fraction faster - exactly the same performance as a pure C-Array.
The test did also reveal an interesting effect I hadn’t expected: the NSArray’s read access performance without fast enumeration is noticeably slower than NSMutableArray. It really shouldn’t be slower, but NSArray consistently performed around 70% slower than NSMutableArray when using a for loop. I have no explanation for this anomaly. And with fast enumeration both are exactly the same speed-wise.
The Y axis is in milliseconds:
These results indicate that you do not need to use a C-Array over NSMutableArray or CCArray when the array is fixed in size and only read from. If you’re only concerned about access speed, and you use the fast enumerator respectively CCARRAY_FOREACH, you can use CCArray, NSArray, NSMutableArray and a C-Array interchangeably. The performance difference is indeed insignificant. There’s a lot of other things you can do to improve your game’s performance before you should start considering which type of array to use. But for a fixed-size array, NSArray is definetely the worst choice.
Things change of course if you need to store primitive data types like float, int, double. In that case, the C-Array will win hands down against its competitors because it doesn’t need to wrap primitive data types in a NSNumber object. But in the other cases, when you store actual pointers, by all means use the convenience collections available to you and benefit from bounds checks and a better interface to set, retrieve and iterate over objects. In this read access test, CCArray only has an advantage if you’re using a regular for loop to iterate over the elements (see the last 3 columns in the chart above). But at most it’s just 10% faster than NSMutableArray, that’s still negligible, especially if you consider the time spent running whatever code within the loop.
Add, Insert & Remove Performance
I also wanted to find out how much of an improvement CCArray is over NSMutableArray for adding and removing objects. It causes the array to expand or shrink as the number of objects increase and decrease, which creates an additional and sometimes significant overhead. That’s where CCArray should shine. Here’s the test setup:
Add object to end of array:
|
1 2 3 4 |
for(int i=0; i<NumItems; i++) { [nsMutArray addObject:label]; } |
Insert object at first position (shifting the remaining part of the array back by 1):
|
1 2 3 4 |
for(int i=0; i<NumItems; i++) { [nsMutArray insertObject:label atIndex:0]; } |
Remove last object:
|
1 2 3 4 |
for(int i=0; i<NumItems; i++) { [nsMutArray removeObjectAtIndex:NumItems - i - 1]; } |
Remove object at index 0 (first position):
|
1 2 3 4 |
for(int i=0; i<NumItems; i++) { [nsMutArray removeObjectAtIndex:0]; } |
The initial finding was promising, the CCArray is 40% to 50% faster than NSMutableArray for the addObject and removeObjectAtIndex:last operations (meaning: to add or remove and item at the last position in the array) on my iPhone 3G. On the iPad as native application, the difference is even more significant with CCArray being 8 times faster than NSMutableArray for the addObject operation, and 2.2 times faster for the removeAtIndex:last operation. That’s great news!
But then came the shock when I tried insertObject:AtIndex:0 and removeObjectAtIndex:0 … I thought my iPhone had locked up and crashed, but alas CCArray is just dead slow in these cases! And by dead slow I mean: broken. Over 200 times slower, even on the iPad. Unless I made a grave mistake in my test (which I don’t see), it’s very likely a bug in the CCArray implementation. Or a design flaw. In any case, something isn’t right when it takes CCArray 53 seconds to insert or remove an object at the first index when NSMutableArray only needs 0.2 seconds to perform the same operations. If you rely on the removeAtIndex and insertAtIndex methods you should refrain from using CCArray until this problem is fixed. As far as I can tell, cocos2d rarely uses these methods internally so this issue shouldn’t have a measurable impact on cocos2d’s overall performance.
Update: @manucorporat has already fixed this CCArray performance issue (within minutes!!), it should be integrated in a new cocos2d build soon. I’ll update the performance test results soon.
Update #2: Apparently the fix was not all encompassing. It was faster on the iPad but just about 8 times, but still at least 13 times slower than NSMutableArray. On my iPhone 3G the results were worse and went down to a factor of 360. It’s being worked on. Stay tuned.
Note that this diagram is not to scale! If it were, you wouldn’t be able to make out the blue bars for NSMutableArray!
All tests were done on an iPhone 3G running iOS 4.1 with a release build of cocos2d v0.99.5 beta. The results for iPad were only glanced at to check for relative differences, see text above. All results are in milliseconds, averaged over several runs (3-5) with an iteration count of 50,000. The read speed tests were run individually, not in sequence, because running all read speed tests in sequence caused slightly different results depending on the order in which the tests were run. For example, the slower speed of NSArray was less pronounced if the tests ran in sequence.
Feel free to download my ArraySpeedTest.zip project and try to reproduce the results. Only run the tests on a device and in release builds to get comparable numbers. Let me know if you find flaws in the test setup. I’m also interested to hear if the relative speeds vary on other devices.
The Alpha Book just got an update with 6 new chapters! And the first 5 chapters have been updated as well with a few corrections and minor changes.
Get the new Alpha Book Chapters here. You’ll have to login with your email address and password you got from the Alpha Book purchase. Then look for the cocos2d book in the list and click on “View Chapters” to download the updated chapters.
Thanks to @shadex and @mrad02 for making me aware of the new chapters via Twitter before I even got the Alpha Book notification email from Apress.
Alpha Book Q&A
If you haven’t purchased the Alpha Book yet, here’s a quick FAQ because I receive a lot of questions:
Q: Will there be more chapters available after this update?
A: Chapters 6-10 was the first update. I assume (can’t say for sure) that there will be another update with the remaining 5 chapters before the book goes to print. I’ll let you know when it happens.
Q: When will more of the book’s source code be released?
A: I don’t know but updates are coming. Please be patient, I’ll let you know.
Q: If I purchase the Alpha Book, will I get the final eBook for free?
A: Yes.
Q: If I purchase the print book, do I get the eBook as well?
A: Not that I know of.
You’ll find more Q&A at the Apress website.
Update:
Chapter 11 Isometric Tilemaps is now also available!
