Re: [pygame] [Announce] Python bindings for the bitmask collision detection library

[Charles Joseph Christie II <sonicbhoc@xxxxxxxxx>]

On Tuesday 15 May 2007 08:36:31 pm René Dudfield wrote:
> Hi,
>
> for other peoples interest we have committed these changes to svn.  We
> also made it use the old faster code for the default rect collision.
> So it shouldn't change how fast current games go.
>
> There's still some more changes coming though.
> The main one being:
> - implementing bitmask collision functions.
>
> Which brought us on to a conversation about collision response.  As
> the new mask module has the ability to return the direction of the
> collisions.  So it'd be nice to make use of that functionality from
> within the sprite module.
>
> pygame.sprite already has a limited collision response mechanism.  It
> allows the 'killing' of sprites upon collision.  With the dokill
> arguments to groupcollide, and spritecollide functions, and the kill()
> method of sprites.
>
>
> However there are three types of collision+response we want:
> 1. - just collision detection.
> 2. - collision detection where the sprites are removed apon detection.
> 3. - collision detection where the direction is calculated and passed
> to the sprites to work out.
>
> Pygame already does 1., and 2.  However 3 is useful.
>
>
> 3. - collision detection where the direction is calculated and passed
> to the sprites to work out.
>
> Number 3, can is pretty generic (the goal of the sprite module).  So
> people can implement their behaviour quite easily.  It will allow
> people to ask all different questions in the behaviour of the
> collision response functions that require a direction:
> - did the mario character jump on the head of the creature?
> - what direction should they bounce away from each other?
>
>
> We worked out one way which we could do this to the sprite module so
> that the current api can remain, and that we can add it in such a way
> that directions are not calculated if they are not needed.
>
> It is important _not_ to calculate the directions if not needed because:
> - it is faster not calculating direction. (we don't want to slow down
> existing games that don't use it).
> - it is easier to implement just collision for custom collision
> functions.  (so people can just implement new forms of collision
> detection, without being forced to implement the collision direction).
>
>
> There would be these changed functions:
>
> The current collision functions:
> def groupcollide(groupa, groupb, dokilla, dokillb, collided = None):
> def spritecollideany(sprite, group, collided = None):
> def spritecollide(sprite, group, dokill, collided = None):
>
> The new collision functions:
> def groupcollide(groupa, groupb, dokilla, dokillb, collided = None,
> collided_direction = None):
> def spritecollideany(sprite, group, collided = None, collided_direction =
> None): def spritecollide(sprite, group, dokill, collided = None,
> collided_direction = None):
>
>
> The new argument is collided_direction. None means do not calculate
> the direction.  Otherwise it should be a collision direction function.
>
> The collision direction functions would be:
> def collide_rect_direction( left, right ):
> def collide_circle_direction( left, right ):
> def collide_mask_direction( left, right ):
>
> Each would of these collide_*_direction functions would return False
> if there is no collision, or a vector direction if there was a
> collision.
>
>
> New Sprite method:
>
> As well as a kill method, the Sprite class will gain a new collided()
> method. def kill(self):
>     def collided(self, asprite, direction):
>
> Where 'asprite' is the sprite collided with, and the 'direction' is
> the direction of the collision.
>
>
> So to implement sprite behaviour on a collision - you could place it
> in the collided method.
>
>
> So that's the idea of how to implement generic collision response
> within the pygame sprite module.
>
> What do you reckon?
>

I like it. But, one question: with this, how would you do that Mario example 
you just gave, with Mario jumpin' on something head?