[pygame] Re: Stange behavior with sound or MPC

[illume]

Hello,

It looks like the google mailing list mirror isn't sending emails back to 
the pygame mailing list for you.

I wonder if it is because you are not signed up to here?
https://www.pygame.org/wiki/info#Mailing%20List

You should be able to send an email to majord...@seul.org with the body, 
subscribe pygame-users

   - subscribe pygame-users 
    


cheers,




On Thursday, February 22, 2018 at 9:49:58 AM UTC+1, Marius Liebenberg wrote:
>
> Hi
> I am using a Pi2 with Jessie setup to use a 2.8" TFT Touch display.
>
> Pygame come installed and I did update to the latest version.
>
> I installed two different internet radio players that make use of a 
> subprocess call to control MPC / MPD player. Here is the strange thing that 
> both applications experience.When loaded first time I can hear the sound 
> being activated but no sound is produced. The MPC output reports the app 
> functioning correctly and playing. If I quit the application the sound will 
> be produced. MPD is a daemon loaded at boot time and PMC is a frontend to 
> comtrol MPD. It has simple commands to play stop set volume etc. It reports 
> the successful actions as they are executed throughout. If I load the 
> python ap from a SSH terminal (remote) it now plays and controls the player 
> correctly. All the functions work on the first load but no sound is 
> produced. 
>
> The app is load with this script
>
> #!/bin/sh
> cd /home/pi/pi-radio
> sudo python radioplayer.py
>
> and I put a call to the script in the /etc/rc.local file at the end.
>
> Anyone that can shed some light please?
>

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] Pre-release wheels

[René Dudfield]

Ok. I think I have it figured out how to do this.

"Pre release wheels through pip"
https://github.com/pygame/pygame/issues/409

If there's any python packaging experts floating by...
Is this how it should be done?


cheers,

Re: [pygame] Pre-release wheels

[René Dudfield]

Thanks for the report.

Anyone else able to reproduce weirdo-mouse coordinates on OSX Sierra/High
Sierra?

brew upgrade sdl sdl_image sdl_mixer sdl_ttf portmidi
python3.6 -m venv anenv
. ./anenv/bin/activate
pip install https://github.com/pygame/pygame/archive/master.zip

wget 
https://gist.githubusercontent.com/illume/b87911469c4e59db387defa09118fff3/raw/b07cae540d069a87639e103ab6f6f5b631d035be/weirdomouse.py

python weirdomouse.py


Close to this top left: wrote:

> Last night at the London Python Dojo I was working with a couple of Pygame
> newbies on a little snow game (https://github.com/lordmauve/snowgame)
> when we came across this bug on Dario's Mac:
>
> https://github.com/pygame/pygame/issues/380
>
> This is an awful bug for beginners. It really looked so much like we had
> done something wrong, storing the mouse coordinates wrongly, because the
> lines we were dragging were starting from the last line, not the position
> of the mouse at mouse down. We checked over our code several times before
> realising that it worked on one of the other Macs, so something must be up
> with Pygame.
>
> I was going to ask Dario to check a Pygame 1.9.4 pre-release but there are
> no wheels on PyPI. It would be great if we could get wheels onto PyPI so
> that we can start testing on more systems. pip doesn't consider pre-release
> versions for installation unless you specify --pre on the command line so
> this wouldn't interfere with getting the stable version normally.
>
> Dan
>

[pygame] Pre-release wheels

[Daniel Pope]

Last night at the London Python Dojo I was working with a couple of Pygame
newbies on a little snow game (https://github.com/lordmauve/snowgame) when
we came across this bug on Dario's Mac:

https://github.com/pygame/pygame/issues/380

This is an awful bug for beginners. It really looked so much like we had
done something wrong, storing the mouse coordinates wrongly, because the
lines we were dragging were starting from the last line, not the position
of the mouse at mouse down. We checked over our code several times before
realising that it worked on one of the other Macs, so something must be up
with Pygame.

I was going to ask Dario to check a Pygame 1.9.4 pre-release but there are
no wheels on PyPI. It would be great if we could get wheels onto PyPI so
that we can start testing on more systems. pip doesn't consider pre-release
versions for installation unless you specify --pre on the command line so
this wouldn't interfere with getting the stable version normally.

Dan

Re: [SPAM: 6.600] Re: [pygame] Re: removing 'experimental' notice from pygame.math

[Ian Mallett]

On Thu, Mar 1, 2018 at 1:43 AM, Greg Ewing 
wrote:

> No, no, no. Z points up in real physics!


Oh, and I expect "j" is the imaginary unit, "Σ"s can be omitted, gravity is
exactly 10 m/s, without the square, and anyway one can drop units whenever
one feels like it?
( Must. Resist. Temptation. To. Rant. . . )

Re: [SPAM: 6.600] Re: [pygame] Re: removing 'experimental' notice from pygame.math

[Greg Ewing]

Daniel Pope wrote:


Y points up in real physics?


No, no, no. Z points up in real physics!

--
Greg