Re: [pygame] BUG: Mask.overlap_mask

[René Dudfield]

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.
>
> https://github.com/pygame/pygame/issues/410
>
> On Fri, Mar 2, 2018 at 10:42 AM, Rybec Arethdar 
> wrote:
>
>> If my student does not post the information on Github, I will see if I
>> can write up a simple program to reproduce it, and I will post it there.
>> As it is, I don't have the code, however we worked together on it for half
>> an hour yesterday, and while there were some bugs in his code initially, by
>> the end we had everything relevant to this worked out.
>>
>> Once there is more information on Github, I'll drop a note here.
>>
>> On Fri, Mar 2, 2018 at 1:16 AM, René Dudfield  wrote:
>>
>>> ... 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 collision detection.An d even making videos about it.
 That's pretty advanced!

 So, what's next for getting this issue fixed?


 You've already linked to some existing discussion on the issue,
 that's a good start! There's even code in there. Brilliant.

 But what even is a mask, and an overlap?


 Another thing people can do is link to the relevant code in
 the pygame source code. This means they don't need to look
 themselves, and it helps them get to the task quicker.

 Remember, the person fixing the code might never have seen
 or even used the code before.

 Documentation for mask overlap stuff lives here:
   https://www.pygame.org/docs/ref/mask.html#pygame.mask.Mask.overlap

 Implementation of bitmask overlap (src/bitmask.c in pygame repo).
   https://github.com/pygame/pygame/blob/master/src/bitmask.c#L161

 The unit test is here (test/mask_test.py in the pygame repo):
   https://github.com/pygame/pygame/blob/master/test/mask_test.py#L74


 So, now they know where to look for what it does, and where in
 the code base they can write a test for it, or change the code.


 But is it even a bug? Having your students writing a unit test
 for their own code will help them check all their assumptions,
 and also see if it's a problem with the mask overlap code or
 a problem somewhere else.

 Being able to reproduce the issue makes it easier for anyone
 coming along to fix it. If not a unit test, then a short script,
 or minimal working example pasted into the issue will help with that.

 Sometimes a visual example with an explanation is best.

 Screenshots, screenshots, and more screenshots.
 Or a video, are all useful in helping people understand what's
 going on.



 Mostly people only get a hour or two here and there on weekends
 or late nights to mess around with pygame, it really helps the
 next person to not drop the ball again.

 Anything to help them see how it's not working correctly will
 help the next person fix it.


 cheers,





 On Friday, March 2, 2018 at 7:46:13 AM UTC+1, ...@gmail.com wrote:
>
> I just found the Pygame Github repository.  I'll make sure the issue
> gets reported there.
>
> On Thursday, March 1, 2018 at 11:42:40 PM UTC-7, rybeca...@gmail.com
> wrote:
>>
>> So, *five years later* this bug still exists.  I use Pygame to teach
>> a college video game course, and I have a student having what appears to 
>> be
>> this exact same issue.  Sadly, the OP never bothered to file that bug
>> report.
>>
>> I don't see any way to post a report at that link, which may be why
>> the bug report was never filed.  I will explain what we are seeing 
>> though.
>>
>> My student started with a YouTube video, showing how to do pixel
>> perfect collision detection with Pygame masks.  Several students have had
>> success with this.  This particular student decided that he wanted to
>> recolor one of the images, to display exactly where it is overlapping
>> another image.  Unfortunately, the recoloring behavior is totally 
>> erratic.
>> The parts of the image that are being recolored based on the overlap mask
>> produced are very inconsistent.  Moving the top image even slightly can
>> dramatically change what pixels are marked as colliding.  The only
>> consistent thing is that pixels that are *not* colliding are never
>> marked as colliding, however pixels that *are* colliding are not

Re: [pygame] BUG: Mask.overlap_mask

[René Dudfield]

