[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

[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

[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)]

[10000, 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 = 10000

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

[rybeca...@gmail.com]

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.

[rybeca...@gmail.com]

I just found the Pygame Github repository.  I'll make sure the issue gets reported there.

[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,

[René Dudfield]

... and replying on the pygame-users mailing list.

[Rybec Arethdar]

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.

--

---
You received this message because you are subscribed to a topic in the Google Groups "pygame mirror on google groups" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pygame-mirror-on-google-groups/8RGH0HIg2o8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pygame-mirror-on-google-groups+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

べん

[Rybec Arethdar]

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

To unsubscribe from this group and all its topics, send an email to pygame-mirror-on-google-groups+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

べん

--

べん

[René Dudfield]

Thank you very much!

You received this message because you are subscribed to the Google Groups "pygame mirror on google groups" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pygame-mirror-on-google-groups+unsubscribe@googlegroups.com.