I'm thinking of using an open-source 2d physics library with a project I'm working on. I've looked around and it seems that my 2 best bets are box2d and chipmunk. I'm leaning toward chipmunk because it's newer (and inspired by box2d), but I don't have any real working knowledge of either library. Anyone have any experience they'd like to share?

I am fan of Box2D:)
Authors of both of these engines are active and are still improving their engines, so the best way will probably be to use both and see what fits your project best:)

Are you looking at Box2D_Lite or Box2D? I'd probably choose Box2D because it is more mature, and has a C++ interface. That's not to say Chipmunk isn't good, or has a nice interface.

I was looking at Box2D. I've started tinkering with chipmunk, and it seems pretty solid.

Basically, I wanted to know if either one was particularly faster / more stable than the other.

One thing i've noticed with chipmunk is that you have to have a really low timestep for it to be solid, i think i ran it 200 times a second in my litte app. But it doesnt require that much cpu anyways so it's pnot really a problem. Better yet is to split every timestep in three or more as the author does in his demos.

[Edited by - lexs on January 1, 2008 1:46:10 PM]

Google has turned up this reference from Gamedev itself. To quote (the first post on that page):

Quote:Original post by pTymN
Chipmunk basically a glorified and optimized version of Box2D.

Does that statement hold water, or is it biased? I'm still a bit hung up on the thought of chipmunk being designed with partial inspiration from Box2D; it seems like that would imply improvement.

Quote:Original post by Funkymunky
Google has turned up this reference from Gamedev itself. To quote (the first post on that page):

Quote:Original post by pTymN
Chipmunk basically a glorified and optimized version of Box2D.

Does that statement hold water, or is it biased? I'm still a bit hung up on the thought of chipmunk being designed with partial inspiration from Box2D; it seems like that would imply improvement.

It was written before Box2D was released...before it was more like a sample code for Erin Catto's presentation. There were some big changes after the release.

Quote:Original post by Funkymunky
Google has turned up this reference from Gamedev itself. To quote (the first post on that page):

Quote:Original post by pTymN
Chipmunk basically a glorified and optimized version of Box2D.

Does that statement hold water, or is it biased? I'm still a bit hung up on the thought of chipmunk being designed with partial inspiration from Box2D; it seems like that would imply improvement.

I believe Chipmunk is a glorified and optimized version of Box2D Lite, not the new Box2D.

Well i've played with them both now, and I'd say they are equally easy to integrate / utilize. I'm leaning more toward Box2D now after the replies I've gotten in this thread.

Now I have a question which is actually relevant to both libraries, so I'll post just go ahead and post it here: What is the deal with these timesteps? I mean, I understand the concept of feeding the physics engine a timestep so as to advance the simulation by some tiny increment. However, both libraries seem to say that you shouldn't tie this timestep to the framerate. My question is, why not? It seems like, for a game, this is exactly what I want to do. I want the physics to perform relative to the rate at which my display is being rendered. Otherwise, gravity will be slower/faster on weaker/stronger machines, as well as pretty much every other physical interaction. Why not use the framerate as a basis for the timestep; because it can cause inaccuracies in the physics simulation? What is the best way to handle this, because I want the physics in the game to perform the same regardless of framerate.