Differences between Box2D 'Web' and 'asm.js'

0 favourites
  • 13 posts
From the Asset Store
Game with complete Source-Code (Construct 3 / .c3p) + HTML5 Exported
  • The new C2 version comes with improvements to the asm.js, and from what I could read, it's far better than the web version of Box2D.

    So, I made a test to compare both:

    Hundreds of squares, with the physics behavior, falling in a concave platform. But, I couldn't notice any difference of performance between both..

    So.. that's my question: where we can see the said difference?

  • Mobiles most likely, where memory is much more critical

  • I'd be curious to see your performance test because my physics stress test (basically filling up a bucket with as many small objects as possible) gets to a 3x higher object count with asm.js. The asm.js version is like a native-compiled version which browsers should be able to optimise like native code.

  • Mobiles most likely, where memory is much more critical

    Hm.. makes sense. hehe

    I'd be curious to see your performance test because my physics stress test (basically filling up a bucket with as many small objects as possible) gets to a 3x higher object count with asm.js. The asm.js version is like a native-compiled version which browsers should be able to optimise like native code.

    Here is the capx: https://dl.dropboxusercontent.com/u/191 ... Box2D.capx

    Till 800 objects, my fps is stable. Then, goes down (web and asm.js).

    I don't know why, but I'm getting exactly the same performance with both..

    My specs:

    GTS 450

    X4 955

    4gb RAM

    And Ashley, one more question: Web and asm.js handle just the physics behavior or every collision and things like that?

    Thanks.

  • Zathan, I agree with your assessment - I've submitted this on the back of another bug report here.

  • Zathan

    Using your test capx (in chrome v40.0.2214.93 m) :

    asm.js

    (roughly) 1200 60 fps

    web

    (roughly) 1300 60 fps

    From my experience Box2D web has shown better performance. I have a feeling this correlates to system specs and vid cards.

    System Specs:

    R196

    Win 7 64

    Xeon E3-1230 3.30GHz

    32 GB

    GTX 650Ti

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Thanks guys, now I know it isn't just on me

    And Ashley, any idea why this happens?

  • UPDATE:

    Updated chrome using R196.2 got better results. In fact asm.js is performing a lot better for me now.

    Using your test capx (in chrome v40.0.2214.94 m) :

    asm.js

    (roughly) 1300 60 fps

    web

    (roughly) 1300 60 fps

  • I submitted this as a bug report and would be interested if anyone else can reproduce what I see on my system....

    Try this capx: [attachment=1:n5nrb90z][/attachment:n5nrb90z]

    It's a variation of the one in the bug report. It creates a large number of physics balls and then just runs as they bounce around in zero gravity - the idea was to create enough balls to stress the system but to maintain near 60 fps in r195. The layout also displays a horizontal scrolling graph of dt so any variations can be seen over time. The number that stresses my system on Chrome is 1600 - so you might need to tweak that up or down depending on what hardware you're using.

    To my eye it appears that r196.2 causes more and more frequent frame drops (large dt values > 16 ms) than seemed apparent in r195. This might be a bespoke finding just to my system so it would be good for others to test it and see if it's either just me... It's also worth noting that I also consistently see no discernible improvement in performance when using asm.js over the standard box.2d.

    [attachment=0:n5nrb90z][/attachment:n5nrb90z]

  • Colludium

    What a nice benchmark. Really awesome. hehe

    unfortunately, that "bug" remains a mystery to me.. Ashley said that his tests gets 3x higher fps in asm.js. '-'

    Oh, and again my previous question: Web and asm.js handle just the physics behavior or every collision and things like that?

    Thanks.

  • Thanks! I'm better at making benchmarks than I am at making games... Something to do with my real job LOL...

    I hope that Ashley is quietly looking into this but I suspect that the case is closed - just from his words to me in the bug report where he all but dismissed these findings. It's quite clear that, on my hardware (i7, 16Gb, 6Gb vram - no slouch ) that r196.2 performs worse than r195 - worse both in terms of number of physics objects that can be handled and worse in terms of the frequency of frame drops that occur when the engine is stressed. The performance hike for asm.js that's been reported has not been duplicated by anyone other than Ashley, that I'm aware of.

    Some fundamental changes were recently made to the physics engine and, although there is evidence that the performance is slightly worse, I think we're just going to have to learn to live with it because the aspiration is to ultimately use only asm.js. Personally, I would rather we had a full native implementation of box2d web rather than have this effort focus on implementing 'improvements' like this.

    As far as I understand it, non-physics collisions are handled differently than the normal c2-optimized collision checking.

  • Colludium

    What a nice benchmark. Really awesome. hehe

    unfortunately, that "bug" remains a mystery to me.. Ashley said that his tests gets 3x higher fps in asm.js. '-'

    Oh, and again my previous question: Web and asm.js handle just the physics behavior or every collision and things like that?

    Thanks.

    It's only a physics engine.

  • Hehe ok.

    Thank you, guys!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)