Ams.js vs Box2d Benchmarks. strange finding

Hey everyone,

I did a benchmark test and posted the results on R0j0hound's chipmunk physics forum post.

These were made using a win7 i5 laptop.

The test, Box containing small bouncing balls with 100% elasticity... I continued to add balls until the cpu usage fluctuated to greater than 85%

Box2dWeb: 600

AMS.JS: 850

Chipmunk: 1400

Something to note here which is very important. AMS.JS Keeps low cpu usage and then once you cross a object count it sky rockets to 90-100% . AMS.JS seems to run an average lower cpu usage than regular Box2d web, but I am notice high cpu spikes. If ams.js spikes to be at where Box2d web runs or even above, I am not sure its benifits are worth it.

When I am making a game, I really prefer to have predictable results and right now ams.js has some unpredictability. If you end up using 500 objects and get frequent spikes, then game play could be affected in a variable way (slow, smooth,slow,smooth). If Ams spike to where box2d web runs at then you really can only safely use the same amount of objects. Does anyone have some knowledge of what is happening here?

Box2d is much more linear in its object count to cpu usage. Chipmunk starts to use more cpu as the balls settle (which they shouldn't be doing). The settling becomes more pronounced as the object count increases.

I am unconvinced about the fruit asm.js promises to bear. I've spammed almost all of your threads about this Ruskul, I think - and here I go again! And I know Ashley doesn't believe my findings about asm.js not offering performance gains. I'll edit my physics test to compare cpu usage between the different engines.

So here are the quick results. 1600 circular objects in zero gravity... It was obvious that chipmunk is the most demanding on the cpu. Regarding the other two physics engines, there is little difference between box2d and asm.js performance, IMO.

These tests were run on Chrome Version 40.0.2214.111 m using r195 and r196.2. r195 was way smoother as you can see when comparing its graphs with the number of the frequent number of large dt values that are apparent in the r196.2 fps graph....

I still use Box2dWeb because of collision disabling which is a big part of my game. Curious when AMS.JS will get an update of this.

I still use Box2dWeb because of collision disabling which is a big part of my game. Curious when AMS.JS will get an update of this.

You can disable collision in asm.js from r196.

delaflaquita - collision disabling is available as of the r196 and on.

Colludium - thats cool, I like your input. I like everyone's input. I think we have similar wants and desires for physics so it makes sense, lol.

Those benchmarks are interesting too. For whatever reason, in the test I did chipmunk was outperforming the others (not expected) but had a lower stability. I noticed on your tests chipmunk was not doing so well. I am curious at what would cause this. I was using gravity in my tests with elasticity at 100% to maintain perpetual movement. Friction was also 0.

Cheers, — I've attached the two versions of the test, in case anyone else is interested in tinkering with them. They're not commented because I'm lazy - all you have to do is select the correct physics engine, make sure the correct behavior is enabled/disabled and enable/disable the on-created group as appropriate.

So I noticed you have to restart construct to get the engine to change. You can't run a game, change from box2d to ams.js, and then re run it. It will still be whatever was selected on start up. I think.

You could do to change between chipmunk and native - just enable/disable the bahavior accordingly. However there's no way I'm aware of to change between box2d web and asm.js.

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.

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.