shakiba

That's right, it's only rendering and layout library.

I guess I fixed the issue that you pointed out, it was a new bug in testbed. Thanks for reporting!

You may need to force-reload the example to see the update. Please let me know if the issue still exists for you.

Thanks! It is easy to integrate Planck.js with other liraries and dev tools.

Thank you!

I have not seen any problem with car example on my own laptop, but I will try it on some more different devices to find the issue.

Regarding performance, because Planck.js code is hand-made and readable it is not difficult to improve it if it is not fast enough with some cases.

asm.js looks promising, I'm going to have a closer look at it.

The game is very cool! :)

P2.js was a great effort and is a nice project. It is also inspired by Box2D and its API is very similar, however Box2D algorithm and architecture are more sophisticated and stable, and is already used in many popular games (such as AngryBirds) and game dev libraries (such as Apple's SpriteKit) so I decided to rewrite Box2D to make it available to JS/HTML5 game developers as well.

Box2DJS is based on an old Flash port and as far as I remember it didn't work well when I tested it (for example second example on the website doesn't work currently, right click to switch to next example). I decided to directly port from C++ so that I can keep it updated.

Awesome, thank you!

Probably it would be easy, I would be happy to help with that, please feel free to open an issue on github.

Those are changes to internals, there are only few API differences which are explained on readme page. Anyway, I agree with you, a new API doc would be very helpful.

The main difference is that it is a hand-made rewrite, so the code is readable and improvable, so performance can be improved and optimized even if it is not fast enough in some cases. Also see my other comment about comparison with emscripten port.

In JS, if you pass same input it will give you same results. With box2d/planck frequency needs to be constant anyway, and I have not seen any nondeterministic component in the code. (I think in box2d docs it refers differences in execution platforms not the library itself.)

Great work! I decided to directly rewrite Planck.js from Box2D C++ code, so that I can keep it updated (as far as I remember that flash port was few years old).

Thanks! Repost from reddit:

The main reasons that I decided not to use Emscripten port was usability:

- First, it is generated and unreadable code, therefore it is impossible to understand how it actually works in JS to use it optimally, debug it or improve it for JS. While it possible to improve Planck.js if it is not as fast in some cases, it is not possible to do anything with Emscripten port.

- Second, API of Emscripten port does not follow JavaScript conventions and is inconvenient to use in JavaScript. For example it returns an empty object, instead of no object (null or undefined) as last element of a linked list (which is very confusing in JS). Here are some more usage comparisons:

    // emscripten
    var bd_ground = new Box2D.b2BodyDef();
    var ground = world.CreateBody(bd_ground);
    var shape0 = new Box2D.b2EdgeShape();
    shape0.Set(new Box2D.b2Vec2(-40.0, -6.0), new Box2D.b2Vec2(40.0, -6.0));
    ground.CreateFixture(shape0, 0.0);    

    // planck.js
    var ground = world.createBody({});
    ground.createFixture(planck.Edge(Vec2(-40.0, -6.0), Vec2(40.0, -6.0)), 0.0);

    // emscripten
    var bd = new Box2D.b2BodyDef();
    bd.set_type(Box2D.b2_dynamicBody);
    bd.set_position(ZERO);
    var body = world.CreateBody(bd);

    // planck.js
    var body = world.createBody({
      type: "dynamic",
      position: Vec2(0, 0),
    });
    // or just world.createDynamicBody();

    // emscripten    
    myQueryCallback = new Box2D.JSQueryCallback();
    myQueryCallback.ReportFixture = function(fixturePtr) { };

    // planck.js
    myQueryCallback = function(fixture) { };

Planck.js developer here! I have posted this to reddit before, so I'm just going to include it here too:

I have ported/rewritten Box2D physics engine to JavaScript, for cross-platform HTML5 game development. Planck.js includes entire Box2D algorithms, a simple HTML5 Testbed, more than 50 examples and some new game prototypes. The project is pre-released and there may still be minor issues, which I'm working to fix. So far I have spent more than 400 hours for developing this project and it consists of around 20k lines of code.

https://github.com/shakiba/planck.js

My main motivations for working on this project are:

- Taking advantage of Box2D's efforts, achievements and community knowledge

- Developing readable and maintainable JavaScript code

- Optimizing the library for web and mobile platforms

- Providing a JavaScrip-friendly API

Your feedback is highly appreciated, and I hope you use Planck.js to make some awesome games soon!

Thank you! Just fixed it! I actually LOLed very hard!

Author here! Thanks for troll comment!

> when I look at an open-source codebase built on React + Redux, it's so easy to understand the application architecture.

That's my point, I believe a library should not imply architecture.

:)

Looks like a new hell!

"APRIL" 2015

Why?

I compared O! GC with few other HTML5 games, it seems that GC frequency is normal with high number of game objects.

Regarding you technical points:

Yes, there is an issue with O!, it makes too much garbage, it should be corrected.

I guess your point is to store depth of a drawable instead of traversing the tree? I'm not sure how faster it can make the entire rendering process.

tick(fn) to register fn is only called during initializations (not every frame), it doesn't matter how it is implemented.

Instead of pin({}) you can use pin('name', value) or simply reuse your {} object. I don't see any problem with "_next = {}" where it is used for creating tweening.

Without type hinting it is still fast enough, but good idea.

Thanks for your point about "throw", however I'm not sure functions having "throw" really need to be optimized, but I will consider that.

absoluteMatrix is only for internal use, and I have not documented it yet, but it is what it is and is only updated on ticks for performance reasons.

Thanks for your point about drawImage try/catch.

I'm not sure how drawImage with source params is optimized across different platforms so for now I have let it be as it is. But I agree with your point.

There is obviously a lot to make it run faster but the point is to find bottlenecks which really matter. For example in most case the bottleneck is the physics engine not rendering engine at all.

Also if you notice you can see I have done a lot to make it fast, for example using lots of timestamps (ts) and monitors (mo) to avoid unnecessary calculations.

Anyway feel free to fork it and change anything to prove that I'm wrong! I will appreciate that!

No worries. Peace! I'm almost done answering your first comment.

Actually I love your feedbacks, but putting your quick conclusion on top and putting personal attack on bottom is strange.

Your exact phrase is "your dishonestly", you could have described it as "inaccurate description" instead.

Thanks a lot for code review, I'm reading, but you have made many unjustified claims and based on results I would say your conclusion is not valid.

You have also made personal attack ("your dishonesty"), probably because of your own competing library (jsil.org).

CutJS is already GPU and CPU-friendly, the problem is that his browser is not GPU-enabled and uses CPU for GPU tasks. It is not about CutJS, Canvas or Flash. When you use CutJS with a GPU enabled browser only a very small portion of CPU is used which shows that is CPU-friendly.

Exactly! Plus scale/skew and rotation.

If you like Pixi/Phaser you will love CutJS! Using CutJS is far simpler and you can use whatever physics and sound library you like. There are P2.js, PhysicsJS and SAT.js examples in repo. For sound you can use Howler.js, SoundManager, etc.