Chipmunk.js - Javascript port

[Murphy]

Hi,

first of all: Chipmunk is awesome! Great work, I really love the API design (:
I'm a Javascript developer and wanted a nice physics engine, so I ported Chipmunk to Javascript. I'm not fully done yet and consider it to be an early alpha, but nontheless.
It's based on Chipmunk 6.0 and I think I'm only two or three commits behind your repo on Github.

I wrote a little about the status on my blog: http://murphy.metafnord.org/blog/Squirrel-physics!.html

Demo page: http://chipmunk.metafnord.org/
Code: https://github.com/Moerphy/Chipmunk.js (wow, I'm super bad at naming projects..)

I'm gonna go get some sleep now (:

Cheers,
Murphy

[viblo]

Very cool!
Will keep an eye on your progress, have been thinking about writing some js games and this would be very interesting to try out.

[slembcke]

Hey that's awesome. I started on a JS port before I finished 6.x, but I don't really do JS programing at all so I sort of gave about half way through. http://files.slembcke.net/temp/Chipmunk-JS/ I had the solver fully working along with collision callbacks, but hadn't implemented anything beyond circle-circle collisions and a brute force broadphase.

I'll have to make a blog post about this.

[Murphy]

He he, I even found this when I was almost done porting (was googling the name to see if anyone else is working on that) and didn't even notice that it was on your page. Yeah Javascript can be a real bitch sometimes (o:

I think everything except for the BBTree and Sweep1D is ported, so most of the work left should be bug fixing and documenting.. and building some games with it. (:

[slembcke]

Well, it was more that it was really the first thing that I had ever programmed in JS other than little 1 liners for webpages here and there. I really had no idea how people liked JS APIs structured. After looking around for a bit it seemed like the answer was that they don't... I had considered finishing it to provide interactive documentation snippets, but that idea sort of died too. Too much work for too little gain.

I would skip the sweep 1D and spatial hash broadphases. I wouldn't really expect they would perform well in Javascript, and after making the BBTree the need for them is only for a few very specific cases.

It would be interesting to see it running with WebGL to see what the performance is like. Dunno what your experience is, but mine was that Canvas2D rendering was eating up almost all of the CPU.

[Murphy]

Oh yes, a lot of JS APIs are a mess.. the lack of native packages and loaders can make people do horrible things. (o:
It gets better though, people are slowly figuring out how to do it right..

I implemented the SpatialHash first because it was simpler than BBTree, since JS objects are hashes already. Only recently figured out how the tree works (I think), so I'm going to give that a shot soon.

Using WebGL would really be interesting, but both my laptops run on Linux with nouveau drivers and I think all major browsers disable WebGL when on nouveau because it crashes all the time. ):
I just ran a few simple scripts through a profiler and Canvas rendering does eat up most of the CPU if there are only a few (< 50) shapes. With more shapes the collision code seems to be the bottleneck.
No point in profiling too much yet though, because BBTree will probably speed that up also.

[slembcke]

Heh. Yeah, the BBTree is significantly more complicated. It took me MONTHS to figure out how to make the data structure work efficiently. I've never really went gone to document/comment it at all, so let me know if you find yourself lost.

[funkaster]

very nice! I'm going to plugin my simple 2d webgl with this to try a few things I have in my mind (https://github.com/funkaster/ChesterGL)

@Murphy: one thing that would make things faster in your implementation is to switch all vector operations from a regular js objects to native arrays. You can even use glmatrix for most of the operations. That will definitively give you a big boost of speed.

[trevarthan]

This is pretty epic work. There are already a lot of graphics (canvas) oriented JS frameworks to hook up to this. cocos2d-javascript and processing.js come to mind.

Whenever programming javascript, I always worry about memory leaks. Back in the bad old days ( 2008? - har har ), JS leaked like crazy on just about every browser. What is your experience with leaks in modern JS on modern browsers?

[Murphy]

Heh. Yeah, the BBTree is significantly more complicated. It took me MONTHS to figure out how to make the data structure work efficiently. I've never really went gone to document/comment it at all, so let me know if you find yourself lost.

I will do that, thanks. (:

@Murphy: one thing that would make things faster in your implementation is to switch all vector operations from a regular js objects to native arrays. You can even use glmatrix for most of the operations. That will definitively give you a big boost of speed.

For now I'm only focusing on getting it complete and stable, but I'll probably try that if the vector operations turn out to be performance hogs. I don't think they were the bottleneck when I profiled it a while ago, but that could easily change with time. (:

This is pretty epic work. There are already a lot of graphics (canvas) oriented JS frameworks to hook up to this. cocos2d-javascript and processing.js come to mind.

Whenever programming javascript, I always worry about memory leaks. Back in the bad old days ( 2008? - har har ), JS leaked like crazy on just about every browser. What is your experience with leaks in modern JS on modern browsers?

Javascript itself still has a few issues that benefit leaking, mostly the lack of Weakmaps (at least until ES5) and DOM-heavy operations. In my experience most Javascript objects are rather short-lived and get GCd really early. Also normal objects are moderatly small, the real bad leaks happen mostly with DOM objects imho.
At least nowadays we have the tools to find leaks easily (: And modern JS engines are insanely good.. I'd even go as far as saying JS runtimes outperform most other interpreted languages on memory and performance.