Chipmunk Physics

It's coming soon. Can't promise an exact date.

There aren't any really ground breaking changes, a few optimizations, small bug fixes, comments, and updated documentation. Unfortunately I haven't been as diligent about writing down changes this time, so I can't be any more specific. You can check the latest code out from SVN if interested.

Do you have any plans to add support for nonconvex polygons?

It looks like convex polys are likely to come at the same time as swept collisions. (a ways off yet) I don\
't really want to make major changes to my collision code until then. While there are some minor problems \
with decomposing a concave poly, overall it work fine.

For release 4, I think I should also just stop with the releases. Keep a well maintained changelog and bi-monthly tarballs maybe.

I don't know. There's something to be said for having a version numbers, at least in so much as generating libraries is involved. For example, in our project, in order to incorporate a per-layer gravity with a single cpSpace, we had to use the cpBodyUpdateVelocity and cpBodyUpdatePosition functions. Now, in the documentation, it's mentioned that we shouldn't need to use those functions, unless we're doing exactly what we're doing. But, because our needs from the engine are pretty basic, we probably won't need any newer version of Chipmunk for our current game.

There's also the philosophy that a game's design should be carefully tuned to its physics engine. If Chimpunk 4 (or later) changes things, no matter how slight, it can, for example, make previously unreachable areas of the level reachable. As such, it would be nice to have the library files marked with their version (libchipmunk3.a chipmunk3.dll, etc.), so that a game targeted for a specific release can be guaranteed that library won't get overwritten.

On the other hand, you can mark them with the svn revision number, but that might start to get unwieldy.

I suggest following the RubyGems rational version numbering policy: http://rubygems.org/read/chapter/7

It makes things clear for users and developers alike about which version to use.

Any progress on "release 4" ?

I like the x.y.z versioning scheme. Its also often seen that y is used as development branch with odd y numbers indicate development (aka trunk) versions and even y numbers stable releases. Right now i can only recall three projects using this actually (the linux kernel, gnome and wesnoth ) but there are much more out there.

dino wrote:Right now i can only recall three projects using this actually (the linux kernel, gnome and wesnoth ) but there are much more out there.

phpBB (this forum software here) uses it

Per body gravity would be cool, and not that hard to implement (I'd image). You could leave the space gravity and have the body gravity default to that.

lucas wrote:Per body gravity would be cool, and not that hard to implement (I'd image). You could leave the space gravity and have the body gravity default to that.

I've been thinking it wouldn't be a bad idea to have gravity or damping multiplieriers. I did used to wonder at the utility of it, but it seems to be something that has been requested a lot.

Well, I have enough progress that a release would be useful. I just need to get off my butt and update the documentation. I think that is mostly what's holding me back.