Re: [pygame] Pixel perfect collision detection sugestion

["John Eriksson" <john@xxxxxxxxxxxx>]

> "In fact I'm not aware of any really interesting physics simulation in
games that use pixel comparison at their roots for collisions."

Hehehe...pixel perfect is definitely not to recomend for any type of physics
simulation since the mathematics involved could be quite hairy *smile*...

But for many types of games you really can benefit a lot by using pixel
perfect collision detection. Take a simple helicopter game for example. You
fly your little chopper in a cave and you get realy close to the walls in a
tight passage....with pixel perfect you make it through (phuew!)...with
rectangle (or even with circle based) your copper might explode even though
you (the player) clearly could see it was at least two or three pixels
between the chopper and the wall(!!).

I belive that all three methods of collision detection
(rectangle,circle,pixel) has their  place and none of them should exclude
any of the others. But I must say that I don't understand why pixel perfect
collision detection hasn't been implemented in PyGame already since the
library has been around for so long.

/John

> In my opinion, the real benefit to using any kind of proxy geometry for
> collision (i.e., circles, rects or even polygons) as opposed to using
pixels
> as part of collision detection is that you can use continuous collision
> detection methods as opposed to discrete ones (meaning you detect when and
> where objects would collide if they moved with given motions as opposed to
see
> if they should have collided in their new positions, like you would with
anoverlap test - some literature refers to this as "a priori" vs.
"a posteriori"
> basically meaning before the fact or after the fact)
>
> The advantage of continous type methods are as John Eriksson said "to
> calculate collision angles and the following collision response", but
also
> that you never miss collisions due to objects moving fast relative to your
> simulation rate. As far as I know, no one has ever implemented any
continuous
> collision system with pixel-based methods, and I don't believe it's
practical
> to do so. In fact I'm not aware of any really interesting physics
simulation
> in games that use pixel comparison at their roots for collisions.
>
> I think this all is relevant for considering what the api for any
collisionstuff added to pygame should be. I don't think I'd personally use a
pixel
> perfect collision test for any continuously moving objects in a game (have
> been avoiding them so far), and so the majority of "sprite" type
of objectsI'd have wouldn't use the tests and would use a different
collision system
> entirely.... However I think I'd find a pixel perfect hittest feature
quitevaluable for stuff where object motion is driven more by user input or
> single-frame events than physics, stuff like stamps and shotgun blasts or
> maybe in a 2d fighting game - also in all the cases I can think of where
I'd
> like to exploit such a feature, the images I'd want to hit test against
each
> other would be proxy stuff - not the actual images drawn for a sprite, so
Ican do zoning for hit response and so I can decouple presentation and art
from
> collision stuff as needed)
>
> So my point is I think for these reasons I'd probably perfer to see any
> pixel-perfect hit testing in pygame exist first as a simple
surface-to-surface
> overlap test at some offset rather than have it's first usable form be
> something in the sprite system (but having the sprite system using it
would be
> cool for people who want simple and quick collisions that look right)
>
> ---
> (P.S. I like the stuff Rene Dudsfield suggested for implementation -
> specifically write stuff that uses John Eriksson's approach in C, skipping
> numeric, and having some kind of mask that's generated from the surface
would
> probably be good to avoid having to lock hardware surfaces to get at bytes
and
> all that)
>
>
>
>
>
>
>