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 »
While I did the year’s end reports on practically everything, I also ran the numbers on KoboldTouch.
Now that it’s been available for just over two months, I decided to make the $39.95 plan available for everyone which was previously only available to Learn Cocos2D 2 book owners. This plan replaces the $44.95 plan.
The “3-months only” plan is now also down from $44.95 to $39.95.
Please take the KoboldTouch survey. I highly appreciate your feedback, thank you!
With actual sales figures of the past two months I could see a clear pattern: Continue reading »
Here’s a quick tip on how to design your scenes so that they scale up to higher resolution displays. For example when your app runs on a widescreen iPhone / iPod touch or on an iPad. This article is not about Retina displays, which use the same coordinate system and merely display higher resolution images.
Design for the lowest supported resolution
First, design your game to the lowest device/window resolution that your app supports. In most cases this will be the 480×320 points used by the majority of iPhones.
Contrary to images, you always want to scale your designed screen layouts up and never down. This is because upscaled screens will always fit on the device’s display, with more or less additional spacing between the nodes. Downscaling however might cause screen elements to overlap, which is hard to fix if you don’t see the overlap in the resolution you design for.
It’s also easier to make manual changes to upscaled screen layouts than it is for downscaled screen layouts.
Calculate the scaling factor
By dividing the current device/window size with the resolution you designed for, you get the scaling factor by which you have to multiply positions. This is a simple wrapper you can use:
|
1 2 3 4 5 6 7 8 9 |
static CGSize designSize = {480, 320}; -(CGPoint) scalePoint:(CGPoint)point { CGSize winSize = [CCDirector sharedDirector].winSize; CGSize scaleFactor = CGSizeMake(winSize.width / designSize.width, winSize.height / designSize.height); return CGPointMake(point.x * scaleFactor.width, point.y * scaleFactor.height); } |
To make a node’s position resolution independent, use the position you would use for a 480×320 screen and scale it up:
|
1 2 |
// centers the sprite, regardless of window size sprite.position = [self scalePoint:CGPointMake(240, 160)]; |
This even works for autorotation. If you use NSNotificationCenter to receive orientation change events, you can use the scalePoint method with the current position to generate the node’s position after the rotation happened. You can try by simply changing the designSize to {320, 480} and setting the app’s default orientation to Portrait.
Caveats
Of course it’s entirely up to you what makes sense, which nodes can be scaled and which should not. For example squeezing a landscape app in portrait mode is possible, but it simply won’t make for a good user experience. However scaling HUD elements that should be aligned with one side of the screen so that they automatically stick to the side of the screen (ie widescreen iPhones, iPad) would be a huge timesaver.
If you update your node’s positions manually in order to move them, then you may have to also scale the amount by which the node moves. It’s easy to do by multiplying the movement vector with the same scale factor.
This won’t work well for actions, which may run faster (or sometimes even slower) depending on window size and aspect ratio. But it’ll work with actions nonetheless if you also apply the scale factor to the target position.
Another issue to watch out for is to accidentally scale up a position, and then scale it up again. This can happen if you’re not careful when updating more complex algorithms or dependencies where more than one method updates the node’s position. The best way to avoid that is to ignore scaling until just before the screen is drawn. You could override the draw or visit method (don’t forget to call super) and scale the position:
|
1 |
self.position = [self scalePoint:self.position]; |
After drawing is complete you could then reset the position back to its original by dividing by the scale factor. I’ll leave it up to you to add a convenience method for that. That would make the position scaling completely transparent to your app and you could simply consider all screens to be in the designed for resolution.
KoboldTouch
I will be adding a KTAutoscaleController to KoboldTouch soon to make this easier for KT users. This will be a really nice feature to have, and really easy to use:
|
1 2 3 4 5 6 7 |
KTAutoscaleController* autoscaleController = [KTAutoscaleController controller]; autoscaleController.designResolution = CGSizeMake(480.0f, 320.0f); [self addSubController:autoscaleController]; // autoscale this sprite's position depending on window size [autoscaleController autoscaleNode:sprite scaledProperties:KTAutoscalePropertyPosition]; |
Until next year, have an enjoyable year’s end!
I completed KoboldTouch v6.0 today. Time to let you know what changed and what will be coming for v6.1.
KoboldTouch v6.0 - Foundation
This version mostly included changes moving from Kobold2D to KoboldTouch. I had already removed superfluous libraries, so KT now only includes Cocos2D with CocosDenshion and the Cocos2D extensions project, the Kobold2D and KoboldTouch source code obviously and Box2D.
But there’s more of course:
Since I’ve started to offer KoboldTouch developers have been wondering what will happen to Kobold2D? I’ll answer these questions here.
Kobold2D Updates
When cocos2d 2.1 (stable) is released, I’ll update Kobold2D to include this latest cocos2d version. Same with any other cocos2d version that will be released in 2013. I won’t update to beta versions - sometimes they’re riddled with bugs, other times the next beta comes only a week or two later.
I’ll continue to support and update Kobold2D for as long as there’s interest in it but I’ll definitely focus my efforts on KoboldTouch now.
KoboldTouch “Lite”
Sometime in 2013 (probably not before Q2) I’ll release KoboldTouch “Lite” for free, with limited features and support. This Lite version will then take over as the successor of Kobold2D, while Kobold2D will remain available for some time.
KoboldTouch “Lite” will have the MVC framework but not much else. It will not include any additional features such as OS integration, better tilemap rendering, Box2D Objective-C wrappers and what not.
This ought to help developers get accustomed with the MVC framework.
Relaunch of www.kobold2d.com
Sooner or later I’ll relaunch the www.kobold2d.com website as www.koboldtouch.com. I’ll go for a simple look & feel (KISS), it will include the Kobold2D articles and I’m going to write all KoboldTouch documentation publicly.
For one this will make it easier for me to write and publish documentation. It should also help KoboldTouch’s popularity to reveal its documentation to both developers and search engines.
KoboldTouch compatibility with Kobold2D
KoboldTouch is not 100% compatible with Kobold2D, since I’ve already trimmed the less popular libraries from KoboldTouch: Chipmunk, Chipmunk Spacemanager, Cocos3D, ObjectAL, SneakyInput, iSimulate, AdMob. The remaining libraries are: cocos2d-iphone, cocos2d-iphone-extensions, CocosDenshion, Kobold2D, Box2, Lua and a few smaller additions (BitArray, LOG_EXPR, etc).
You should be able to port code that does not use one of these libraries with ease. Though without adapting to the MVC framework you lose a lot of the benefits of using KoboldTouch.
Custom Folders and Source Control
Issues regarding custom folders and source control usage come up frequently. I will alleviate those with KoboldTouch.
The project starter tool will be improved to support creating new projects in a custom folder, with or without copying the offline documentation to the new folder. The project upgrader tool will also work with custom folder locations.
The documentation accounts for most of the disk space usage of a Kobold2D/KoboldTouch project and should therefore not be included when you intend to manage this project with source control. Specifically if it’s an online repository with limited disk space. With the additional libraries stripped and documentation not included, a new KoboldTouch project weighs in at around 15 MB of disk space.
What will remain is that the installer will install to a fixed folder, since you will then be able to create new projects in any custom folder so there’s no real need for a custom folder location during installation.
There are plenty of issues with PackageMaker to overcome to support custom folder locations and I’d rather spend that time on other things. As was always the case, you can of course move the Kobold2D folder anywhere else after the installation completed - it’s just one click & drag operation in Finder.
Your question not answered here?
Let me know by writing a comment.
