Re: [pygame] BUG: Mask.overlap_mask

Thank you very much! On Wed, Mar 7, 2018 at 8:13 PM, Rybec Arethdar wrote: > Alright, I wrote the program. I also modified it in a second version, to > eliminate the use of Surface.set_at() as an explanation for the results. I > posted both programs on Github. > >

Re: [pygame] BUG: Mask.overlap_mask

... and replying on the pygame-users mailing list. On Fri, Mar 2, 2018 at 8:38 AM, illume wrote: > Hello, > > Thanks for picking up the ball. > It must be muddy and old after five years on the ground. > > It's cool that your students are messing around with > per pixel

Re: [pygame] BUG: Mask.overlap_mask

Hello, Thanks for picking up the ball. It must be muddy and old after five years on the ground. It's cool that your students are messing around with per pixel collision detection.An d even making videos about it. That's pretty advanced! So, what's next for getting this issue fixed? You've

Re: [pygame] BUG: Mask.overlap_mask

Might it be that one method assumes a position of (0,0) if none is set, and the other does not? Is the result consistent for the unexpected result? If not, that would suggest the values have not been initialised. Russell On 19 June 2014 16:14, Florian Krause siebenhundertz...@gmail.com wrote:

Re: [pygame] BUG: Mask.overlap_mask

The position of the surface shouldn't matter for a mask, though. The value is curious. It also works with a positive offset. Perhaps these will give some clues as to what's happening: print [m1.overlap_mask(m2, (x, x)).count() for x in range(50)] [1, 9702, 9408, 9118, 8832, 8550, 8272, 7998,