Re: [pygame] pygame.sprite collision callback functions patch.

["René Dudfield" <renesd@xxxxxxxxx>]

Thanks again for the patches John.

Your patches have been committed.
Committed revision 1230.

ps.  Zhang Fan is going to be working on physics related stuff over
the next few months - so any input you could give him would be great
:)


Zhang: here's a few more things you might want to add to your reading list:
http://thread.gmane.org/gmane.comp.python.pygame/12496
http://thread.gmane.org/gmane.comp.python.pygame/12444

http://www.gamasutra.com/features/19991018/Gomez_3.htm
http://en.wikipedia.org/wiki/Sweep_and_prune

cheers,



On Wed, Apr 23, 2008 at 2:57 PM, René Dudfield <renesd@xxxxxxxxx> wrote:
> Cool, thanks :)  I should be able to commit your patches tonight.
>
>  I agree that we should probably figure out which vector classes we're
>  going to add to pygame, and if we might add something like a physics
>  engine to pygame.  Good point.
>
>  I think we should probably come up with something for the pygame 1.9
>  release... but what that is exactly I'm not sure yet... and needs more
>  discussion.  We were hoping that one of the google summer of code
>  projects were going to be accepted to add vectors and/or a physics
>  engine to pygame... but unfortunately it doesn't appear one of those
>  projects were accepted.  So now we need to figure out what to do.
>
>  cu,
>
>
>
>
>
>  On Wed, Apr 23, 2008 at 4:13 AM, John Krukoff <helot@xxxxxxxxxxx> wrote:
>  > Heh, can I get away with just writing tests for collide_circle_ratio, since
>  >  that's the only "new" code?
>  >
>  >  Just kidding, though working with unittest again feels like I'm back in
>  >  2006. Attached is a set of unit tests that exercise all the collide*
>  >  functions, and expand upon the tests that were already there. I'm not sure
>  >  these should all be in one test case, but it's how it was before, and the
>  >  setup is common with all of them.
>  >
>  >  So, what I was thinking I should adapt from my project is a sweep and prune
>  >  broad phase collision detection algorithm
>  >  (http://en.wikipedia.org/wiki/Sweep_and_prune), which is quite different
>  >  from the swept AABB test that sjbrown is implementing there. The problem I'm
>  >  trying to solve is handling large numbers of objects, whereas he's trying to
>  >  get more accurate collision detection.
>  >
>  >  The tricky part of writing an efficient sweep and prune algorithim in pygame
>  >  is that the sprite class doesn't have a good way of tracking motion, so it's
>  >  hard to take advantage of frame coherency to speed up a sweep and prune
>  >  test. I still think it's worth a try, but I think building the arrays each
>  >  frame might kill the performance advantage of sweep and prune for most
>  >  reasonable numbers of sprites.
>  >
>  >  I might add, I can't say I'm excited about his module either, especially as
>  >  it pertains to a generic solution in pygame itself. For one, he's
>  >  calculating a collision between the entirety of the AABB's swept volumes,
>  >  which is going too far in the other direction of just testing end positions.
>  >  If you're going to incur the overhead (especially in python), it should
>  >  really be done right and correctly find misses between two fast moving
>  >  objects.
>  >
>  >  His code is also really much more complicated than necessary, at least for
>  >  the collision detection part. The C code equivalent is shorter:
>  >  http://www.gamasutra.com/features/19991018/Gomez_3.htm
>  >
>  >  But really, my fundamental objection to trying to integrate collision
>  >  response at this time in pygame is that it really doesn't have a framework
>  >  for describing motion yet. And before we can get there, we'd need a 2d
>  >  vector class at the very least (likely 3d to make everybody happy). Then we
>  >  might be able to start talking about what collision response means in a
>  >  generic enough way to be helpful. Until pygame gets there, I just don't see
>  >  the point in worrying about anything more than collision detection.
>  >  ---------
>  >
>  > John Krukoff
>  >  helot@xxxxxxxxxxx
>  >
>  >
>  >
>  >
>  > > -----Original Message-----
>  >  > From: owner-pygame-users@xxxxxxxx [mailto:owner-pygame-users@xxxxxxxx] On
>  >  > Behalf Of René Dudfield
>  >  > Sent: Monday, April 21, 2008 6:50 PM
>  >  > To: pygame-users@xxxxxxxx; sjbrown@xxxxxxxxx
>  >  > Subject: Re: [pygame] pygame.sprite collision callback functions patch.
>  >  >
>  >  > Cool.  Thanks John!
>  >  >
>  >  > yeah, these functions are a fairly easy way to change collision behaviour.
>  >  >
>  >  > sjbrown was interested in doing a sweeping collision module.  See the
>  >  > email with subject: Collision Resolver module
>  >  > http://thread.gmane.org/gmane.comp.python.pygame/12496
>  >  > http://thread.gmane.org/gmane.comp.python.pygame/12444
>  >  >
>  >  > Maybe you guys could work together on something?  He's got the start
>  >  > of some code in one of the threads.
>  >  >
>  >  >
>  >  > Would it be possible to make some unittests for the functions you've
>  >  > made?  We're trying to make all new code have unittests.
>  >  >
>  >  >
>  >  >
>  >  > On Tue, Apr 22, 2008 at 3:18 AM, John Krukoff <helot@xxxxxxxxxxx> wrote:
>  >  > >
>  >  > >
>  >  > >
>  >  > >
>  >  > > So, I recently downloaded pygame 1.8, and was surprised to see the
>  >  > collision
>  >  > > callback functions make their way into the final release. I'd been under
>  >  > the
>  >  > > impression that things were trending towards a much more complicated
>  >  > > collision system, and thought these would get cut.
>  >  > >
>  >  > >
>  >  > >
>  >  > > In any case, here's a set of updates to the sprite.py collision
>  >  > functions
>  >  > > that update them to match the modules coding style, include appropriate
>  >  > > comments, and are about 20% faster. It also includes a
>  >  > collide_circle_ratio
>  >  > > function for completeness, and perhaps most importantly, fixes a bug in
>  >  > > colide_mask which kept it from working correctly.
>  >  > >
>  >  > >
>  >  > >
>  >  > > By the way, I keep meaning to write a sweep and prune collision
>  >  > detection
>  >  > > implementation that'll plug into the standard sprite module, has anybody
>  >  > > done that already?
>  >  > >
>  >  > > ---------
>  >  > >
>  >  > > John Krukoff
>  >  > >
>  >  > > helot@xxxxxxxxxxx
>  >  > >
>  >  > >
>  >
>