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