Nape and Starling together? It’s possible!

# post updated (see UPDATED #3)

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:
1. Compile caxe from sources (only once).
2. Compile flib from sources (only once).
3. Use caxe preprocessor on .cx sources to get haxe (.hx) sources (every swc compile).
4. Compile haxe sources into the swcs (every swc compile).

Nape sources updates too often, thus, I’ll not keep this swcs sync with them, moreover, maybe we will see the Starling support officially in some of next Nape updates!

UPDATED:
By the way, manual Starling DisplayObjects control is really simple. You could do it this way:

// somewhere in your code
var someBody:Body = new Body(BodyType.DYNAMIC, new Vec2());
someBody.userData = someStarlingSprite;

// in some loop, as example, in the loop where you call Space.step()
var len:uint = _napeSpace.bodies.length;
var i:uint;
var body:Body
var sprite:Sprite;

for (i = 0; i < len; i++ )
{
	body = _napeSpace.bodies.at(i);
	sprite = (body.userData as Sprite);
	sprite.x = body.position.x;
	sprite.y = body.position.y;
	// limiting angle to +-360 and converting 
	// degrees to the radians (Starling prefer radians for rotation)
	sprite.rotation = (body.rotation*180/Math.PI)%360; 
}

That’s it!
This approach a could be slower when positioning and rotating your Body.graphic right inside of Body instances, because you should iterate through all bodies and call a bunch of getters\methods each frame.
But it allows you to use the latest native Nape swc with any third-party rendering framework, as Starling, and it’s great!

UPDATED #2
Nape was updated and in it’s new version we can use Starling DisplayObjects like this:

//...
body.graphic = starling_display_object;
body.graphicUpdate = _updateGraphic;
//...
private function _updateGraphic(b:Body)
{
    b.graphic.x = b.position.x;
    b.graphic.y = b.position.y;
    b.graphic.rotation = b.rotation; //keep radians since that's what starling uses.
}

Lee Brimelow recently created a new tutorial “Starling Physics Using Nape” where he demonstrates this approach on the sample project. Thanks, Lee!

Thanks to the Nape author, Luca Deltodesco!

UPDATED #3
Due to found bug in Flash Player Runtime (http://jpauclair.net/2012/02/25/epic-memory-track-down/), it’s strongly recommended to rewrite _updateGraphic this way:

//...
body.graphic = starling_display_object;
body.graphicUpdate = _updateGraphic;
//...
private function _updateGraphic(b:Body)
{
    var gr:DisplayObject = b.graphic;
    gr.x = b.position.x;
    gr.y = b.position.y;
    gr.rotation = b.rotation; //keep radians since that's what starling uses.
}

It will keep you safe from that bug and don’t let your memory to be exploded.

Found a typo? Please, highlight it and press Shift + Enter or click here to inform me!

Share Button

Comments

Nape and Starling together? It’s possible! — 13 Comments

      • I’ve already found solution. They did it in the same way as Box2D does:
        body.userData.view = image; //some display object, starling or not it doesn’t matter
        And in the update world loop:

        private function loop(e:starling.events.Event):void
        {
           space.step(1 / 60);
           space.liveBodies.foreach(updateGraphic);			
        }
        

        And function updateGraphic:

        private function updateGraphic(obj:Body):void
        {
        			if (obj.userData.view)
        	{
        	  var graf:starling.display.DisplayObject = obj.userData.view as starling.display.DisplayObject;
        				graf.x = obj.position.x;
        				graf.y = obj.position.y;
        				graf.rotation = obj.rotation;
        	}
        		
        }
        

        And btw, thanks for very useful blog))

    • I’m not sure about qbox2d, didn’t tried it with Starling yet. And I think I’ll not – Nape beats qb2d in performance and I’m not sure about the future of Alchemy-based projects.

  1. Pingback: leebrimelow.com » New tutorial on Starling physics using Nape

Feel free to print your thoughts on topic below

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">