Re: [pygame] Pixel perfect collision detection sugestion

[Brian Fisher <brian_fisher@xxxxxxx>]

------ Original Message ------
> I understand that circular or ellipsoidal collision is a good tradeoff 
> between rect and pixel-perfect collision. Anyone have any practical 
> experience with that?
> 
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 an
overlap 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 collision
stuff 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 objects
I'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 quite
valuable 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 I
can 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)