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

[René Dudfield]

Another option would be to have some new functions for direction.
Rather than adding more keyword arguments.  The benefit of that is
they can return something different.

spritecollide_direction(...) ->
[(spriteb, direction), ((spritec, direction)), ...]

groupcollide_direction(...) ->
{ spritea : ( spriteb, direction ), ... }


piman:  I'd really appreciate your comments on this whole thing.




On 5/16/07, René Dudfield <[EMAIL PROTECTED]> 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?


On 5/9/07, John Krukoff <[EMAIL PROTECTED]> wrote:
> René Dudfield wrote:
> > It's in pygame now.
> >
> > There's still a few things I need to do.
> >
> > - make constructor which takes a surface.
> > - a 'make_surface' method in C.  should take a threshold for alpha.
> > - complete the documentation (now in src/mask.doc)
> > - complete the unittests (test/test/mask_test.py)
> > - make set_at and get_at raise IndexError when wrong index is given.
> > - double check the reference counting.
> > - integrate Mask into examples/testsprite.py
> >
> >
> > JKrukoff has an idea about how to change the sprite classes so they
> > can be extended to use different types of collision detection.  He's
> > going to write a proposal to the mailing list about it later.
>
> Right, so as discussed in IRC, I have a simple proposal for extending the
> sprite module collision detection routines to be able to handle arbitrary
> 

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

[René Dudfield]

Good question...


On 5/16/07, Charles Joseph Christie II <[EMAIL PROTECTED]> wrote:

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?

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

[Charles Joseph Christie II]

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?

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

[René Dudfield]

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?


On 5/9/07, John Krukoff <[EMAIL PROTECTED]> wrote:

René Dudfield wrote:
> It's in pygame now.
>
> There's still a few things I need to do.
>
> - make constructor which takes a surface.
> - a 'make_surface' method in C.  should take a threshold for alpha.
> - complete the documentation (now in src/mask.doc)
> - complete the unittests (test/test/mask_test.py)
> - make set_at and get_at raise IndexError when wrong index is given.
> - double check the reference counting.
> - integrate Mask into examples/testsprite.py
>
>
> JKrukoff has an idea about how to change the sprite classes so they
> can be extended to use different types of collision detection.  He's
> going to write a proposal to the mailing list about it later.

Right, so as discussed in IRC, I have a simple proposal for extending the
sprite module collision detection routines to be able to handle arbitrary
types of collisions instead of only rect collisions. I propose adding a
callback parameter to spritecollide, groupcollide, and spritecollideany
which will be a function which evaluates two sprites for a collision,
returning a boolean result.

The default value for this parameter would be a function that uses
colliderect to evaluate the two sprites, giving clean backwards
compatibility with existing code.

I've had to write my own collision routines in order to support mixing
bounding boxes a

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

[John Krukoff]

René Dudfield wrote:
> It's in pygame now.
> 
> There's still a few things I need to do.
> 
> - make constructor which takes a surface.
> - a 'make_surface' method in C.  should take a threshold for alpha.
> - complete the documentation (now in src/mask.doc)
> - complete the unittests (test/test/mask_test.py)
> - make set_at and get_at raise IndexError when wrong index is given.
> - double check the reference counting.
> - integrate Mask into examples/testsprite.py
> 
> 
> JKrukoff has an idea about how to change the sprite classes so they
> can be extended to use different types of collision detection.  He's
> going to write a proposal to the mailing list about it later.

Right, so as discussed in IRC, I have a simple proposal for extending the
sprite module collision detection routines to be able to handle arbitrary
types of collisions instead of only rect collisions. I propose adding a
callback parameter to spritecollide, groupcollide, and spritecollideany
which will be a function which evaluates two sprites for a collision,
returning a boolean result.

The default value for this parameter would be a function that uses
colliderect to evaluate the two sprites, giving clean backwards
compatibility with existing code.

I've had to write my own collision routines in order to support mixing
bounding boxes and bounding circles, but this method would allow for such
tests to be plugged into the existing API. This functionality currently
seems urgent, as we now need an optional way to use bitmask based
collisions. As long as it has to be extended, why not do so in a generic
way?

