Box2DFlash 2.1 Progress - Updated 20090930

Discuss issues specific to the Flash/AS3 port of Box2D
BorisTheBrave
Posts: 1911
Joined: Mon Jan 07, 2008 10:51 am
Contact:

Box2DFlash 2.1 Progress - Updated 20090930

Postby BorisTheBrave » Sun Aug 30, 2009 9:06 am

Latest official post

Quick bulletin that I'm working on porting Erin's recent changes to Box2D, which will eventually become the bulk of 2.1. It's a pretty big job, which I'm doing at once, so there'll be nothing compilable for a while. I've done maybe 10%.

I have a few changes planned for 2.1 beyond mirroring the C++. Box2DFlashAS3 will be breaking compatibility with the C++ and backwards compatibility in both API and implementation. These changes will be put in place after porting is largely complete.
  • The API will be changed to AS3 coding conventions. No b2- prefixes (namespaces are good enough), and lowerCamelCase instead of UpperCamelCase. The b2Vec class will be scourged of inconsistent methods, though letter-style overloading will remain (e.g. b2MulX vs b2MulMV).
  • The API will reflect AS3 idioms better. Get/set properties will be available in addition to the method style. Fixed sized arrays will be reduced in prominence. Function callbacks will be available for some methods. Definitions objects will become optional.
  • The source will transition to using Vector.<> rather than Array internally. A release using Array will be provided using a sed script, but the HEAD version won't be.
  • Broadphases will be swappable. There'll be two implementations initially: the old SAP, and the new Dynamic tree one. This is mainly because I'm curious as the performance difference.
  • Possibly will keep the edge shape as a distinct shape type from polygon (they are being merged in the C++). I think the connectivity information will come in handy for various reasons (such as ensuring leakproof raycasting).
  • Performance will suffer. Box2DFlashAS3 has extensive inlining, and I do not have time to recreate all this for the new code. This might for the basis for a later project, along with RVO.

Between these changes, and the C++ API changes, this release will be fairly non-backwards compatible. I would recommend upgrading existing projects only for devoted users. Just to spell it out, here is a small sample of how the differences might be.

2.0:

Code: Select all

var bd:b2BodyDef = new b2BodyDef();
var body:b2Body = myWorld.CreateBody(bd);
var cd:b2CircleDef = new b2CircleDef();
cd.radius = 5;
cd.density = 1;
cd.restitution = 0.5;
body.CreateShape(cd);
body.SetMassFromShapes();

2.1:

Code: Select all

var body:Body = myWorld.createBody();
var f:Fixture = body.createFixture2(Circle.create(5), 1);
f.restitution = 0.5;
body.setMassFromShapes();

This is ALL PLANS. Meaning, it's open to negotiation, and I have no guarantees that I'll get round to everything. I'm particularly keen to hear the Java porter's opinions.

How can you help? Uh, well atm you cannot, unless you are willing to port a file or two, and you have both good C++ and AS3. I'll let you know later - I'll need a new TestBed formed, and then debuggers to unearth why the new TestBed doesn't work.

mayobutter
Posts: 915
Joined: Fri Dec 14, 2007 8:07 pm
Contact:

Re: Box2DFlash 2.1 Progress

Postby mayobutter » Sun Aug 30, 2009 11:03 am

