There are many Cocos2D + Storyboard tutorials, it’s about time to do another one that’s done right. Also, this one’s backwards: we’ll start with a Cocos2D template and then add Storyboards to it. The tutorial will work for existing Cocos2D projects to which you wish to add Storyboards, too!
I’ll show you how to add Storyboards to a Cocos2D v2.1 project, with ARC enabled of course. This approach will take a little more work, but the solution will be complete and you gain a fair understanding of how things work together. Plus two custom but reusable View and Navigation controller classes, and I’ll show you what changes you need to make to the AppDelegate.
The resulting project will work with iOS 5 and iOS 6 and autorotation. The navigation and cocos view controllers are separated, and you will be able to subclass them for code customizations as is customary in Cocoa. Cool? Cool, cool, cool!
As usual you can grab the example project (Cocos2D + Box2D + Storyboards with ARC enabled) from github. I’ll also be adding a Storyboards template project to KoboldTouch in the next update, and document what’s special about the KoboldTouch solution.
Oh, only one thing … this tutorial is part of Essential Cocos2D. Head on over and enjoy!
KoboldTouch v6.2 marks the third major milestone for KoboldTouch. It also marks the longest development cycle between two updates: exactly 30 days.
That’s 30 days packed with new features, improvements and bugfixes, there’s a new development blog for the work-in-progress “Angry Trains” starterkit and slowly but surely the documentation is coming together.
So let’s check out the exciting new features in KoboldTouch v6.2:
Objective-C Box2D Physics wrapper
The Objective-C wrapper for Box2D (aka “Boxjective2D”) is now in a state that I feel very comfortable with. And proud. It’s the only Box2D Objective-C wrapper that’s both fairly complete and supported and will be continuously improved. It’s also stable, super-slick and easy to use, highly efficient without compromising integrity (ie no @private vars) and you can always access the underlying Box2D objects.
The following Box2D components are wrapped in Objective-C classes, which is about 80% of the public API of Box2D (and I won’t stop there): Continue reading »
I am so very happy to … no, actually I’m relieved Kobold2D is working fine again with the latest Xcode 4.6, including iOS 6 autorotation fixes and the FIX_CATEGORY_BUG issue. Being happy is reserved for whenever I’ve added something nice to KoboldTouch.
Of course I updated cocos2d-iphone to version 2.1-rc0a (on first sight that version looks like being encoded in hexadecimal). Which meant I also had to update cocos2d-iphone-extension to whatever is the current development version – which must be somewhat above 0.21 but that’s hard to tell because there’s no reference of a version number anywhere.
Also updated Chipmunk (6.1.2) and obviously that had to be followed by updating Chimpunk (oh there it is again – my favorite typo today) SpaceManager v0.2.01.
Lastly Admob was playing hard to catch. And it has grown awfully huge, comes with several of Google’s other SDKs as well. Given the dwindling interest in ads by game developers I just pulled the plug and removed AdMob. You can still add it back in to your project according to Google’s instructions though.
That said, here’s the download link for Kobold2D v2.1. Here’s the link to the Release Notes.
I’ll make another update when cocos2d 2.1 is final. The next version is dated for “March” according to the Changelog, but that’s going to be another release candidate. I didn’t want to hold off on updating Kobold2D for the cocos2d 2.1 final version.
PS: There won’t be anymore updates to the Kobold2D v1.x branch.
When you embark on a project, the first thing a developer ought to do is to run some basic math. Especially if you already have some specs regarding the number and sizes of assets. Because otherwise you may end up trying hard to work around a memory related issue which perhaps even modern desktop computers would struggle with.
So today, I’ll do some math for you, the things you should consider before starting a project or adding one more of those big new shiny features to your app. Kind of like an addendum to my popular article about memory optimization and reducing bundle size.
How much wood texture would a woodchuck choke on if a woodchuck could choke on wood textures?
A texture is an in-memory representation of an image made up of individual pixels. Each pixel uses a certain amount of memory to represent its color. A texture’s memory size is therefore simply the product of width * height * sizeof(color).
Before I go any further, I like to stress it again: the size of an image file is much smaller than the size of the texture generated from the image. Don’t use image file sizes to make memory usage estimations.
Most common are 32-Bit and 16-Bit textures which use 4 and 2 Bytes respectively per pixel. A 4096×4096 image with 32-Bit color depth therefore uses 64 MB memory. Let that sink in for a moment …
At 16-Bit it only uses half of that, though without color dithering (TexturePacker does this for you) this might not look too good depending on the image.
This is pretty much what you’re stuck with unless you export textures as .pvr.ccz. Not only does this format load tremendously faster than PNG (not to speak of JPG which are unbearably slow to load in cocos2d), the .pvr.ccz format also reduces the texture memory size because the texture can stay compressed in memory.
It’s extremely difficult to estimate how much smaller a PVR texture’s memory footprint will be without actually giving it a try. But you can expect anywhere between 10% to 50% reduction.
To the non-power-of-two!
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 already blogged about scaling node positions with display resolution. This feature is now built into KoboldTouch. Time for a demonstration before I get back to work on an improved Tilemap renderer:
The cool thing about KoboldTouch autoscaling is that it works transparently. Your nodes will be positioned relative to the design resolution, for example 480×320. The nodes will continue to use the same position on any device! So you just develop these nodes’ positions and their movement as if they were always on a 480×320 device. It’s that simple.
It also works for movement of any kind, be it CCMove* actions or manually updating the position property every frame. Moving nodes continue to move seemlessly even when you rotate the device. Continue reading »
Loading ...
