Mobile devices are becoming more and more powerful. However, not all your users will have high-end mobile devices, so you should keep a low-powered device handy for testing the performance of your games.
Here are 10 ways not usually mentioned on how to improve mobile Unity performance. The usual advice (use low-poly models, minimal lights, few effect, etc) is good. But if you still need need to increase performance, try these tricks: Continue reading Boosting Unity performance on mobile devices
One of the most problematic constraints when developing applications for resource constrained devices, such as mobile or Set Top Box is ‘video memory’.
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’
YouView is a Smart TV service in the UK, a spin-off of a BBC RnD project which runs on Set Top Boxes and certain Smart TVs. I worked on the core UI for years and thought I’d share some insights into best practices when building applications for such resource constrained devices.
It gets scary out there sometimes. During my freelance career I’ve worked at a lot of different companies and have seen such coding horrors as you cannot imagine. So I thought I’d start immortalising some of them – so that we can all learn better coding practices, by looking at the bad.
Starter for 10 – What’s wrong with this picture?
|
1 2 3 4 5 6 |
public function doSomething(stuff:String):void { var newPixels:BitmapData = new BitmapData(someUint, someUint, true, 0); someBlitUtil.blitStuffTo(newPixels, stuff); someBitmap.bitmapData = newPixels; } |
Did you spot the fubar? It’s not an obvious one. Continue reading CODING WRONGS – Where do I start with the bad?
I’d recently been playing around with packaging AIR for iOS, to run on my iPad. While the performance has been improved massively since CS5 Packager, it’s still not great in AIR 2.6. It seems that AIR 2.7 brings with it some great performance enhancements – though I’ll reserve judgement until I’ve tried it myself – check out the article and video here.
Well, it’s been a while. Having spent the last 8 months working on the YouView set top box platform, I’ve been so busy that I wasn’t even sure my site was still up. And now that I’ve dived headlong into the tricky world of embedded systems development, I wanted to starting playing with other platforms out there. The first two that recently caught my eye were Apple iOS (specifically the iPad) and the new Blackberry PlayBook.
I was keen to see what the application development process is like for these two platforms, especially for Flash Developers and how the two Big Tablets, iPad and PlayBook, measurement up as potential target platforms for the crazy ideas in my head that I’d want to build. So, I made the first steps at development for both.
iPad
Now that Adobe is ‘allowed’ to pursue iOS as a target platform for AIR, via its cross-compiler again, I went through the process of signing up as an iOS developer, jumping through the various other hoops and getting my first ‘hello world’ app onto my iPad. The whole process is a lot more complicated than it probably could be, but then, the same could be said of device development at YouView – this is the nature of such platforms, they are emerging technologies and, as such, are moving targets and simply not like the desktop machines we are all used to developing for. I have to say though, I’m impressed with the recent leaps in performance and functionality Adobe has made with AIR 2.6 for iOS – it leaves Packager in the dust.
PlayBook
Perhaps because the tool chain for PlayBook development feels more like developing for YouView, I was more comfortable with developing for the Playbook and managed to crack out a very simple app, getting in App World in a matter of a couple of days.
Now that I’ve stepped well outside the desktop comfort zone, I have been playing for a while with resource constrained device development, hardware acceleration of Flash content and developing an unhealthy obsession for writing clean, memory/rendering performance optimal code. I hope to bring some of this to projects for iOS and Playbook, as well as share what I’ve learned over the last year.
Here are a few simple tricks that may help the performance of your code/graphics intensive Flash movies. This is not an exhaustive list, by any means, rather some of the more effective performance tweaks to try out on your projects. There are the usual sensible coding tricks, like using local variables for oft-used references within functions, or planning your code loops carefully and breaking out of loops whenever feasible – but you should be doing these already. I’ll be adding to this post as and when I feel necessary, but will generally avoid the more granular tricks, such as bytecode optimisation. Some of those methods are too complex to explain in simple terms here and generally have a low effort-to-benefit ratio anyway:
Use scrollRect in conjunction with cacheAsBitmap. The cacheAsBitmap parameter of a movieclip can improve performance dramatically, but will cause problems if the render area of the movieclip gets too large (e.g. larger than 2880 in width or height), regardless of whether it is cropped by the viewable area of the Flash Player. The solution is to use scrollRect to constrain the rendering area to desired limits, in this example, the stage width/height:
|
1 2 3 |
import flash.geom.Rectangle; scrollRect = new Rectangle(0, 0, Stage.width, Stage.height); cacheAsBitmap = true; |
Create bitmap snapshots of complex movieclips. Where you may have a movieclip full of layered graphical effects that isn’t animated, you can save a lot of rendering time by creating a snapshot of the movie. Similar to the cacheAsBitmap parameter, but will improve performance further if your movieclip comprises many lines or alphas. The following function shows a quick and dirty way of duplicating a movieclip as a snapshot of the original:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
import flash.geom.*; function createSnapshot (base:MovieClip, mc:MovieClip):MovieClip { var bounds = mc.getBounds(base); var bmpWidth = bounds.xMax-bounds.xMin; var bmpHeight = bounds.yMax-bounds.yMin; var bmp1 = new BitmapData(bmpWidth, bmpHeight, true, 0x00000000); var snapshot = base.createEmptyMovieClip("snapshot"+base.getNextHighestDepth(), base.getNextHighestDepth()); snapshot._x = mc._x; snapshot._y = mc._y; var rect = new Rectangle(0, 0, bmpWidth, bmpHeight); var pos = new Point(0, 0); bmp1.draw(mc, new Matrix(mc._xscale/100, 0, 0, mc._yscale/100, mc._x-bounds.xMin, mc._y-bounds.yMin)); snapshot.attachBitmap(bmp1, 1, "auto", true); snapshot._x = bounds.xMin; snapshot._y = bounds.yMin; mc.unloadMovie(); return snapshot; } |
Use the opaque window mode trick – sparingly! Setting the wmode=opaque HTML parameter of your Flash object can improve rendering performance, but at a potential cost. Not only does it make the rendering order of movieclips and frames more ‘lazy’, but will effect keyboard interaction adversely in some browsers (especially FireFox). Use with caution.
I’ll be updating and tracking back to this post occasionally, so stay tuned…
