I've been entertaining thoughts recently of integrating a physics engine with minisphere.  I initially looked at Box2D, but that's C++ and I'd prefer to keep the engine pure C if at all possible.  This led me to look into Chipmunk:
http://chipmunk-physics.net

It's C and appears to be a primary competitor to Box2D--usually faster, but with fewer bells and whistles.  It also apparently has a JS port.

My question to you guys is: Would there be any interest in seeing this become a reality?

I would love a proper and reasonably usable physics engine built into Sphere someday (sooner rather than later) and it can probably be the basis of the particle system stuff, saves me from having to write/rewrite NPhys/NPart every time I want to do something that even resembles physics in a Sphere project (like bullets in my shmup).

Alright, well Chipmunk looks easy enough to use, so I'll do some experiments and see how difficult it would be to build an API around it.

The good news is, it looks like Chipmunk isn't very difficult to use.  Just looking at the examples it came with, it seems to be designed to be very generic and low-level, but there a ton of helper functions to make things easier.

The thing is though, I'm not sure how to set up the API so that it retains most of the necessary features but is still general enough to be able to drop in a different physics engine if necessary.  There's also the issue of units--Box2D uses physical measurements, Chipmunk is ostensibly in pixels (technically it's dimensionless).  So there's a lot to figure out here.

I was able to get fairly decent performance from Box2D via emscripten. I think it's worth looking at.

Yeah, Box2D definitely looks nice, but its API is C++, meaning I would have a write a wrapper/shim to be able to call into it from C.  Chipmunk is C natively, so it'll be easier to just drop it in.

We'll see what happens.

I mean Box2D in JS directly, via emscripten. Performance does take a hit, but I was only seeing a single order of magnitude speed loss. Not great, but that's the kind of price I consider acceptable to put something like that in script.

Of course, that doesn't really require engine support anyway

I think you would need a new object type to hold all the information. If not, at least a matrix, or use something to handle them in JS? for example:  http://glmatrix.net/
Or, in Sphere classic style, you would get so many new functions like .rotateXYZ(pivot_point, X_degrees,Y_degrees,Z_degrees) but then, to simpify, also .rotateX(), not to mention .zoom(), .translate() etc. Once you get to collissions, you will need either the vertices of an image, "mass" of the image, and then do something with the data you get back, like rotate the image because the collision gave it spin. Maybe I am the one looking wrongly at the problem at hand, but it seems to me the physics engine will do a small part, not a big part like automatically change the x,y of an image (of a spriteset), and then in javascript you would have to define if the spriteset is allowed to be rotated... what I am trying to say: how much is inside the user interface javascript, and how much would be handled inside C.
Things can be simplified by only allowing vector polygons, and then use a poligon of 4 points, for which we get the 4 coordinates back in JS and draw the image each time (where we can either get the spriteset image, or a font image, etc). But this method would require a way to, say, create a best-fit poligon out of an image with a circle (kind of like an image mask).....

I'm going to stop now, my head hurts when I try to apply ragdoll physics to a sprite... would be cool though, the rectangular sprite bending like a C when punched in the gut. Automatic pixel-perfect edge detection...