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 > > > >
Attachment:
sprite_test.py.patch
Description: Binary data