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?
