Chipmunk bindings for MonoTouch

(c) S. Delcroix 2013

I'm quite pleased to announce the availability of Chipmunk bindings for monotouch. I started that last year, and bound just enough of it to get a sample working, added some constraints lately in order to place labels, and completed it since for the beauty of the task. The image next to this is a screenshot from a system using a motor, a gear joint, pivot joints and some more.

At this point in time, the ~2000 lines of manually crafted lines of code can be found in this pull request, but you probably won't have to wait long before it's merged in the monotouch-bindings repository.

What's missing ?

Mainly queries, plus a few function calls here and there.

Integrate with cocos2d

If you build the Chipmunk bindings from within the mono touch-bindings/cocos2d folder, with ENABLE_CHIPMUNK_INTEGRATION=1, Chipmunk will be build inside of the Cocos2d.dll, and you'll also get the CCPhysicsSprite class acting as integration layer between a Cocos2d sprite and a Chipmunk body.

Memory management

tl;dr Always keep a reference to your Space object and you'll be fine.

Multiple Chipmunk managed objects can hold a reference to the same native struct (for example, you could have the object you added to the space, and then another one pointing to the same native ref returned from a callback). As such, we can't free the native memory when a managed object is GC'd. To workaround this, we keep a table of all the managed objects (except for Arbiters) pointing to a native one, and only free the native pointer when the last managed instance is disposed.

In addition, the Space keep a managed reference to all the Bodies, Shapes and Constraint added, so the native memory isn't freed even if your code doesn't keep a ref to the body/shape/constraint. So, keep a ref to the Space and everything we'll be fine, provided that you create all the Chipmunk objects from the managed side.


For more on this, or something totally different, contact me, I'm open for contracting.