I wrote iCanSleep after I couldn’t find a tool that matched my requirements.
Both Caffeeine and InsomniaX rubbed me the wrong way – the former does not allow the display to sleep (WTF? Who would want that?) and the latter prevents sleeping altogether (WTF? I can set Energy Saver settings to “Never” myself, thank you).
To be fair: both tools have some merit, just not for me. Specifically InsomniaX has features for MacBook Pro users.
What I wanted was a tool with customizable “no sleep” duration, and not the 5-30 minutes, 1, 2 and 5 hour option of Caffeine, or none as with InsomniaX.
Continue reading »
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.
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.
In order to write Tiled’s TMX file format I needed to do exactly this: figure out how to compress data, encode it as a string, and write it to XML.
I wrote down what I learned from using zlib, base64 and xswi – XML Stream writer for iOS (a single Objective-C class) while writing KoboldTouch‘s TMX writer.
- How to compress and encode data with zlib and base64
- How to write XML on iOS with xswi (XML Stream Writer)
I was positively surprised how relatively painless zlib and base64 encoding worked (I expected the worst!) and how simple and effective xswi is for writing XML compared to any other XML library.
I’ll probably continue to add those articles to Essential Cocos2D rather than posting them on this blog. Confluence is just so much more convenient for writing technical documentation than WordPress.
Final word: Enjoy!
I added two additional Plans to KoboldTouch:
- NEW: 1-Month Support & Updates: $19.95
- 3-Months Support & Updates: $39.95 (same as before)
- NEW: 12-Months Support & Updates: $119.95 (4 quarters for the price of 3)
All plans are now non-recurring / not auto-renewing. No more subscription plans.
The 1-Month plan is for trying out KoboldTouch, or getting or updating it cheaply. Lowering the barrier of entry. I want to increase the user base to gather more feedback, requests and suggestions.
The 12-Month plan is for supporters and early adopters who are willing to invest into KoboldTouch while saving money in the long run.
Note: You can continue using and publishing apps built with KoboldTouch even after your support & updates plan has expired.
At this point KoboldTouch isn’t for everyone (yet). I decided to narrow the focus to the type of users I seem to have convinced and the type of users I like to work with and attract more. I summed it up like so:
KoboldTouch is a custom-built game engine for demanding iOS & Mac OS X developers.
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.
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 »
Continue reading »
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 »
Continue reading »