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