The attached file contains a sample implementation (sans documentation or
optimization work) which should illustrate the method. It also contains
basic collision functions for rect collisions, scaled rect collisions, and
circle collisions.

This method also lends itself to doing tests in stages, where a less
accurate and faster collision test is used first, and then the results are
used for a second pass with a more accurate (and slower) collision test.

Ex.
>>> import pygame.sprite as sprite
>>> a, b = pygame.sprite.Sprite( ), pygame.sprite.Sprite( )
>>> a.rect = pygame.rect.Rect( 0, 0, 10, 10 )
>>> b.rect = pygame.rect.Rect( 5, 5, 10, 10 )
>>> sprite.spritecollide( a, [ b ], False )
[]
>>> sprite.spritecollide( a, [ b ], False, sprite.collide_rect )
[]
>>> sprite.spritecollide( a, [ b ], False, sprite.collide_circle )
[]

Admittedly, this doesn't solve the issue of how to generate masks for
bitmask collisions (though that can be worked around in the collision
function much as radius calculations are in collide_circle), but then the
default implementation doesn't provide a rect either. This is, I think, a
change in spirit with the current sprite implementation of an extensible
container.

There are some performance considerations, as this adds a couple of lookups
and a function call to each test, but honestly, if you're worried about
performance you aren't using the default collision functions anyway.

-
John Krukoff
[EMAIL PROTECTED]
##pygame - Python Game Library
##Copyright (C) 2000-2003  Pete Shinners
##  (C) 2004 Joe Wreschnig
##This library is free software; you can redistribute it and/or
##modify it under the terms of the GNU Library General Public
##License as published by the Free Software Foundation; either
##version 2 of the License, or (at your option) any later version.
##
##This library is distributed in the hope that it will be useful,
##but WITHOUT ANY WARRANTY; without even the implied warranty of
##MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
##Library General Public License for more details.
##
##You should have received a copy of the GNU Library General Public
##License along with this library; if not, write to the Free
##Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
##
##Pete Shinners
##[EMAIL PROTECTED]

