... and replying on the pygame-users mailing list. On Fri, Mar 2, 2018 at 8:38 AM, illume <ren...@gmail.com> 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. >>> >>
