[ODE] Question about variable step size and collision detection

Filip Joelsson filip at blueturtle.nu
Mon Dec 18 13:35:47 MST 2006

mån 2006-12-18 klockan 16:34 +0100 skrev Per Bull Holmen:

> Good point. Just to briefly explain my ideas, you can
> think of something like Arkanoid meets flipper. Like
> arkanoid, there will be much bouncing of a (hard)
> ball, hitting all kinds of walls and objects, and it
> may go slowly at times, fast or very fast at other
> times. More like flipper, these objects hit may not
> always be rectangular and static, but arbitrarily
> shaped, dynamic, sometimes on hinges. I'll need a
> physics engine to handle all of this. Most objects in
> the dynamics world will be resting throughout most of
> the game.
> I've played around with making an arkanoid-like game
> before. I seem to recall that letting the ball
> penetrate a few pixels into walls etc. does not look
> all bad, but it looks cleaner if it hits perfectly.


> For the most part, very few "live" objects (maybe 2-4,
> to be exact), will be manipulated by the engine. At
> times, there may be 10-20, most circle-shaped, (I will
> problably use cylinders for collision primitives) and
> only constrained by the x/y-plane.

If you want pixel perfect collision detection, I'd suggest that you
implement your own sprite class - instead of using cylinders. For
collision detection with sprites, all you need is to store beginning and
end for each row (which you'll do anyway if they are run length encoded)
- and check for overlaps. ODE allows you to plug your own CD in - so
this can be _very_ efficient.

If you want resources - there is an old tutorial on the tech on
Flipcode, or I can toss up a lib (in C) under a BSD license (it's for
PocketPC - but the CD is quite general).

I have seen that ODE is used in a couple of 2D applications. Would there
be an interest in a sprite class for the main tree?


More information about the ODE mailing list