[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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 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...@xxxxxxxxx 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.