I'm just chiming in here to let you know I'm also working on a port, based off of Adobe Alchemy. Progress has been slow (since I've got a full time job) but I've got the majority of features working. Here's a demo:

http://www.sideroller.com/demo/demo.html

This is using the latest SVN C++ version of Box2D. The third demo is a "stress test" that demonstrates the performance is very good. I plan on releasing the code once I've got the contact callback system working properly.

I don't mean to hijack your thread. There's probably still advantages to porting a native AS3 version, but porting has got to be a pain :P

BorisTheBrave
Posts: 1911
Joined: Mon Jan 07, 2008 10:51 am
Contact:

Re: Box2DFlash 2.1 Progress

Postby BorisTheBrave » Sun Aug 30, 2009 1:44 pm

Ah, that's cool, I hadn't realized anyone had managed to get that to work. What does "based on" mean, I thought it was pretty much an all or nothing affair?

I'm really interested in the performance. If Alchemy turns out to be significantly faster, including API costs, then I'd probably drop doing a native port all together. I'm really not familiar with Alchemy, but I cannot see what advantages there would be to a native port, beyond hacking it up. Anyone?

But I cannot really tell performance from your demo. Do you think you could arrange for something more objective? Like the same demo, with no graphics, fixed timestep, set up for both systems? Though it'll still be comparing 2.1alpha with 2.0.

And yes, porting is an immeasurable pain. The value-type thing vs reference type makes it very difficult to avoid subtle bugs, and lack of operator overloading means many lines need rewriting so it goes very slowly.

mayobutter
Posts: 915
Joined: Fri Dec 14, 2007 8:07 pm
Contact:

Re: Box2DFlash 2.1 Progress

Postby mayobutter » Sun Aug 30, 2009 5:26 pm

For each b2Body, b2Shape, etc. there's an AS3 equivalent class that keeps a pointer to the C++ version. From what I've read, performance in Alchemy is very good as long as these functions are avoided as much as possible. So instead of calling C++ getter / setter functions, the AS3 classes instead implement getters and setters that read directly from the C++ memory block (which is fast). So for example, getting the position of each body for placement doesn't have much overhead. Creating a new body does, however, because it must invoke C++ code.

Any performance gains I've seen are completely subjective and based on my experience with the library. Not very scientific :). I'll see if I can get some code finally posted next weekend.

BorisTheBrave
Posts: 1911
Joined: Mon Jan 07, 2008 10:51 am
Contact:

Re: Box2DFlash 2.1 Progress

Postby BorisTheBrave » Mon Aug 31, 2009 1:53 am

Yes, this is why we'll need some tests other than just running a simulation, which is Alchemy's strongest suit. Many people call SetXForm every frame, and events which call to user code, so you make it sound like those could make a serious difference. Perhaps a better cutoff would be just the solver unit, as that has explicit copying of data to and fro anyway.

Anyway, looking forward to some code.

shaktool
Posts: 434
Joined: Sun Jan 20, 2008 7:52 pm
Contact:

Re: Box2DFlash 2.1 Progress

Postby shaktool » Mon Aug 31, 2009 10:17 pm

Ah, hello, it's been a while. ;) Your blog post popped up in my aggregator.

That all sounds awesome, except I'd like to see maybe a link to a rationalization for why edge chains were removed? I don't really know how the C++ version works any more, but if it's harder to build interior environments now I will be (predictably) annoyed.

While we're making the API user-friendly, any reason why we would still need to explicitly call "setMassFromShapes()"? Maybe that should just be the default thing to do. And in order to avoid recalculating the mass every time a new shape is added, just recalculate it the next time the mass is requested.

BorisTheBrave
Posts: 1911
Joined: Mon Jan 07, 2008 10:51 am
Contact:

Re: Box2DFlash 2.1 Progress

Postby BorisTheBrave » Tue Sep 01, 2009 12:42 pm

Good to hear from you shaktool. Though I see you fairly enough on TiGSource.
You'd have to ask Erin why edge shapes are being removed, he's consolidated the C++ version so I have less input now (not that I ever had much). The gist of it is that they are now redundant - now that core shapes have been eliminated (shapes now pop 'out', not 'in', similar to Bullet), you can simply make two vertex polygons. And it's only removing them as a base shape - there will still likely eventually be a b2EdgeChainDef constructor, as it's pretty convenient. So no, it should be no harder to build interiors. And it gives double edged edges, which people asked for with almost as much frequency as true one way edges.

I fancy keeping them as for a) the connectivity (and direction) information, b) in case I want to expand to circle segments (as the solid arcs I used to do are just too much work to fit into the new framework).

I suppose we could do that for setMassFromShapes, but most of the internal uses read the private variable for speed, preventing a lazy instantiation. Could check a flag at the start of Step, though... Every extra line shaved off creating a simple circle is a major gain, imho, so will thing about it.
I was actually considering the more radical step of using (what I think is) Java-style construction - you are free to manipulate the objects independant of their attachment to the world. (i.e. Create/Destroy methods, become Add/Remove, and you are responsible for invoking the constructors yourself). Then SetMassFromShapes could be called during Adding. But it's very contrary to the Box2D Way, and ultimately doesn't gain you massive amounts, and breaks down when you try to do joints the same way (can something be "half in" the world?)

Erin Catto
Site Admin
Posts: 2948
Joined: Thu Sep 06, 2007 12:34 am

Re: Box2DFlash 2.1 Progress

Postby Erin Catto » Tue Sep 01, 2009 4:32 pm

In my experience edge connectivity information is only useful for co-linear edges. In that case the edges should be merged.

There is no limitation in using 2-vertex polygons that I know of. There is some wasted memory, but I think that can be improved.

shaktool
Posts: 434
Joined: Sun Jan 20, 2008 7:52 pm
Contact:

Re: Box2DFlash 2.1 Progress

Postby shaktool » Tue Sep 01, 2009 4:57 pm

Shapes that pop "out" instead of "in" do remove a lot of the need for edge chain connectivity... in the context of physics simulation. It's still helpful for stuff like Geemer AI, but I guess that's a special case that I could hack around if needed.
(Geemers basically cling and crawl along a structure without relying on gravity or other forces to stay in contact)
http://www.youtube.com/watch?v=zbyXW4hbUOM

Erin Catto
Site Admin
Posts: 2948
Joined: Thu Sep 06, 2007 12:34 am

Re: Box2DFlash 2.1 Progress

Postby Erin Catto » Tue Sep 01, 2009 5:53 pm

Game specific stuff can be hooked into fixture user data.


Return to “Flash”



Who is online

Users browsing this forum: No registered users and 2 guests