Developer Diaries 3
December 6 by John for Red Conquest
Having just finished porting Blue Defense: Second Wave to Android, I realize there were so many things that I took for granted when developing Red Conquest for iDevices.
1) Access to system resources
On iOS, and Palm's PDK, you are allowed to allocate memory until the system is completely out of it. It's what I'm used to, as a c++ developer on Windows. However, on Android, you do not have the same freedom - the java (sorry, Dalvik) heap is limited to a scant 16mb on some devices! Newer devices have a 24 meg heap, but still - you have to bend over backwards to get your data into the native heap, where it is unlimited. This was the first major hurdle we had to cross in the port.
Basically, we were decompressing some large textures into memory for use in OpenGL, and in iOS we have a background loader that does this on separate threads. In Android, this would cause out-of-memory errors randomly! Why? Because sometimes, two large 1024x1024 images would decompress at the same time, each decompressing to 4mb plus whatever other data storage was needed for the process. After it's shunted off to OpenGL, it's off the java heap for good - but still, having to design a background texture loading solution around a 16mb limited working memory seems like something I'd have to deal with in the early 90s.
2) Quality Sound API
When developing Red Conquest, we thought nothing of pushing dozens of simultaneous sounds, pitch shifting them differently over time, and generally doing whatever we wanted thanks to OpenAL. Android sound management was generally not up to par, still, after several major iterations.
3) Speed!
On iDevices, even the lowly iPhone 2G and original iPod Touch put out decent 2D performance, and can process a ton of geometry relative to their meagre 400mhz processor. I think it's mostly because of native, statically-optimized code, instead of Android's Dalvik bytecode which is interpreted on the fly by the runtime (and don't get me started on the garbage collector!).
Basically, I get significantly better geometry processing performance from my original iPhone than I do from my Motorola Droid test device, which has a GPU in the same class as the 3rd generation iPod touches (iPhone 3GS class), and a processor rated at 528MHz (30% faster than original iPhone).
4) Multitouch
iPhones have had quite good multitouch from day 1. It seems it was their primary selling point - something nobody else had really done right before. In the Android world, multitouch is a mixed bag - the APIs required to do proper multitouch didn't exist until Android 2.0. Before then, it was a dual-touch or tri-touch sort of affair, both in the API and in the hardware. Now, some android devices that do support multitouch have strange hardware-related bugs (such as the Nexus One), where in some cases the Y coordinate of two multitouch events will be switched! This means that on some devices, proper multitouch is limited to pinch/zoom effects, and can't truly be relied on for core gameplay mechanics.
The multimove screen in Red Conquest would not have been feasible on early android devices, let me tell you. :(
5) Compatibility
I can kind of understand this one - some hardware just can't run the latest Android OS for any number of reasons. However, some devices can run it, but the carrier has chosen not to update to it, or hasn't gotten around to updating to it yet! Specifically for multitouch, OS 2.0 is required to have the proper APIs for it - but my friend Kats, for instance, has a Motorola Backflip capable of at least Android 2.1, but can't update because his carrier is stuck at the positively ancient Android 1.6.
All iOS devices are, for better or for worse, capable of running the latest iOS update.
Furthermore, the vast majority of bugs and development resources I need to make my games were available two major revisions ago, at OS 2.1 (after some audio bug fixes), while Android still has no mature and simple Audio api, and is hard to optimize for.
So there you have it - Red Conquest took forever to develop, but even then, it was a walk in the park compared to what it could have been. :p
1) Access to system resources
On iOS, and Palm's PDK, you are allowed to allocate memory until the system is completely out of it. It's what I'm used to, as a c++ developer on Windows. However, on Android, you do not have the same freedom - the java (sorry, Dalvik) heap is limited to a scant 16mb on some devices! Newer devices have a 24 meg heap, but still - you have to bend over backwards to get your data into the native heap, where it is unlimited. This was the first major hurdle we had to cross in the port.
Basically, we were decompressing some large textures into memory for use in OpenGL, and in iOS we have a background loader that does this on separate threads. In Android, this would cause out-of-memory errors randomly! Why? Because sometimes, two large 1024x1024 images would decompress at the same time, each decompressing to 4mb plus whatever other data storage was needed for the process. After it's shunted off to OpenGL, it's off the java heap for good - but still, having to design a background texture loading solution around a 16mb limited working memory seems like something I'd have to deal with in the early 90s.
2) Quality Sound API
When developing Red Conquest, we thought nothing of pushing dozens of simultaneous sounds, pitch shifting them differently over time, and generally doing whatever we wanted thanks to OpenAL. Android sound management was generally not up to par, still, after several major iterations.
3) Speed!
On iDevices, even the lowly iPhone 2G and original iPod Touch put out decent 2D performance, and can process a ton of geometry relative to their meagre 400mhz processor. I think it's mostly because of native, statically-optimized code, instead of Android's Dalvik bytecode which is interpreted on the fly by the runtime (and don't get me started on the garbage collector!).
Basically, I get significantly better geometry processing performance from my original iPhone than I do from my Motorola Droid test device, which has a GPU in the same class as the 3rd generation iPod touches (iPhone 3GS class), and a processor rated at 528MHz (30% faster than original iPhone).
4) Multitouch
iPhones have had quite good multitouch from day 1. It seems it was their primary selling point - something nobody else had really done right before. In the Android world, multitouch is a mixed bag - the APIs required to do proper multitouch didn't exist until Android 2.0. Before then, it was a dual-touch or tri-touch sort of affair, both in the API and in the hardware. Now, some android devices that do support multitouch have strange hardware-related bugs (such as the Nexus One), where in some cases the Y coordinate of two multitouch events will be switched! This means that on some devices, proper multitouch is limited to pinch/zoom effects, and can't truly be relied on for core gameplay mechanics.
The multimove screen in Red Conquest would not have been feasible on early android devices, let me tell you. :(
5) Compatibility
I can kind of understand this one - some hardware just can't run the latest Android OS for any number of reasons. However, some devices can run it, but the carrier has chosen not to update to it, or hasn't gotten around to updating to it yet! Specifically for multitouch, OS 2.0 is required to have the proper APIs for it - but my friend Kats, for instance, has a Motorola Backflip capable of at least Android 2.1, but can't update because his carrier is stuck at the positively ancient Android 1.6.
All iOS devices are, for better or for worse, capable of running the latest iOS update.
Furthermore, the vast majority of bugs and development resources I need to make my games were available two major revisions ago, at OS 2.1 (after some audio bug fixes), while Android still has no mature and simple Audio api, and is hard to optimize for.
So there you have it - Red Conquest took forever to develop, but even then, it was a walk in the park compared to what it could have been. :p
Copyright © 2009 Cat-In-A-Box. All rights reserved.