Can Flash games packed for iOS and other mobile devices achieve reasonable performance?

Question

I was thinking of developing a game in Flash, as a hobby/educational project.

However, I was hoping I could make it run on a smartphone, but a friend who develops in Flash says that in their experience things will move really slow on the likes of an iPad when the Flash packager is used. So slowly that you can't use it commercially for fast-moving games.

Has anyone else experienced this slowness? Is there a way around it or is the technology just not there yet?

Answer 1

I'm currently using Flash to prototype a game for iOS and performance is decent. It's nowhere near the speed of a native implementation and is also slower than flash running on the desktop. But that's what has to be expected...

The term "commercial" doesn't indicate how much load your game will put on the CPU. Also "fast-moving" isn't a problem if your logic is simple and you're not overly excessive with graphics and animations.

Since flash code all runs on the CPU (unless you make use of the new 3D APIs), you're limited to what the CPU at hand can offer and this is much less than any modern desktop CPU. If you design your game in a way that respects these constraints, I see no problem in a Flash game on a mobile device.

Answer 2

I use Flash to build game prototypes, and you can get some great performance out of the packager, but you have to be aware of certain things. First off, it might be tempting to think that an iOS device is just a slower version of a PC. You might think that if you make your code run fast on a desktop, then it'll run decently on iOS. And nothing could be further from the truth.

The biggest difference is on the desktop, when running flash, your actionscript is being JIT-compiled. Its being dynamically interpreted by the flash player and executed. When you are talking about flash, the actionscript is getting precompiled and executed. Its like the difference between optimizing Ruby vs C++. Understanding that your actionscript is going to be compiled down to the iOS instruction set and not interpreted on the fly means that performance bottlenecks and bugs will be different (sometimes very different) between deployment platforms.

A couple quick things that I've noticed:

• Instantiating objects is painful, and slower than you might think. If at all possible use an object pool to reuse existing objects.

• Combined with the last one, garbage collection is painful and non-deterministic.

• Events are slow. Every time you dispatch an event you have have create a new instance, and then flash has a lot of overhead to capture and bubble that event around. Prefer simple callbacks (or even function objects) for simple event rasing.

• Related to the last, only have one listener bound to Event.ENTER_FRAME. Have a centralized scene manager and takes care calling an update() method on children. It may sounds like you are reimplementing the native flash display stack (which you are), but like mentioned the last point you are incurring a lot of overhead.

• Prefer bitmaps over vectors. Vectors are drawn by the CPU, so every render frame the vector has to be redrawn... from scratch. Bitmaps (with the cacheAsBitmap property) can be differed to the GPU.

• Optimize your bitmaps for the device. If you are making an iPhone targeted game, dont make a character sprite sheet that is 256x256 pixels big if the character is only going to be 64x64 on the screen.

• Learn to use cacheAsBitmapMatrix. You can get a pretty decent performance boost using bitmaps and using this matrix for rotation and scaling over the simple rotation. scaleX and scaleY properties. In fact I would say, even if you aren't using cacheAsBitmapMatrix still prefer .transform.matrix for moving stuff around. If you are mathematically minded at all, then this will make your life so much easier.

• Understand how bitmaps, filters, and cacheAsBitmap works in flash. Understand how they effect memory usage.

• Prefer strongly typed variables over dynamically typed variables: var x:uint = 0. Also mark your classes as final if you aren't going to subclass it. There is a little performance boost for that.

• Get Flash Builder 4.5 Pro over Flash CS5.5. Flash Builder (even as an Eclipse plugin/extension) is way more suited for this style of development, and its memory and cpu profiler is one of the best, and well worth the investment.

• Lastly, watch this slideshow by grant skinner. Its probably one of the best over all references on ActionScript optimization. But pay close attention to the first few screens where he says "optimization without benchmarking is pointless". I cannot stress that enough. Learn to deploy your game and app to the device and get some instrumentation off of it. Benchmark it and see where you need to optimize before optimization.

But with all that said, iOS apps built by the flash compiler aren't inherently slow. But they are very different.

I haven't had a chance to get my hands on a flash 11 compiler for iOS, so I have no idea what the new molehill api will look like on an iOS device, or what other internal compiler optimization they have done between releases. But it will probably be an improvement.

Answer 3

Molehill is right around the corner... So until Flash Player 11 comes out as bummzack stated things will be very slow assuming what you are doing has a lot of moving parts. If you are making something rather simple, REALLY simple then you should be fine. Also there is always Elips Studio as well, they have emulated the Flex SDK so you can build your apps in their flavor of mxml and as3 and it compiles down to native code... So it runs very smooth and very fast! The SDK is free now and you will feel just like you were coding in Flash Builder.

Answer 4

You can develop small games in Flash that does not do much of processing and run it smoothly on your device. But since Flash utilises the CPU and not the GPU, you cannot expect much of fluidity in your app that uses lot of artwork and does a good amount of processing. But it looks like Flash Player 11, which is said to utilise the GPU, will do the trick of running such applications without a glitch.