Box2D Forums

Update: Box2DFlashAS3 1.4.3 released.
Example and download link can be found here:
http://box2dflash.sourceforge.net/


////////////////////////////////////////////////////////


Been working on this for a few days now,
I've managed to get it to compile and not crash, so I figured I'd make a thread for anyone interested (or able to help me make it run a bit better?).

Anyway, have a look:
http://skatehed.ho8.com/flash9/PhysTest.html
(5 iterations, 30 hertz)

Is it normal behavior for boxes that spawn near (inside aabb maybe?), or inside each other to not collide until they move apart?
Also, I copied the pair rendering code from the samples, and the lines are 'snapping' to every 0.5 units or something, any ideas what might be causing this, and if it might stem from a bug I've created somewhere?
edit: Indeed it was a bug I had created, fixed now though (but not re-uploaded).
http://skatehed.ho8.com/flash9/debug/PhysTest.html

There are a few areas that I can think of that could probably be optimized, but I hadn't used box2D before I started this port so any tips on areas to optimize would be appreciated.

I'm hoping I'll be able to get it to run better, so I can actually use it in a project. (:
Either way, it was heaps of fun working on (except the vector math without operator overloading :S ), and I learned heaps about Actionscript and c++ (Like how to emulate a c++ union with AS3 :P )

Cheers, let my know what you think.
-Matt

That's cool to see Box2D running in Flash!

Do you plan to support all the joint types and other features?

Your boxes should always collide when overlapped. You need to draw the contact points be sure if it is a bug or they are slow to resolve (b2_maxLinearCorrection). Are you using pixel units?

You have a lot of bodies for a Flash demo. Off hand I can't think of any simple thing to improve performance (besides using a larger time step / fewer iterations as you have already done). I do plan to make a performance pass, but not until the core engine is feature complete.

This site has another flash engine based on Box2D Lite. Perhaps you can exchange notes.

http://lab.polygonal.de/

Very cool, that's an awesome start, and put together very quickly, too! [especially considering that a C++->AS3 port is not exactly trivial!]

I'm in the middle of a Java port right now, and I think Java and ActionScript are pretty similar as regards object creation and all that - I'm also sorely missing operator overloading. As far as the boxes not colliding correctly when they spawn inside each other, one translation "gotcha" you might want to look out for (I still haven't gotten to the compile stage yet, so keep in mind that this is just off the top of my head) is that there are a lot of places in the Box2D code where = assignment is used, but what actually happens behind the scenes in C++ is that a copy of the object is made before assignment (if I recall correctly this happens by default unless you explicitly overload the equality operator). In Java, at least, assignment just points the reference at the assignee rather than making a copy first, more like pointer assignment in C, and I think AS does the same. Be very careful that you are explicitly copying the objects during assignment, otherwise you _might_ run into trouble, since what you'll end up with is two different objects holding references to the same object, fighting each other's changes. I can't think why exactly this would happen upon overlapping initialization or why it would make the objects not actually collide correctly, but assuming you did a straight textual port of the code, it's definitely at least something to check.

Speed-wise, I don't know how AS3 performs, but from the horrible old-days of Flash (before ActionScript became a Real Programming Language), simple things like inlining all your vector math by hand tended to help quite a bit, as well as watching out for any temporary object creation. This is the type of optimization that becomes less necessary over the years as the interpreters mature, but it still might be helpful for AS3, I'm not sure.

Any chance you're planning to release the code?

Erin:
All the code is ported, and I just went over the 1.2.1 source with a file compare tool, and made all the changes from 1.1.0 (I didn't realize you had made 2 releases in the time it took me to port 1.1.0 :P), so all the features are there (including the updated circle collisions now), they just need to be tested.

I eventually found that bug, it was a scope problem in flash where a variable declared inside a loop was replacing a variable outside the loop with the same name.
Glad that one's over. :P

You are right, probably a _lot_ more going on in one place than I will need in a game. I'm planning to go through all the vector math anyway and try to fix that up a bit. Currently each operator is replaced with a function that returns a reference to a new b2Vec2, which is horribly inefficient, but that was the easiest way to get it up and running without operator overloading. Some code will get a bit messy, but I think it will be worth it.

Motor Physics looks very impressive, definitely looking forward to it's release.

ewjordan:
Thanks for the tips.
The last bug I had was an object being set as a reference, rather than replacing the object itself, like you mentioned, that was incredibly painful to find :P.

I'll try to release the source as soon as I have tested all of the features, and fixed any more bugs I come across.

Best of luck with your Java port. (:

I've just come across another bug, something to do with objects leaving the world, I'll have to look in to that tomorrow and upload the .swf then.
For now though, here's an updated screenshot.



Cheers
-Matt

I'm currently going through the codebase and making optimizations where I can. Mostly I'm trying to speed up the vector/matrix math (Manually inlining most of it as ewjordan suggested).
So far it runs 2+ times faster than the first version I uploaded, and there's still a bit of optimization to do.

So I'm pretty happy with how it's turning out. (:

Try it here:
http://skatehed.ho8.com/flash9/121/PhysTest.html


I might make a test-bed to make sure all the features work as they should, then I guess I'll upload the source somewhere for anyone that wants it.

Thanks for such an awesome 2D physics engine Erin.
And thanks for making the codebase nice and easy to work with. (:

Cheers
-Matt

Edit: was just wondering how the pyramid stack from the demo's would go now that it runs better, and it actually does pretty well. :D
http://skatehed.ho8.com/flash9/pyramid/PhysTest.html
(Had to put it up to 10 iterations for stability)

Ok, now that is cool!

Thanks Erin. (:

Been playing around with a level builder type thing within flash, using components, which basically let you expose properties from a class to object instances on the stage.
So I can drag a 'PhysBox' from the library, scale it, rotate it, adjust the friction, density, etc. then drag a 'PhysRevoluteJoint' from the library, position it, link it to the box I created, set up the motor, set up the limits, etc and I'm done.

I made this in a few minutes using that method.
http://skatehed.ho8.com/flash9/ragdollLol.html
(Mouse to drag objects)
I had to have gaps in the joints because I don't have the updated version with the m_collideConnected fix yet, so sometimes limbs will get stuck between other limbs.
But I still thought it was pretty cool. (:

Oh, and I put some post-process bloom in for fun, so sorry if it runs worse than it should. (:

More if you're interested:
http://skatehed.ho8.com/flash9/dominoes.html
http://skatehed.ho8.com/flash9/bloomLol.html
http://skatehed.ho8.com/flash9/motionBlurLol.html (Doesn't have mouse input, updates physics and renders 4 times per frame, which is why it runs so slow :P )

Quick question on this - in our Java port, I'm having a problem getting box stacking to work. The result is reminding me a lot of what happens in Box2dLite when you turn warm-starting or accumulation off. The VerticalStack demo slips apart, and the Pyramid just kind of collapses in on itself.

Java and Flash are not too dissimilar to my knowledge as far as object references go (and that's been the major stumbling block so far in Java), so I was wondering, do you remember having to do anything particularly clever or special to get stacking to work right?

I checked out your project from sourceforge and had a bit of a look.

I don't actually know java, and I may be missing something, but I found that in the Evaluate() function in b2PolyContact, you have replaced:
with
Which I tried and it seemed to cause the exact problem with stacking that you mentioned.

Since not all of m0's properties are used, you can cut the copy down to something like this:



I checked the other areas I could think of, and you seem to have everything right.

Hope that helps.
-Matt

Awesome! Thanks for the advice, that absolutely fixed it, and things now stack perfectly! I've only programmed a little bit of Actionscript, but I had a good feeling that if we ran into a problem in Java you'd almost certainly have had the same thing happen in yours. It's always that nasty old reference versus value problem, showing up in different ways.

I remember running into roughly the same kind of bug in the b2BroadPhase - there's a memmove() call being used to shift an array around in CreateProxy(), and until I figured out how to properly handle it, no collisions happened at all. The obvious translation of memmove is System.arraycopy in Java, but that didn't do enough. The ultimate resolution looks odd in code - after the arraycopy I looped through each member and made it use the copy constructor on itself, which is downright bizarre because it seems like that would do nothing at all - but it ended up working because it essentially forced a deep copy of the array instead of a shallow one. It was extremely difficult to figure out that this was what was wrong, though.

So anyone that's working on a port into another language that doesn't use pointers, keep these things in mind - every time you hit a memmove or memcopy in the C++ code, you need to be very careful! Luckily Erin's code is quite clean, so these calls only show up when they are absolutely necessary. In retrospect, I suppose I should have realized that he never would have used them without actually needing to (if he could have gotten away with just setting a pointer, he would have).

- Eric