4 ms·

I wonder how will this runs once you have a half dozen independent objects running around the screen. The extra layer provided by the browser (especially on mob

by jtagen 16y ago

I wonder how will this runs once you have a half dozen independent objects running around the screen. The extra layer provided by the browser (especially on mobile devices) must cause an enormous hit. From the movie, things look like they have serious lag. I'm hoping this works, could be a great teaching tool.

bd 16y ago
This technology is actually pretty fast. Drawing images is so fundamental for browsers that it tends to be heavily optimized. If your hardware runs well Google Maps, it will run well this engine (and also the other very similar one - Aves from Dextrose). Rendering wise, it's the same technology. Most of heavy lifting is done by compiled code of the browser, JavaScript just sets few parameters (as opposed to canvas, where you "micromanage" rendering in relatively slow scripting language). One screenful of map is about 80-100 images, though performance wise there is still quite a lot of breathing room. I did some stress tests and my notebook can easily handle many hundreds individual image sprites (done as absolutely positioned DOM elements). Now physics, this may be slow to do in JavaScript. But with a type of games that work well with image sprites (basically anything where building blocks are large), this will probably not make too big problems as you will not have that many interacting objects (at once together at screen) and also interaction will be optimizable. The "killer app" will probably be tile based strategies or role-playing games (see current top Facebook apps), so physics / pathfinding / AI would only need to deal with discrete grids, not some costly pixel precise collision detection.
- teamonkey 16y ago
  JS physics library: http://box2d-js.sourceforge.net/index2.html http://box2d-js.sourceforge.net/index2.html

4 ms·

I wonder how will this runs once you have a half dozen independent objects running around the screen. The extra layer provided by the browser (especially on mob

by jtagen 16y ago

bd 16y ago
This technology is actually pretty fast. Drawing images is so fundamental for browsers that it tends to be heavily optimized. If your hardware runs well Google Maps, it will run well this engine (and also the other very similar one - Aves from Dextrose). Rendering wise, it's the same technology. Most of heavy lifting is done by compiled code of the browser, JavaScript just sets few parameters (as opposed to canvas, where you "micromanage" rendering in relatively slow scripting language). One screenful of map is about 80-100 images, though performance wise there is still quite a lot of breathing room. I did some stress tests and my notebook can easily handle many hundreds individual image sprites (done as absolutely positioned DOM elements). Now physics, this may be slow to do in JavaScript. But with a type of games that work well with image sprites (basically anything where building blocks are large), this will probably not make too big problems as you will not have that many interacting objects (at once together at screen) and also interaction will be optimizable. The "killer app" will probably be tile based strategies or role-playing games (see current top Facebook apps), so physics / pathfinding / AI would only need to deal with discrete grids, not some costly pixel precise collision detection.
- teamonkey 16y ago
  JS physics library: http://box2d-js.sourceforge.net/index2.html http://box2d-js.sourceforge.net/index2.html