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 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:
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.
