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.
It seems like a no-brainer to most computer-affiniados and gamers: eventually, all video games will be distributed online. The question is only, when?
To retailers this seems to be a whole different story. Most of them are in denial, as I can tell from occasionally reading retail game publishing magazines. They’ll be in for quite the surprise in about 10 years, when it will be obvious even to the blind-folded that boxed retail games will soon be a thing of the past. Alongside Blu-ray movies. It is inevitable, as video games and movies alike are moving towards their most natural distribution media format: instant digital home delivery.
Not only will this reduce inventory risks for publishers, it also cuts out the retail middle-man, allowing direct to consumer sales with full control over pricing and availability. With all the advantages of tracking each user’s usage and profile information for marketing purposes. At the same time conveniently disallowing or at least automating the consumer’s rights to re-sell or lend digital products or issue refunds. Neither Floppy Disks nor Optical Media have offered such compelling advantages to media producers.
But first, let’s consult the history of video game distribution before analyzing what it can tell us about the future. One thing I can say with conviction in advance: retail stores selling physical games and movies will be as commonplace in the 2030s as are Vinyl record stores today.
Detecting collisions on pixel-perfect boundaries is the holy grail of collision detection in 2D games. As such, it seems like the ideal, if not to say perfect, solution to collision detection in general. Yet, it’s also quite complicated and the straightforward solutions don’t perform very well until you start optimizing the code.
This first post focuses on creating a pixel mask by analyzing the raw image data, as proposed over 3 years ago by Ernesto Corvi. It’s the fastest solution if you want to test if a point collides with a pixel on an image, which also works for rotated and scaled sprites. However it does take some optimizing to speed up detecting collisions between a bounding box of a node and the pixel mask, or two pixel masks.
The alternative solution is to render the two colliding objects onto a CCRenderTexture, as developed by Dani and others on the Cocos2D forum. It is able to detect collisions of arbitrarily rotated and scaled sprites but can be expected to be noticeably slower than a pixel mask. I will discuss this solution in a future iDevBlogADay post.
The results will find their way into Kobold2D, to make the solutions readily available to all developers.
Cocos2D’s CCRenderTexture class is shrouded in mysteries. Part of it because it has a low-level aura to it, and most certainly because it simply works differently than most Cocos2D nodes. In this tutorial you’ll learn all about CCRenderTexture and what you can use it for.
The CCRenderTexture demo project will guide you through basic uses of CCRenderTexture with 6 examples, including taking a screenshot, drawing with your fingers and applying full-screen motion blur.
As a bonus I’ve also added an example for CCMutableTexture2D (aka CCTexture2DMutable) that shows how you can set pixels in a mutable texture.
- How to create a CCRenderTexture
- How to render nodes onto a CCRenderTexture
- How to draw OpenGL stuff on CCRenderTexture
- How to create sprites from a CCRenderTexture
- How to create screenshots with CCRenderTexture
- Drawing / Sketching with CCRenderTexture
- Fullscreen Motion-Blur with CCRenderTexture
- Set pixels with CCTexture2DMutable aka CCMutableTexture2D
- The CCRenderTexture demo project
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.
I have no doubt that automatic reference counting (ARC) is the next big leap forward for Objective-C since the introduction of Objective-C 2.0. ARC allows you to put the burden of memory management on the (Apple LLVM 3.0) compiler, and never think about retain, release and autorelease ever again.
Since many user’s first experiences with ARC will be trying to convert an existing app, they will learn the hard way that converting existing code to ARC is not a fire & forget operation. And since this is the Internet, there’s also a lot of assumptions, false statements and other myths revolving around ARC going around.
So here’s just about everything you need to know about ARC, and some ARC-mythbusting too.
- Development Requirements for ARC apps
- Minimum Deployment Targets for ARC apps
- Required Deployment Targets with zeroing weak references
- How to enable ARC in your project
- Compile errors after switching to LLVM 3.0
- Getting third party libraries to build with ARC
- Converting an existing app to ARC
- “Cannot Convert to Objective-C ARC”
- Fixing pointer types in C structs
- Fixing C/C++ pointer transfers with bridged casts
- Fixing NSAutoreleasePool with @autoreleasepool
- Methods you can’t call (or override) anymore
- You can still override -(void) dealloc {}
- Property naming restriction
- New Property keywords: strong and weak
- ARC forbids synthesizing a readonly property without ownership qualifier
- For experts: detecting at compile-time if ARC is enabled
- For experts: allow use of ARC keywords with ARC disabled
- Myth: ARC has not been proven reliable
- Myth: ARC takes away control over Memory Management
- ARC Reference Documentation
I haven’t been able to find a list of all Objective-C @ compiler directives in one place. We all know the keywords like @interface and @implementation but others like @dynamic and @encode are lesser known, and possibly even much less understood.
Although I know most of them already, I couldn’t shake the feeling that I may be missing a hidden gem. So I made an effort to document all the Objective-C @ compiler directives in one place.
