Intro to AS3 Workers (Part 3): NAPE Physics + Starling!

In part 1 of this series we looked at the basic message protocol for AS3 Workers, and a simple hello world.
In part 2, we looked at an example of performing imageProcessing in a seperate thread.
In this final installment, I’ll show how you can run your Physics entirely on a seperate thread, and we’ll also throw in a little Starling to the mix as some icing on the cake
Here’s an example of what we’re making:


Note: If you can’t see the SWF, make sure you have downloaded Flash Player 11.4. Chrome user’s, don’t forget to disable the old version.
As a comparison, here’s an optimized Haxe Demo rendered in CPU mode with Physics done in the main thread:
http://deltaluca.me.uk/docnew/swf/StressPyramid.html
On most computers the single threaded test will struggle to reach >45fps. With the CPU completely maxed out. Even if you do manage to hit 60fps because you have a super fast CPU, you;re still totally maxed out, you would have no more room at all to do anything else in your game. Contrast that to the Worker implementation, where the main thread is doing virtually nothing on the CPU. It spends <1ms on de-serializing the data, and a couple more pushing a bunch of vertex's to Starling. It has so much free time it's taking a smoke break!

Overview

First a quick overview of how this will work:

• The Nape simulation will live entirely inside a Worker thread
• The Main Thread will make calls on the Worker Thread when it wants to add a new Physics Body
• Each frame, the Worker Thread will copy the position data of all bodies into a shared ByteArray
• The Main Thread will read the position data from the ByteArray, and use it to update the on-screen Sprites

We’ll start by looking at the document class, and the messages that it sends to the Worker. Then we’ll look at the Worker which contains the actual physics code.

Document Class

The first step is to setup our worker and some message channels so we can talk.
At this point you should be familiar with this boiler-plate code for a Worker-based application: [...]
Read more: Intro to AS3 Workers (Part 3): NAPE Physics + Starling!

Citrus Engine on Nape and physics performance improvement

Hi folks! Since my studies are over and my new portfolio online, I have time to focus on personal projects. Yep, it was time to contribute again to the Citrus Engine. I’ve worked 3 days at full time focusing on its big issue : mobile performances. I’m glad to say that now they are just an old memories!
6 months ago, I’ve made the CE compatible with Stage3D thanks to Starling and added some cool stuff. CitrusEngineV3 BETA 1 has been downloaded 3047 in 6 months, that’s not bad! However it didn’t see lots of Stage3D game, because it was missing the point : people wants to make mobile games.
You will find all the sources at the end.
Nape
Nape is Luca Deltodesco‘s open-source physics engine written in haXe with the help of his preprocessor caXe. It is written with AVM2 in mind for performance, and utilising another part of his build chain provides a seamless API between AS3 and haXe though it does compile with hxcpp with other targets unknown. The idea behind Nape is to provide a high-performance, powerful and moreover friendly and safe physics engine.
Nape is faster than Box2D, and easier to handle. Adding it in the CE wasn’t hard, and we use it the same way than Box2D. Using Box2D (Alchemy version) & Stage3D with Starling in the CE you must take a look on Adobe Flash Player Premium announcement if you are targetting Browser games. With Nape, you are no more related to the “premium features license” from Adobe.
Nape is ready to be use (no bug spotted!), however since I’m really new to Nape, there are some strange behavior whith NapePhysicsObject in the CE (you can see it in this demo). It’s not a problem for a performance test.
A NapeStarlingGameState Class exemple :
[...] Read more: Citrus Engine on Nape and physics performance improvement

Epic Flash memory leak track down

Have you ever had a memory instantiation problem that was impossible to track down? Here is a post that might help you with that kind of thing!

Beware! This post is very long… but VERY instructive! If you want to learn some internal mechanism of Flash, I strongly suggest you read it from top to bottom without skipping parts!:)

The Context

Yesterday I was helping Luca (creator of Nape physic engine, made with haXe) to find what seemed to be a big memory leak. There was a couple framework used so it could be directly from Nape… or from Starling… or from debug tool running… or from a port error from haXe…

So I though it was going to be simple

I got TheMiner running and started profiling. It was pretty easy to find a LOT of memory allocation coming from Starling. The SWC version available is over 4 months old and back then there was a lot of useless instantiation coming from TouchProcessor.as
If you use Starling, I suggest you build from sources as these instantiation are gone now.
There are a couple left but no big deal.

We also saw that Nape was using a LOT of anonymous function call and some try catch. This create what’s called activation-object. And there was a lot of these. So by removing anon-calls and try catch we were able to remove a lot of instanciation.

And After removing the debugging tools, It was clear it was coming from haXe or Nape.

But even when recording all samples allocated by the VM I could not find the damn allocation. (we are talking of more than 1Mo per sec)

Then I wrote a Scala script to try to identify samples that could have been missed, but that didn’t help me much since that was only an override of constructor and constructorProp avm opcodes.

Simplifying the context

So I decided to look a bit further into the bytecode and found something very interesting.

After simplifying the problem multiple time, I got this very simple code to demonstrate the bug.
Because Nape has that very nice abstraction layer, it can support both standard DisplayObject as well as Starling 3D DisplayObject.

The leak happens when Nape try to set the DisplayObject properties like .x, .y, .rotation, etc.
Let’s create a fake DisplayObject class and name it DO [...]

Read more: Epic Flash memory leak track down

Nape and Starling together? It’s possible!

Hey, friends!

Somebody of you already tried fastest 2D flash physics engine Nape with a GPU 2D rendering framework Starling together and noticed that Body.graphic property is class of flash.display.DisplayObject and it can’t be assigned to the starling.display.DisplayObject instance.

So, some of you just used Box2D, some of you controlled Starling DisplayObjects manually, maybe some did what I did, but keep it away from public, but I like Body.graphic property – it’s really useful and I wish all as3 developers can easily use fastest 2d physics engine with 2D GPU rendering engine.

Today I’m glad to present you modified Nape FP 10+ swcs (release and debug) of the Milestone 7.2 “r3″ (maybe not fully) compatible with the Starling.

I just replaced Body.graphic flash.display.DisplayObject class by the Dynamic class (* in as3) and removed Body.graphic.rotation radians to degrees conversion to make it compatible with Starling in my case.
Now I can use Nape as usual, with usual DisplayObjects, it’s really cool!
Yes, there are possible some more compatibility issues, but this changes was enough in my case and Nape worked with the Starling DisplayObjects fine.

Feel free to download and use this swcs with Starling Framework!
debug swc
release swc

I like a challenge with caxe and flib compiling on Windows in the MinGW I faced while recompiling swc, it was fun!
To get the working swcs on Windows, you should

Read more: Nape and Starling together? It’s possible!