Here’s a sneaky peeky at some early gameplay of my forthcoming mobile game, Herd’em:
I knocked up a quick demo to show how you might create a Unity game, which uses either keyboard input, or the accelerometer of a mobile device, without having to change any code, include any third party libraries, or use conditional compilation. Continue reading Unity – automatically choosing key or accelerometer input
One of the most problematic constraints when developing applications for mobile or Set Top Box is video memory (AKA VRAM). You often will not have control over how much video memory is allocated to your application, or what the fallback behaviour is when your application uses too much. Continue reading Sneaky tricks for developing on small devices – Bitmap ‘folding’
I finally decided to relaunch one of my classic old Flash games as a mobile app. I picked Super Kickups since I think the game mechanic works nicely on a touchscreen – that, and someone once told me that it’s addictive as crack – which I take as a compliment. I’ve recently added a leaderboard and I’ll be adding various other features, such as pickups and achievements, in the near future.
I used Starling for the rendering and it runs smoothly at 60fps on both my shiny new HTC and my somewhat slower old Sony Xperia. It’d be good to know how it runs on a range of other devices – especially if anyone finds the performance slow.
Having just finished building the UI for the YouView set top box, I thought I’d share some of my insights into best practices when building applications for such resource constrained devices. The YouView UI is AIR based, written in AS3 and runs in Stagecraft 2, also known as ‘AIR for TV’. As the name suggests, AIR for TV is a special version of the Flash player for embedded systems, such as set top boxes. The first incarnation of the YouView UI (back when it was just codenamed ‘canvas’) was for Stagecraft version 1, which means coding in AS2 and suffering the abysmal performance that comes with running on AVM1 (ActionScript Virtual Machine 1).
Despite the delays and the need to code the UI from scratch in AS3, I think it was ultimately the right decision. Stagecraft 2 is a much better platform – Stagecraft 2.5.1 to be precise. It was a great opportunity to learn how to write optimal code and use hardware acceleration effectively on resource constrained devices. I’ll be doing some tutorials on this in the near future, but here’s the key points to observe when developing for such platforms:
- Limit the complexity of your display list heirarchy
This may sound obvious, but ensure you nest as few things as possible, keeping the display list as shallow as possible. Stagecraft needs to traverse through the display list, working out which areas of the screen to redraw. This is similar to how the desktop Flash Player handles redraws, but with some key differences to how it decides what needs redrawing, how it tackles moving display objects and how it delegates the work of updating the frame buffer – a subject for another time. Mostly importantly, if you’re developing for a resource constrained device (such as mobile or set top box), you’ll have very limited CPU power, even if the device’s GPU (graphics processing unit) affords you great hardware acceleration capabilities. So, before Stagecraft can delegate any work to hardware, it enumerates changes in the display list in software. Complex display list heirarchies are a headache for some of the low-powered CPUs found in mobiles and set top boxes and this’ll show up as rocketing CPU usage, low framerates and few spare ‘DoPlays’ in Stagecraft (spare work cycles). By keeping your display list shallow, with only the bare minimum of display objects on stage at any one time, you’ll be making life easier for Stagecraft by doing less work on the CPU – whether or not graphics are drawn in software or hardware.
- Benchmark everything
When building an application for a resource constrained device, you should be able to run each component in isolation, to assess its drain on CPU and system/video memory. There’s no point optimising the hell out of one component, when it’s actually another one that is the source of your performance bottleneck.
- Know thine hardware acceleration capabilities
There’s no point blindly using cacheAsBitmap and cacheAsBitmapMatrix everywhere, if it’s not going to speed things up on the target device. Worse still, too many cacheAsBitmaps and you may be just wasting valuable video memory, or causing unnecessary redraws (again, the subject of a future article). A lot of platforms will accelerate bitmaps, even if stretched, but not necessarily if flipped or rotated. Alpha on bitmaps (or anything cached as bitmap) will usually be accelerated too, but this is not necessarily the case with all colour transforms. Benchmarking any component you’re building will quickly tell you where you might have pushed it too far, but you should also have a way of verifying that a particular set of transforms is indeed hardware accelerated. Stagecraft provides this when using its –showblit command line parameter. I’ll be going into more detail about this in another post.
- Mind your memory
When using various hardware acceleration tricks, especially on resource constrained devices, video memory is at a premium and usually in limited supply. You will need to know the limits and have a way of seeing how much video memory your application is using at any one time – ensuring you dispose and dereference any bitmaps you’re finished with too. If your platform uses DirectFB for its rendering, as YouView does, the executable ‘dfdump’ can show you just where your video memory is going. This is something else I’ll get into in another article.
- Blit blit blit
This refers to blitting, where blocks of pixels are copied from one bitmap to another. This technique is used a lot in games, where graphics performance is critical, you should arm yourself with the basics of how old video games used blitting of multiple things to a single bitmap for performance and video memory efficiency.
I’ll probably go into more depth on each of these things in forthcoming posts. Stay tuned.
I just tried packaging a game, written in AS3, for my iPad, PlayBook and BlackBerry 10 Dev Alpha device – works pretty well!
Unlike the iPad, the BlackBerry PlayBook has rather poor international keyboard support, with no method for entering chinese characters. I like the way iOS achieves this, so went about building my own version in ActionScript. Continue reading Chinese Handwriting Recognition App
I had a conversation yesterday with a friend and colleague about how his company should standardise their development environment for all Flashers – be they contract or perm, junior to senior. Continue reading How the hell do I build this?