[Update: this demo has evolved quite a bit and now has some actual interactivity and a few more options. See the updated version here.]
I wanted to post the simple demo I mentioned in the last entry, compiled against the latest version of the gwtBox2d library. There are actually two versions, one with the physics simulated in the main loop and one with it done in a Worker script.
A couple of notes:
The Worker version runs well in Chrome and Windows Safari, poorly in Firefox, and not at all in IE (no Workers). See my last post for details.
The main-loop version is operable in Internet Explorer 8 but there are a few too many shapes for the JScript engine to handle quickly. I’m also using the GWT incubator version of gwt-canvas which is choking while translating some command to VML, so nothing is displaying in IE8. gwt-canvas hasn’t been updated in a while; I really need to switch to a more up-to-date implementation (though I’m really tempted just to write a quick GWT wrapper for excanvas. Why reimplement when there’s already a community knee-deep in VML and Silverlight interoperability?).
This demo came almost directly from the eighth JBox2D demo—I wanted code I was certain would run—but I don’t have mouse picking or bullets yet. Five sets of blocks fall from above, jittered slightly around five x-coordinates to get a different result every time the simulation is run. You’ll notice that in the Java version of the demo the stacks of blocks stay upright. In many rigid body physics libraries, apparently, stable stacked blocks are an indicator of quality as they are easy to produce in real life but difficult to simulate. The posted demos are running at the suggested 10 constraint-solving iterations per step, but, since they only run at 30 steps per second (and can only run faster in Chrome and Safari), it is extremely unlikely that the engine will be able to recognize the stacks of blocks as at rest and let them stay stacked.
The “benchmarking” stats at the bottom of the Canvas are for the physics calculations only. On my computer, Firefox runs the first demo noticeably slower than 30 frames per second even though the physics calculation time would allow it to run faster that that. Rendering on a 750×400 pixel Canvas nearly doubles the time per frame (that’s 60 quads on a surface smaller than a Nexus One screen. We have hardware for that sort of thing!). Hence Worker scripts. While most people don’t want the average website to peg their processor, I see two processes that are largely independent; why not run them in parallel? Firefox 3.7?
Finally, I would really like to upload the demo source to the Google Code repository, but I would have to commit it from another Eclipse project. I’m still a total SVN noob, so I’m afraid I’ll screw up everything while trying to do that. Stay tuned.