... 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 collision detection.An d even making videos about it.
> That's pretty advanced!
>
> So, what's next for getting this issue fixed?
>
>
> You've already linked to some existing discussion on the issue,
> that's a good start! There's even code in there. Brilliant.
>
> But what even is a mask, and an overlap?
>
>
> Another thing people can do is link to the relevant code in
> the pygame source code. This means they don't need to look
> themselves, and it helps them get to the task quicker.
>
> Remember, the person fixing the code might never have seen
> or even used the code before.
>
> Documentation for mask overlap stuff lives here:
>   https://www.pygame.org/docs/ref/mask.html#pygame.mask.Mask.overlap
>
> Implementation of bitmask overlap (src/bitmask.c in pygame repo).
>   https://github.com/pygame/pygame/blob/master/src/bitmask.c#L161
>
> The unit test is here (test/mask_test.py in the pygame repo):
>   https://github.com/pygame/pygame/blob/master/test/mask_test.py#L74
>
>
> So, now they know where to look for what it does, and where in
> the code base they can write a test for it, or change the code.
>
>
> But is it even a bug? Having your students writing a unit test
> for their own code will help them check all their assumptions,
> and also see if it's a problem with the mask overlap code or
> a problem somewhere else.
>
> Being able to reproduce the issue makes it easier for anyone
> coming along to fix it. If not a unit test, then a short script,
> or minimal working example pasted into the issue will help with that.
>
> Sometimes a visual example with an explanation is best.
>
> Screenshots, screenshots, and more screenshots.
> Or a video, are all useful in helping people understand what's
> going on.
>
>
>
> Mostly people only get a hour or two here and there on weekends
> or late nights to mess around with pygame, it really helps the
> next person to not drop the ball again.
>
> Anything to help them see how it's not working correctly will
> help the next person fix it.
>
>
> cheers,
>
>
>
>
>
> On Friday, March 2, 2018 at 7:46:13 AM UTC+1, ...@gmail.com wrote:
>>
>> I just found the Pygame Github repository.  I'll make sure the issue gets
>> reported there.
>>
>> On Thursday, March 1, 2018 at 11:42:40 PM UTC-7, rybeca...@gmail.com
>> wrote:
>>>
>>> So, *five years later* this bug still exists.  I use Pygame to teach a
>>> college video game course, and I have a student having what appears to be
>>> this exact same issue.  Sadly, the OP never bothered to file that bug
>>> report.
>>>
>>> I don't see any way to post a report at that link, which may be why the
>>> bug report was never filed.  I will explain what we are seeing though.
>>>
>>> My student started with a YouTube video, showing how to do pixel perfect
>>> collision detection with Pygame masks.  Several students have had success
>>> with this.  This particular student decided that he wanted to recolor one
>>> of the images, to display exactly where it is overlapping another image.
>>> Unfortunately, the recoloring behavior is totally erratic.  The parts of
>>> the image that are being recolored based on the overlap mask produced are
>>> very inconsistent.  Moving the top image even slightly can dramatically
>>> change what pixels are marked as colliding.  The only consistent thing is
>>> that pixels that are *not* colliding are never marked as colliding,
>>> however pixels that *are* colliding are not consistently marked as
>>> colliding.  When the mobile image is stationary, the pixels marked as
>>> colliding don't change, but a movement of 1 pixel in any direction can
>>> dramatically change what is marked as colliding and what is not.  Moving
>>> the mobile image rapidly back and forth over the stationary one appears to
>>> reveal vertical divisions, where pixels on one side are more likely to be
>>> marked as colliding than pixels on the other.  I did not observe horizontal
>>> divisions like this, though I could have missed them.
>>>
>>> Anyhow, someone *please* file a report for this bug!  It clearly should
>>> have been done 5 years ago, but someone obviously dropped the ball.
>>>
>>

Re: [pygame] BUG: Mask.overlap_mask

[illume]

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 already linked to some existing discussion on the issue,
that's a good start! There's even code in there. Brilliant.

But what even is a mask, and an overlap?


Another thing people can do is link to the relevant code in
the pygame source code. This means they don't need to look
themselves, and it helps them get to the task quicker.

Remember, the person fixing the code might never have seen
or even used the code before.

Documentation for mask overlap stuff lives here:
  https://www.pygame.org/docs/ref/mask.html#pygame.mask.Mask.overlap

Implementation of bitmask overlap (src/bitmask.c in pygame repo).
  https://github.com/pygame/pygame/blob/master/src/bitmask.c#L161

The unit test is here (test/mask_test.py in the pygame repo):
  https://github.com/pygame/pygame/blob/master/test/mask_test.py#L74


So, now they know where to look for what it does, and where in 
the code base they can write a test for it, or change the code.


But is it even a bug? Having your students writing a unit test
for their own code will help them check all their assumptions,
and also see if it's a problem with the mask overlap code or
a problem somewhere else.

Being able to reproduce the issue makes it easier for anyone
coming along to fix it. If not a unit test, then a short script,
or minimal working example pasted into the issue will help with that.

Sometimes a visual example with an explanation is best.

Screenshots, screenshots, and more screenshots.
Or a video, are all useful in helping people understand what's
going on.



Mostly people only get a hour or two here and there on weekends
or late nights to mess around with pygame, it really helps the
next person to not drop the ball again.

Anything to help them see how it's not working correctly will
help the next person fix it.


cheers,





On Friday, March 2, 2018 at 7:46:13 AM UTC+1, ...@gmail.com wrote:
>
> I just found the Pygame Github repository.  I'll make sure the issue gets 
> reported there.
>
> On Thursday, March 1, 2018 at 11:42:40 PM UTC-7, rybeca...@gmail.com 
> wrote:
>>
>> So, *five years later* this bug still exists.  I use Pygame to teach a 
>> college video game course, and I have a student having what appears to be 
>> this exact same issue.  Sadly, the OP never bothered to file that bug 
>> report.
>>
>> I don't see any way to post a report at that link, which may be why the 
>> bug report was never filed.  I will explain what we are seeing though.
>>
>> My student started with a YouTube video, showing how to do pixel perfect 
>> collision detection with Pygame masks.  Several students have had success 
>> with this.  This particular student decided that he wanted to recolor one 
>> of the images, to display exactly where it is overlapping another image.  
>> Unfortunately, the recoloring behavior is totally erratic.  The parts of 
>> the image that are being recolored based on the overlap mask produced are 
>> very inconsistent.  Moving the top image even slightly can dramatically 
>> change what pixels are marked as colliding.  The only consistent thing is 
>> that pixels that are *not* colliding are never marked as colliding, 
>> however pixels that *are* colliding are not consistently marked as 
>> colliding.  When the mobile image is stationary, the pixels marked as 
>> colliding don't change, but a movement of 1 pixel in any direction can 
>> dramatically change what is marked as colliding and what is not.  Moving 
>> the mobile image rapidly back and forth over the stationary one appears to 
>> reveal vertical divisions, where pixels on one side are more likely to be 
>> marked as colliding than pixels on the other.  I did not observe horizontal 
>> divisions like this, though I could have missed them.
>>
>> Anyhow, someone *please* file a report for this bug!  It clearly should 
>> have been done 5 years ago, but someone obviously dropped the ball.
>>
>

