A virus would stop spreading in community if 40%-60% of people are immune, for example by catching it and producing antibody. So a radical approach would be to have people who are more likely to survive volunteer to catch it in quarantine and under care.It would make volunteers immune so that they can get back to life and work without worry and will stop the virus from hitting more vulnerable...
I like Functional Programming, however in JavaScript I can't figure out how to use polymorphism with FP. For example how would you implement `toString` in JavaScript with Functional Programming?Cross posted here: stackoverflow.com/questions/48257447/
You may need to force-reload the example to see the update. Please let me know if the issue still exists for 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 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) { };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!
That's my point, I believe a library should not imply architecture.
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!