Which Physics Engine for Flash and AIR apps?

I did a small comparison of the most common ways in which a Flash or an AIR developer makes use of a physics engine in a game.

The test involves creating 50 dynamic bodies with full bounce and dropping them in a walled enclosure and normal gravity. And this test was tried with the following 3 engines –

1. Box2D – The most updated and authentic source of AS3 port of Box2D
2. Box2D FlasCC-ed – FlasCC-ed version of native Box2D library
3. Nape – 2D Physics engine for AS3/Haxe

And here are the results –

Engine	MacbookPro (with DD*)	MacbookPro (without DD)	iPhone4 (with DD)	iPhone4 (without DD)
Box2D AS3	45 fps	60 fps	20 fps	42 fps
Box2D FlasCC-ed AS3	60 fps	60 fps	14 fps	30 fps
Nape	60 fps	60 fps	42 fps	58 fps

* DD stands for ‘DebugDraw’, which refers to drawing the physics bodies on every enter frame.

Making ByteArray faster

The actionscript bytecode generated by FlasCC (previously known as Alchemy) is generally more performant than what you could accomplish using the actionscript compiler. Apart from usage of better data types and instructions, one of the primary reasons behind this was the usage of domain memory by FlasCC, which result in faster read-writes in a memory buffer. Flash and AIR Runtimes already had support to understand these special memory opcodes to make use of the domain memory and result in faster memory access.

Starting AIR 3.6, the Actionscript compiler (ASC2) is also able to generate these fast memory opcodes directly from AS3 code (it was previously only available through FlasCC).

To make a bytearray faster, you just need to assign it to the domainmemory.

 ApplicationDomain.currentDomain.domainMemory = myByteArray; 

Is packaging Flascc-generated swf files slow with AIR iOS?

Flascc (earlier called Alchemy) is a tool to convert your native code into a swf file. If you try to package such a swf file into an iOS application (.ipa) using ADT, then the packaging time depends a lot on the optimizations that you used with Flascc. For instance, using “-O4” could increase the packaging time by more than 4 times against using “-O2”.

Let me show that using the 01_HelloWorld sample bundled with the Flascc SDK. The sample is a just single line hello world C code.

 #include
 int main(int argc, char **argv)
 {
     printf("Hello World\n");
 }
 

AIR SDK and Flash Builder 4.7

This has always been a topic of interest, and continues to be so. I know that we at Adobe could have handled this overlay stuff in a much better and a cleaner way, but until then, following could turn out to be handy.

Basically, Flash Builder 4.7 handles a Flex project and an Actionscript project in a completely different manner. The location of AIR SDK inside the Flash Builder, from where you get a new AIR SDK, and how you overlay that SDK in Flash Builder, all differ.

Welcome back…

Resuming my blog after a pretty long time.

Quite a number of things changed in the meantime. After being a part of Adobe AIR desktop team for 2 years, I now lead the AIR mobile engineering team and have been a part of it for more than 5 years. It’s been a pretty interesting and fun journey so far, with focus of Flash and AIR moving from a general purpose runtime to Gaming and Video. I keep coming across some of the most immersive and breath taking games created with AIR on iOS and Android on a daily basis, and it is highly gratifying.

And yes, I got blessed with a baby boy, who is now more than a year old. And am enjoying every single moment of parenthood 🙂

Ok, then. See you again, soon!