Box2D Forums

Hey - nice, runs ok (all things considered).

I always wondered if it is real time. I downloaded the Windows version of the demos and the small version of the domino stack runs at about 40% cpu on my 1.8Ghz single core laptop so no reason why not...

I think the reason Chipmunk is so fast is the spacial hashing method - Eric, any thoughts on this vs the broadphase in Box2D?

Cool stuff rje/ewjordan.

I've finished porting the code for 1.4.3, just got to do some more examples and make sure it works in Flex.
Also, for this release I'm trying to get rid of the m_physScale variable by using pixel units, I've had to increase the gravity and all other forces dramatically and it seems to function ok now, is there anything else I need to change aside from b2_lengthUnitsPerMeter?

Thanks
-Matt

In another post someone mentioned they had to adjust
b2_velocityThreshold since that's in m/s
Mike

I won't be optimizing Box2D until it is mostly feature complete and stabilized. That said, the broad-phase in Box2D uses an algorithm similar to many commercial engines.

Re: the broadphase, I've tried spatial hashing before, and it has two things going for it over SAP: it's simpler to code, and you can achieve faster asymptotic running time for additions and deletions. The simplicity is not really an issue here, because Erin has done all the hard work for you. The addition speed is probably not such an issue in the C++, because the asymptotic O(N) addition cost in SAP ends up being handled by a fast memory copy. It's more of a problem in Java, because the copy has to happen manually (System.arraycopy makes shallow copies, but deep ones are needed, and any cache coherence that you would hope to exploit by having the objects arranged in memory is potentially lost because Java just allocates everything to the heap, so an array of objects could be scattered all over memory, though a good JVM will not do this). In other words, in C++ the O(N) probably has such a low constant that it doesn't matter much, but in Java or AS3 that constant is likely much higher.

So in theory, a spatial hash might be quicker sometimes, particularly in a pseudo-interpreted language. But in my experience, I've never seen a huge difference, and spatial hashing makes you pick a single length scale, which is a serious con if you use many differently sized objects. Might be interesting to code up a spatial hash for Box2D and test them back to back, you could probably start with Chipmunk's and tweak the interface to make it match up, though I don't know Chipmunk too well.

Anyhow, in the domino stack the bottleneck seems to be the polygon collision test (and to some extent, the drawing, which Java is not so good at), not the broadphase. At some point I'll get this running in C++ to see how fast it can go - anyone that wants to beat me to it, be aware you need to alter some of the b2_max* constants to let you create more stuff, I couldn't get a stack 20 high with the defaults.

Sorry about the delay, Box2DFlash 1.4.3 has been done for a few days now, but I've been too busy to do the extra examples I wanted to include before releasing it.

So I've uploaded the source (without new examples) here. http://skatehed.ho8.com/flash9/143/Box2DFlashAS3_1.4.3.rar
(The package has been renamed from 'Engine' to 'Box2D', so you might have to do some find-replace 'Engine.' with 'Box2D.' on any code you had previously written)
Also note that it has been switched over to pixel units, so two of the examples are messed up, and you might have to make some changes to your own code if you want to use pixel units (or b2Settings.as to switch it back to meters).
Let me know if you have any trouble with it.

The 'Example' demo has been replaced by Seymour's example which exhibited a bug under 1.4.2 that has now been fixed (Great work Erin!).
http://skatehed.ho8.com/flash9/143/PhysTest.html

The official release will still be coming fairly soon, but I figure most of you don't need the new examples.

Cheers,
-Matt

Great work with the Box2D flash conversion!

I have two questions:
1. Is there an API?
2. Are there functions and examples for connecting DisplayObjects (e.g. BitMaps)?

For example in the Fisix Engine (http://www.fisixengine.com/) they have:
- newConstraintAttacher(mc:DisplayObject)
- newDisplayAttacher(mc:DisplayObject)
- newParticleAttacher(mc:DisplayObject)
- newSurfaceAttacher(mc:DisplayObject)
- newWheelAttacher(mc:DisplayObject).

Shapes and Bodies have an m_userData property that you can use to attach Objects. I use it to attach MovieClips. Box2D doesn't have any built in rendering engine so when you loop over your shapes to render them, just grab the m_userData prop and adjust the position and rotation to match your Shape.

Thanks for the information! It's a shame that there is no standard API and convention for attaching DisplayObjects and other common tasks. Has anyone made an AS3 wrapper that would accomplish this?

IMHO, this is the way it should be, it's a physics engine, not a rendering engine. For a physics engine developed in AS3, I can understand binding the two together, there's just not that many ways to render stuff to the screen, but this is ported from C++, where a built-in rendering engine would be too restrictive.

If you make yourself a base class that has a reference to the box2d shape and a draw method, this should become pretty core to your app.

myShape.m_userData = new Actor(shape);

then your shape has a reference to your movieclip and your movieclip has a reference to the shape