"""
This module contains a base class for sprite objects. Also
several different group classes you can use to store and
identify the sprites. Some of the groups can be used to
draw the sprites they contain. Lastly there are a handful
of collision detection functions to help you quickly find
intersecting sprites in a group.

The way the groups are designed, it is very efficient at
adding and removing sprites from groups. This makes the
groups a perfect use for cataloging or tagging different
sprites. instead of keeping an identifier or type as a
member of a sprite class, just store the sprite in a
different set of groups. this ends up being a much better
way to loop through, find, and effect different sprites.
It is also a very quick to test if a sprite is contained
in a given group.

You can manage the relationship between groups and sprites
from both the groups and the actual sprite classes. Both
have add() and remove() functions that let you add sprites
to groups and groups to sprites.

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

[René Dudfield]

It's in pygame now.

There's still a few things I need to do.

- make constructor which takes a surface.
- a 'make_surface' method in C.  should take a threshold for alpha.
- complete the documentation (now in src/mask.doc)
- complete the unittests (test/test/mask_test.py)
- make set_at and get_at raise IndexError when wrong index is given.
- double check the reference counting.
- integrate Mask into examples/testsprite.py


JKrukoff has an idea about how to change the sprite classes so they
can be extended to use different types of collision detection.  He's
going to write a proposal to the mailing list about it later.




On 5/9/07, René Dudfield <[EMAIL PROTECTED]> wrote:

hi,

I'm in irc now putting bitmask into pygame.

illume is my nick.

Cheers,



On 5/6/07, Ulf Ekström <[EMAIL PROTECTED]> wrote:
> Hi.
>
> > Bitmask as a separate module is a good idea.  I think your pygame.mask
> > is a good name.  Then we can provide some pygame.sprite mixins, or
> > methods to help there.
> >
> > - pygame.mask module.
> > - move docs from the source to .doc file.
> > - some unittests in the test/ directory.
>
> Ok, I can do this.
>
> > - move your pygame example to examples/bitmask.py or maybe...
> > bouncy_bitmask.py ?
>
> Sure, no problem. I have not even looked at the pygame source tree, so
> I don't know how you organize stuff. I will have a look.
>
> > I'm not sure about a surface method.  It might simplify things for
> > some people though.  However then it makes surface depend on the
> > bitmask module (not necessarily bad).
>
> It is more complicated, but I can imagine it makes it easier to use
> for beginners. Anyway, I cannot really help with this part so I leave
> it up to you guys.
>
> > Has it been tested on big endian machines?  eg ppc macs?  It looks to
> > have checks in there for 64bit machines - has it been tested on 64bit
> > machines too?
>
> Yes. The library is used in my game 'Airstrike', which has been tested
> on a lot of platforms: sparc, ppc, i386 and even some old amiga
> platform. So I think it works. I develop on ppc and i386.
>
> > 'maskFromSurface' might be a constructor argument?  This would be so
> > common, that we should do our own implementation.
>
> Yes. It is also much faster in C than in Python. I can't really think
> of a good set of arguments to the constructor that allows for either
> (width,height) or a surface, though.
>
>  Do you think it
> > would be very different for different games?  eg, using different
> > alpha levels as 'empty'.  5% alpha might be considered to be gone by
> > some games/sprites.  If you think that's useful, an alpha_threshold
> > argument might be appropriate.
>
> I think it's a good idea. It can default to 50%.
>
> > As you suggest, there's lots of other uses for bitmasks, other than 
collision.
> >
> > Blitting surfaces masked with a bitmask might be a future application.
> >  Another future application might be to reduce over draw - by using
> > the bitmask to show which pixels we have updated.
> >
> > A mask.setrange() method might be useful.  So you can set a range of
> > bits at once, quickly.
>
> Perhaps this can wait until the next release, I think collision
> detection is the main feature, and it may seem overly complicated if
> we add a lot of extra functions. But again, I think you can decide
> this best.
>
> I will start working on this and try to be on irc next wednesday.
>
> Regards,
> UIf
>

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

[René Dudfield]

hi,

I'm in irc now putting bitmask into pygame.

illume is my nick.

Cheers,



On 5/6/07, Ulf Ekström <[EMAIL PROTECTED]> wrote:

Hi.

> Bitmask as a separate module is a good idea.  I think your pygame.mask
> is a good name.  Then we can provide some pygame.sprite mixins, or
> methods to help there.
>
> - pygame.mask module.
> - move docs from the source to .doc file.
> - some unittests in the test/ directory.

Ok, I can do this.

> - move your pygame example to examples/bitmask.py or maybe...
> bouncy_bitmask.py ?

Sure, no problem. I have not even looked at the pygame source tree, so
I don't know how you organize stuff. I will have a look.

> I'm not sure about a surface method.  It might simplify things for
> some people though.  However then it makes surface depend on the
> bitmask module (not necessarily bad).

It is more complicated, but I can imagine it makes it easier to use
for beginners. Anyway, I cannot really help with this part so I leave
it up to you guys.

> Has it been tested on big endian machines?  eg ppc macs?  It looks to
> have checks in there for 64bit machines - has it been tested on 64bit
> machines too?

Yes. The library is used in my game 'Airstrike', which has been tested
on a lot of platforms: sparc, ppc, i386 and even some old amiga
platform. So I think it works. I develop on ppc and i386.

> 'maskFromSurface' might be a constructor argument?  This would be so
> common, that we should do our own implementation.

Yes. It is also much faster in C than in Python. I can't really think
of a good set of arguments to the constructor that allows for either
(width,height) or a surface, though.

 Do you think it
> would be very different for different games?  eg, using different
> alpha levels as 'empty'.  5% alpha might be considered to be gone by
> some games/sprites.  If you think that's useful, an alpha_threshold
> argument might be appropriate.

I think it's a good idea. It can default to 50%.

> As you suggest, there's lots of other uses for bitmasks, other than collision.
>
> Blitting surfaces masked with a bitmask might be a future application.
>  Another future application might be to reduce over draw - by using
> the bitmask to show which pixels we have updated.
>
> A mask.setrange() method might be useful.  So you can set a range of
> bits at once, quickly.

Perhaps this can wait until the next release, I think collision
detection is the main feature, and it may seem overly complicated if
we add a lot of extra functions. But again, I think you can decide
this best.

I will start working on this and try to be on irc next wednesday.

Regards,
UIf

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

[Ulf Ekström]

Hi.


Bitmask as a separate module is a good idea.  I think your pygame.mask
is a good name.  Then we can provide some pygame.sprite mixins, or
methods to help there.

- pygame.mask module.
- move docs from the source to .doc file.
- some unittests in the test/ directory.


Ok, I can do this.


- move your pygame example to examples/bitmask.py or maybe...
bouncy_bitmask.py ?


Sure, no problem. I have not even looked at the pygame source tree, so
I don't know how you organize stuff. I will have a look.


I'm not sure about a surface method.  It might simplify things for
some people though.  However then it makes surface depend on the
bitmask module (not necessarily bad).


It is more complicated, but I can imagine it makes it easier to use
for beginners. Anyway, I cannot really help with this part so I leave
it up to you guys.


Has it been tested on big endian machines?  eg ppc macs?  It looks to
have checks in there for 64bit machines - has it been tested on 64bit
machines too?


Yes. The library is used in my game 'Airstrike', which has been tested
on a lot of platforms: sparc, ppc, i386 and even some old amiga
platform. So I think it works. I develop on ppc and i386.


'maskFromSurface' might be a constructor argument?  This would be so
common, that we should do our own implementation.


Yes. It is also much faster in C than in Python. I can't really think
of a good set of arguments to the constructor that allows for either
(width,height) or a surface, though.

Do you think it

would be very different for different games?  eg, using different
alpha levels as 'empty'.  5% alpha might be considered to be gone by
some games/sprites.  If you think that's useful, an alpha_threshold
argument might be appropriate.


I think it's a good idea. It can default to 50%.


As you suggest, there's lots of other uses for bitmasks, other than collision.

Blitting surfaces masked with a bitmask might be a future application.
 Another future application might be to reduce over draw - by using
the bitmask to show which pixels we have updated.

A mask.setrange() method might be useful.  So you can set a range of
bits at once, quickly.


Perhaps this can wait until the next release, I think collision
detection is the main feature, and it may seem overly complicated if
we add a lot of extra functions. But again, I think you can decide
this best.

I will start working on this and try to be on irc next wednesday.

Regards,
UIf

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

[René Dudfield]

hello,


here's a few thoughts on what could change...


Bitmask as a separate module is a good idea.  I think your pygame.mask
is a good name.  Then we can provide some pygame.sprite mixins, or
methods to help there.

- pygame.mask module.
- move docs from the source to .doc file.
- some unittests in the test/ directory.
- move your pygame example to examples/bitmask.py or maybe...
bouncy_bitmask.py ?

I'm not sure about a surface method.  It might simplify things for
some people though.  However then it makes surface depend on the
bitmask module (not necessarily bad).

Has it been tested on big endian machines?  eg ppc macs?  It looks to
have checks in there for 64bit machines - has it been tested on 64bit
machines too?


'maskFromSurface' might be a constructor argument?  This would be so
common, that we should do our own implementation.  Do you think it
would be very different for different games?  eg, using different
alpha levels as 'empty'.  5% alpha might be considered to be gone by
some games/sprites.  If you think that's useful, an alpha_threshold
argument might be appropriate.

As you suggest, there's lots of other uses for bitmasks, other than collision.

Blitting surfaces masked with a bitmask might be a future application.
Another future application might be to reduce over draw - by using
the bitmask to show which pixels we have updated.

A mask.setrange() method might be useful.  So you can set a range of
bits at once, quickly.




On 5/4/07, Ulf Ekström <[EMAIL PROTECTED]> wrote:

Hi again.

> This is the time we are in irc weekly for dev stuff.  Otherwise I idle
> in the channel, but don't really look in that often.

Ok, I will try to catch that time next week. In the meantime is there
anything I should do? One question is how tightly you want to
integrate the mask stuff into pygame. I imagine that
pygame.sprite.spritecollide should somehow be made to work with the
masks, but it could also be a stand alone module, "pygame.mask" or
something.

One way to do it is to completely hide the mask, and just implement an
surface.overlap(anothersurface, offset). This would automatically
create masks when needed for each surface, based on the alpha channel
or colorkey of the surface. The problem with this is that sometimes
you like to have masks which are not really related to an image, for
example an "area of effect", but on the other hand it would be very
easy to use for the majority of cases.

Another way to do it is to just add the current bitmask module to
pygame, then the programmer has to create the masks himself, but
things are more flexible and the implementation is easier.

Which approach do you prefer?

Regards,
Ulf

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

[Ulf Ekström]

Hi again.


This is the time we are in irc weekly for dev stuff.  Otherwise I idle
in the channel, but don't really look in that often.


Ok, I will try to catch that time next week. In the meantime is there
anything I should do? One question is how tightly you want to
integrate the mask stuff into pygame. I imagine that
pygame.sprite.spritecollide should somehow be made to work with the
masks, but it could also be a stand alone module, "pygame.mask" or
something.

One way to do it is to completely hide the mask, and just implement an
surface.overlap(anothersurface, offset). This would automatically
create masks when needed for each surface, based on the alpha channel
or colorkey of the surface. The problem with this is that sometimes
you like to have masks which are not really related to an image, for
example an "area of effect", but on the other hand it would be very
easy to use for the majority of cases.

Another way to do it is to just add the current bitmask module to
pygame, then the programmer has to create the masks himself, but
things are more flexible and the implementation is easier.

Which approach do you prefer?

Regards,
Ulf

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

[René Dudfield]

Hey,

that's good to hear.

This is the time we are in irc weekly for dev stuff.  Otherwise I idle
in the channel, but don't really look in that often.

nick: illume

AU: Wednesday 6am
Germany: Tuesday 10pm
UK: Tuesday 9pm
US Eastern: Tuesday 4pm
US Pacific: Tuesday 1pm
http://www.worldtimeserver.com/convert_time_in_AU-VIC.aspx?h=6&mn=0




On 5/3/07, Ulf Ekström <[EMAIL PROTECTED]> wrote:

[..]

> I would like to include it in pygame - so people don't need to do
> another install.  Would this be ok?

[..]

That would be just what I was looking for :-). I am not completely
sure of the python binding code, so please have a careful look at it.

What timezone are you in, for irc?

Ulf

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

[Ulf Ekström]

[..]


I would like to include it in pygame - so people don't need to do
another install.  Would this be ok?


[..]

That would be just what I was looking for :-). I am not completely
sure of the python binding code, so please have a careful look at it.

What timezone are you in, for irc?

Ulf

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

[René Dudfield]

hello,

very cool!

I would like to include it in pygame - so people don't need to do
another install.  Would this be ok?

I'll be hanging out in irc next week if you want to talk about it.
details here: http://www.pygame.org/wiki/todo

Or just email any time.

Cheers,



On 4/4/07, Ulf Ekström <[EMAIL PROTECTED]> wrote:

Hi all,
I have written a Python wrapper for my pixel perfect collision detection library
"bitmask". It can be easily used together with Pygame, and there is an
example in the tarball which bounces some sprites against each other.
However, this is my first attempt at writing python wrappers, and I
would really appreciate it if someone could have a look at the wrapper
code (it seems to be slightly shaky).

Get the (prerelease) library at http://fluff.dyndns.org/bitmask-1.7b.tar.gz

I hope this can be useful for someone, and I am very interested in
seeing fast pixel perfect
collision detection in pygame itself.

Regards,
Ulf

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

[Ulf Ekström]

Hi all,
I have written a Python wrapper for my pixel perfect collision detection library
"bitmask". It can be easily used together with Pygame, and there is an
example in the tarball which bounces some sprites against each other.
However, this is my first attempt at writing python wrappers, and I
would really appreciate it if someone could have a look at the wrapper
code (it seems to be slightly shaky).

Get the (prerelease) library at http://fluff.dyndns.org/bitmask-1.7b.tar.gz

I hope this can be useful for someone, and I am very interested in
seeing fast pixel perfect
collision detection in pygame itself.

Regards,
Ulf