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 –
- Box2D – The most updated and authentic source of AS3 port of Box2D
- Box2D FlasCC-ed – FlasCC-ed version of native Box2D library
- Nape – 2D Physics engine for AS3/Haxe
And here are the results –
||MacbookPro (with DD*)
||MacbookPro (without DD)
||iPhone4 (with DD)
||iPhone4 (without DD)
|Box2D FlasCC-ed AS3
* DD stands for ‘DebugDraw’, which refers to drawing the physics bodies on every enter frame.
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;
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.
int main(int argc, char **argv)
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. Continue reading
Here is a pretty common scenario you could face while installing an AIR application. Let me tell you a few things that you could try to fix it.
Scenario: You try to install an application, say TweetDeck, and it fails.
1. Make sure that you have the latest runtime installed on your system. If not, use the following link
2. Are you installing the application from browser (using AIR’s seamless installation feature)? If yes, then please first remove the .macromedia folder from your home directory and then try again. Continue reading