Ams.js vs Box2d Benchmarks. strange finding

Sorry, what I meant was Collision Disabling with asm.js is not supported on Intel XDK yet. I exported my mobile game with Intel XDK build and when I tested APK I was wondering why my game was messed up. My character would freeze and game was unplayable. Took me a good while to figure out that Intel XDK doesn't support collision disabling yet with asm.js so I had to switch back to Box2dweb and everyone was fixed. Gonna have to wait for next update of Intel XDK maybe.

@delaflaquita - that is super interesting. I wouldn't think that it would matter if you exported on intel xdk. Good to know, because I have been using that as of late.

In my mini-game it seems that Box 2d does micro-stutters after about 2 minutes adding and destroying objects. Chipmunk on the other hand never seems to get this way. I let the simulation run while i cooked dinner and came back to it preforming as good as when i left it.

Changed back to ASM box 2d and the micro stutters where back.

Think I am going to experement more with this later. I amvery impressed with Chipmunk so far.

@jojoe , that is good to know. I've noticed the micro-stutters with box2d as well when objects added/destroyed.

[Ashley]

I'd point out that the performance of Box2D physics is significantly determined by the number of velocity and position iterations, which currently default to 8 velocity iterations and 3 position iterations. This is the tradeoff between CPU work and physics accuracy. Comparing it to another physics engine is difficult, because it could use a default equivalent to say 4 & 2 iterations, making it less accurate but less CPU intensive. You can probably turn down the iteration count until Box2D is faster than another engine, but then the accuracy of the physics simulation suffers, and it is probably difficult to compare the accuracy of two different physics engines.

Further the C2 physics engine has features that involve adding callbacks to the physics engine which probably have a small performance impact - disable collisions requires collision callbacks, and the physics engine is also able to fire normal 'On collision' events upon physics collisions (which wouldn't otherwise happen). If another physics engine does not support these features, it has an unfair performance advantage since it does not have to do the same work.

We have a benchmark (based around circle collision shapes, which I think makes the difference) which clearly shows asm.js physics is about 3x faster than box2dweb in that case. So even if in other cases asm.js is about the same, if sometimes it's that much faster, it's definitely worth having.

We aim by the next stable release to have asm.js physics as the default.

@jojoe - do you notice those stutters only in asm.js or is it in box2d web as well?

@Ashley - In your benchmarks, do you use gravity? I am just curious. I like box2d over chipmunk, because it seems more stable to me. I used circles bouncing around and added them manually until cpu was where I wanted it. Now that you mentioned iterations, that is definitely something to consider. chipmunk handled more circles in the test but the physics simulation brokedown (I was losing energy in the spheres over time which isn't right).

[Ashley]

Yes, it was just a big bucket which I filled with circle collision sprites (with gravity so they all fall down). A clear 3x difference in the object count, far higher with asm.js physics. Which makes sense since it's practically a native compilation anyway.

@ruskul

It was Box2D, with and without asm.

I was testing with NodeWebkit (nw.js) too if that makes any difference.

@ruskul Have you set friction to 0 and also built a frame with 0 friction around? It is normal to lose energy when there's friction between objects

@BouncyTrip - yeah, Friction was all set to 0 in both box2d and chipmunk. Thanks though, that's important. That's a pretty sweet hat.