Re: [pygame] BUG: Mask.overlap_mask

[Russell Jones]

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:

 Hello together,

 Mask.overlap_mask does not what it is supposed to do. In the following
 example, the two counts that are output should be the same. The second one
 is the one from overlap_mask. I have no clue what goes wrong there, since
 the results does not make any sense to me.

 Please let me know how I can get the correct overlap mask in the case
 below.

 Thanks,
 Florian



 import pygame

 pygame.init()
 pygame.display.init()
 pygame.display.set_mode((800, 600))
 s1 = pygame.Surface((100, 100)).convert_alpha()
 s2 = pygame.Surface((200, 200)).convert_alpha()
 s1.fill((0,0,0))
 s2.fill((0,0,0))

 m1 = pygame.mask.from_surface(s1)
 m2 = pygame.mask.from_surface(s2)

 print m1.overlap_area(m2, (-150, 50))
 print m1.overlap_mask(m2, (-150, 50)).count()




 --
 www.fladd.de - Homepage of Florian Krause

Re: [pygame] BUG: Mask.overlap_mask

[Russell Jones]

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, 7728, 7462, 7200, 6942,
6688, 6438, 6192, 5950, 5712, 5478, 5248, 5022, 4800, 4582, 4368, 4158,
3952, 3750, 3552, 3358, 3168, 2982, 2800, 2622, 2448, 2278, 2112, 1950,
1792, 1701, 1612, 1525, 1440, 1357, 1276, 1197, 1120, 1045, 972, 901, 832,
765]

prev = 1
for y in [m1.overlap_mask(m2, (x, x)).count() for x in range(50)]:
 print(prev - y, end=', ')
 prev = y
0, 298, 294, 290, 286, 282, 278, 274, 270, 266, 262, 258, 254, 250, 246,
242, 238, 234, 230, 226, 222, 218, 214, 210, 206, 202, 198, 194, 190, 186,
182, 178, 174, 170, 166, 162, 158, 91, 89, 87, 85, 83, 81, 79, 77, 75, 73,
71, 69, 67,

You can file a bug at the link below, I couldn't find any existing issues
mentioning overlap_mask with a quick search.
https://bitbucket.org/pygame/pygame/issues

Russell


On 5 July 2014 21:26, Russell Jones russell.jo...@gmail.com wrote:

 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:

 Hello together,

 Mask.overlap_mask does not what it is supposed to do. In the following
 example, the two counts that are output should be the same. The second one
 is the one from overlap_mask. I have no clue what goes wrong there, since
 the results does not make any sense to me.

 Please let me know how I can get the correct overlap mask in the case
 below.

 Thanks,
 Florian



 import pygame

 pygame.init()
 pygame.display.init()
 pygame.display.set_mode((800, 600))
 s1 = pygame.Surface((100, 100)).convert_alpha()
 s2 = pygame.Surface((200, 200)).convert_alpha()
 s1.fill((0,0,0))
 s2.fill((0,0,0))

 m1 = pygame.mask.from_surface(s1)
 m2 = pygame.mask.from_surface(s2)

 print m1.overlap_area(m2, (-150, 50))
  print m1.overlap_mask(m2, (-150, 50)).count()




 --
 www.fladd.de - Homepage of Florian Krause

[pygame] BUG: Mask.overlap_mask

[Florian Krause]

Hello together,

Mask.overlap_mask does not what it is supposed to do. In the following
example, the two counts that are output should be the same. The second one
is the one from overlap_mask. I have no clue what goes wrong there, since
the results does not make any sense to me.

Please let me know how I can get the correct overlap mask in the case below.

Thanks,
Florian



import pygame

pygame.init()
pygame.display.init()
pygame.display.set_mode((800, 600))
s1 = pygame.Surface((100, 100)).convert_alpha()
s2 = pygame.Surface((200, 200)).convert_alpha()
s1.fill((0,0,0))
s2.fill((0,0,0))

m1 = pygame.mask.from_surface(s1)
m2 = pygame.mask.from_surface(s2)

print m1.overlap_area(m2, (-150, 50))
print m1.overlap_mask(m2, (-150, 50)).count()




-- 
www.fladd.de - Homepage of Florian Krause