Re: [pygame] extending pygame masks

["Nirav Patel" <olpc@xxxxxxxxxxxxxx>]

It's not necessarily a good idea to have stuff that specific to an app
in a library.  I think it would be good to have the convolution
function built into mask, and leave the rest of the implementation up
to the user.  As for how to deal with the interface for convolving,
perhaps it would be useful to have one of the masks specified as being
the "world", and the other as the object being moved? Something like:
Mask.convolve(world = Mask) returning a mask the size of the world mask.

It would be fairly easy to construct this world mask by using Mask.draw.

Of course, its not really up to me.  Anyone else with opinions on the
matter, feel free to chime in.

Nirav

On Wed, Oct 15, 2008 at 1:04 PM, Michael George <mdgeorge@xxxxxxxxxxxxxx> wrote:
> Would it make sense for me to build this right into the Mask module and send
> you a patch then, or would it be better for me to develop it separately as I
> have been and share the source with you when it's finished so that you can
> put it together?
>
> I'm still not entirely sure about the interface I want to provide.  The
> problem is computing the corresponding rects.  Let's say you have an
> obstacle with rect a and are dragging an object with rect b.  Then the
> output should have rect c where
>
> c.top    = a.top    - b.bottom
> c.bottom = a.bottom - b. top
> c.left   = a.left   - b.right
> c.right  = a.right  - b.left
>
> (this might be off-by-one somewhere..probably need a -1 in c.bottom and
> c.left).  This would mean the bit of c corresponding to (x,y) would be set
> if b were translated by (x,y).  The reason this all presents a problem is
> because masks don't have associated rects, but I'd rather not leave it to
> the user to do the math.  Probably the right thing to do is provides
> something that takes a pair of sprites with rect and mask fields and outputs
> a sprite.
>
> The other problem is that for my application I'd like to apply this to many
> sprites all at once and then compute the overlay.  It would be more
> efficient to compute this all in one go since the intermediate masks could
> be avoided.  Probably the right thing then is to provide a function to
> compute the hitmask of a whole sprite group.
>
> So I guess I've answered my own question.  The interface should consist of
> two functions:
>
> hitmask(Sprite)     :: Sprite  Return a sprite with the rect and mask
> attributes set
> grouphitmask(Group) :: Sprite  Return a sprite with the rect and mask
> attributes set, containing the union of the hitmasks for the group
>
> What do you think?  Also, if you do want me to add this to pygame, should it
> go in the mask module or the sprite module?
>
> --Mike
>
> Nirav Patel wrote:
>>
>> Mike
>>
>> Ah, very interesting. Can I see the source on that?  I would love to
>> see that included in the Mask module.
>>
>> Nirav
>>
>
>