TIGSource Forums

I managed to hack ball physics into new closure recently and fairly simply using a bitmap collision kinda thing, ball physics is so easy!

Originally I was planning on trying to hack the behavior into Box2D with by writing some shoddy bitmap shape hack, but the hack itself might be more trouble than its worth.

Speed isn't that big of a deal, the most shapes I plan to have interacting with each other on a given stage is a couple at most. It's not a physics game at heart so naturally they're just there to supplement the experience.

I was thinking about faking box (square) physics using balls. I don't know how well that would work, and I can think of more troubles than I can think of advantages, but it definitely got me thinking a little bit.

My other option was treating it as a set of points instead then adding restraints among them, since point - bitmap physics is easy enough. Looks more like this will be the better way, and I might end up trying the box2D hack in the end after all.

Wait, I don't understand... What exactly is it that you need to hack into Box2D??

Bitmap land. My engine is an ever changing bitmap shape if you ever played the original, it was the best possible way to implement it.

Looks like it is difficult to implement a bitmap shape for Box2D.  You'll never get a ball behaving like a box :), but its not too hard to implement basic 2D rigid body dynamics for boxes (without stacking or constraints...) Chris Heckers articles (http://chrishecker.com/Rigid_Body_Dynamics#Physics_Articles) might be helpful.  Another alternative would be to implement Jacobsen verlet physics (http://www.gamasutra.com/resource_guide/20030121/jacobson_01.shtml).

I was thinking verlet, too. It's astoundingly easy to implement.
But I still think by the time you've cleared the glitches out, it would be equivalent work to adding on to an engine. The actual physical reaction to the collision, and determining the geometric properties of the collision are more or less orthogonal, so you might as well outsource as much of the first as you can. Some physics methods require less geometric information than other, so I suppose that should be your main criteria.

The biggest problem with modifying Box2D is that you'll get some very weird (and likely unwanted) side effects when the terrain changes shape. Box2D is typically run in timesteps much smaller than a full video frame. If in a single Box2D cycle a new shape appears from nowhere (or an existing one deforms significantly) this could give a pretty hefty kick to anything that ends up overlapping it.

Having played (and very much enjoyed) the original Closure, I'm a bit concerned that this could end up introducing the equivalent of Doom's "rocket jumps". :(

Bateleur: Box2D separates position and velocity solutions (nowadays). Meaning if you create two things overlapping they will separate at great speed, but it won't affect their actual velocity after they cease overlapping.

If you implement rigid bodies without stacking or constraints, following chris hecker's stuff, wouldn't that be quite jittery?  His examples are, at least.  I think you'd need some better treatment of contact forces, which is more annoying to implement.

Putting bodies that aren't moving that much to sleep or having heaving dampening would improve the behavior somewhat. Penalty constraints might not be that hard to implement. When it gets to the point where he's basically rewriting box 2D he might as well just bite the bullet and implement a bitmap collision shape...