Re: [pygame] extending pygame masks

["Nirav Patel" <olpc@xxxxxxxxxxxxxx>]

You can use the diff command to generate patches, but if its easier
for you, you can just upload or email the files you changed.

Nirav

On Fri, Oct 17, 2008 at 6:57 PM, Michael George <mdgeorge@xxxxxxxxxxxxxx> wrote:
> I added a convolve function with the proposed interface, as well as docs and
> a handful of unit tests.  How do I generate and submit a patch?
>
> --Mike
>
> René Dudfield wrote:
>>
>> Sounds cool.
>>
>> Remember to also write unittests  :)  The mask module is falling
>> behind it unittests at the moment.
>>
>> cheers!
>>
>>
>> On Thu, Oct 16, 2008 at 5:40 AM, Michael George <mdgeorge@xxxxxxxxxxxxxx>
>> wrote:
>>
>>>
>>> Nirav Patel wrote:
>>>
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>
>>> I think it makes more sense to do it the other way - world.convolve(obj)
>>> rather than obj.convolve(world).  The two are flips of each other anyway,
>>> so
>>> it's probably not a big deal.  In either case, the output needs to be
>>> bigger
>>> than both of the inputs (the size of the convolution is the sum of the
>>> sizes
>>> of the inputs, minus one).
>>>
>>> I guess it's not too hard to compute the rects if you're careful.
>>>
>>>>
>>>> It would be fairly easy to construct this world mask by using Mask.draw.
>>>>
>>>>
>>>>
>>>
>>> Yeah, that's probably best.  In fact, I was thinking that I might need to
>>> do
>>> it that way anyway.  The only reason to do it for a collection in one go
>>> is
>>> that you can avoid allocating all of those intermediate masks, and
>>> shifting
>>> everything twice.  I guess masks are pretty small and shifts are pretty
>>> fast
>>> so it's not such a big deal.
>>>
>>> So here's a revised proposal:
>>>
>>> Mask.convolve(other = Mask): return Mask
>>>  compute the convolution of self and other.  The (x,y) bit of the return
>>> value will be set if shifting the lower-right corner of other to position
>>> (x,y) would cause it to overlap with self.  The return value has size
>>> equal
>>> to self.getsize() + other.getsize() - (1,1).
>>>
>>>
>>> (and possibly)
>>> Mask.convolve(other = Mask, world = Mask, offset = (x,y)): return None
>>>  Functionally the same as world.union(self.convolve(other), offset) but
>>> more efficient
>>>
>>> Then the stuff that computes the rectangles and masks for a sprite group
>>> would be up to the application developer (i.e. me).
>>>
>>> On a side note, does Mask.draw do an "or" or a copy of the two masks?
>>>  They're probably both useful.  Assuming it's a copy, I've used
>>> world.union
>>> to denote orring the bitmasks.
>>>
>>> --Mike
>>>
>>>
>
>