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

[Greg Ewing]

René Dudfield wrote:

So it might be nice to return the length(magnitude) there?


BTW, I don't really like the name "length" for a function
that returns the magnitude of an arbitrary vector. It only
makes sense for vectors representing a physical distance;
it's nonsense for anything else (velocity, acceleration,
electric field, etc.)

--
Greg

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

[René Dudfield]

Having normalize_ip return the old length would be a bit weird.
Yeah, another name like 'normalize_ip_return_length' But maybe longer ;)
speed = direction.length_normalize_ip()

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

[René Dudfield]

What is UP for rock climbers hanging upside down,
when they are chatting on their phone,
which points towards the horizon,
whilst they live in Australia? ;)

( @Ian... give in to the temptation... )




Thanks Victor, those are some good notes.
And I guess some of them will take some time to figure out how to handle
them nicely.


1) Ok, right. I'll add that to the list.
http://www.pymunk.org/en/latest/_modules/pymunk/vec2d.html#Vec2d.normalize_return_length

That's useful because...
when you want to keep the length (as a speed),
but normalize the vector to be used just as a direction.

This would be like normalize_ip in the pygame vector.
  http://www.pygame.org/docs/ref/math.html#pygame.math.Vector2.normalize_ip

'normalize_ip' currently returns None.
So it might be nice to return the length(magnitude) there?

'normalize` returns a copy of the vector.



2) scaling back up from 0 does indeed seem hard.
Would it need to be only after it was scaled down?
Perhaps adding the last value would be useful.
But then, there are many ways a vector can come to be at zero.

3) perhaps some assumption could be used about screen->world coordinates
could be baked in.

Or some property of the vector,
vec2(0, 1).asGL??? -> vec2(0, -1)

Swizzle convention?
vec2(0, 1).xY -> vec2(0, -1)

Not sure really.

draw.circle says,
  "Give me the coordinates in pygame screen coordinates? Please." -> (0, 1)



4) oh yes, draw functions. Very good point.

Automatic rounding in the draw functions seem a good idea.
I'll include drawing a circle in my example I'm writing,
and perhaps modernise circle drawing first.

What would a pygame.draw.vector2 look like? draw.vector3?



5) I didn't try benchmarking with pypy.
I expect they'll have similar performance to other pygame C types like Rect.

Not sure if they have optimized keyword arguments(METH_KEYWORDS),
 as much as they have METH_NOARGS and METH_VARARGS.

I'm going to the pypy sprint in Leysin, and should get a benchmark ready by
then.





On Thu, Mar 1, 2018 at 10:17 AM, Ian Mallett  wrote:

> 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: [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] updated homebrew package for newer OSX versions?

[René Dudfield]

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

On Fri, Mar 2, 2018 at 9:13 AM, illume  wrote:

> Hi Sean,
>
> No one is, as far as I'm aware.
> There used to be one, but homebrew removed all python packages I think.
> You can probably find the previous maintainers with some searching.
>
> Happy to help you out if you need it.
>
> The mac homebrew compile instructions are here:
> https://www.pygame.org/wiki/MacCompile#Installing%20from%
> 20source%20with%20homebrew
>
>
> Note, we currently recommend people use this to install stuff.
> python3 -m pip -U install pygame --user
>
> With a whole bunch of platform specific notes at:
> https://www.pygame.org/wiki/GettingStarted
>
> That doesn't install into the system folder, but into a user folder.
> It's unfortunate that pip still destroys stuff by default.
>
>
> ps. it looks like you need to sign up to the mailing list at:
> https://www.pygame.org/wiki/info#Mailing%20List
> Seems your post is just on the google mirror of the mailing list.
> Sorry for the confusion.
>
>
>
> On Sunday, February 18, 2018 at 4:07:59 AM UTC+1, SeanSF wrote:
>>
>> Hey all, so it appears that installing pygame on the newer OSX versions
>> is extremely problematic. On a friend's computer I tried pip and
>> easy_install, and both ran into conflicts with the system python and
>> root/nonroot install paths.
>>
>> Rather than get into the specific problem here, can I ask the simple
>> question -- is anybody working on or actively maintaining a an OSX homebrew
>> tap for pygame? If not, I might jump into the fray and give it a shot.
>>
>> This way we can get back to just 'brew install python-pygame' and you're
>> done.
>>
>> --
>> A musician must make music, an artist must paint, a poet must write, if
>> he is to be ultimately at peace with himself.
>> - Abraham Maslow
>>
>

Re: [pygame] Re: Stange behavior with sound or MPC

[René Dudfield]

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

On Fri, Mar 2, 2018 at 8:54 AM, illume  wrote:

> 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] updated homebrew package for newer OSX versions?

[illume]

Hi Sean,

No one is, as far as I'm aware.
There used to be one, but homebrew removed all python packages I think.
You can probably find the previous maintainers with some searching.

Happy to help you out if you need it.

The mac homebrew compile instructions are here:
https://www.pygame.org/wiki/MacCompile#Installing%20from%20source%20with%20homebrew


Note, we currently recommend people use this to install stuff.
python3 -m pip -U install pygame --user

With a whole bunch of platform specific notes at:
https://www.pygame.org/wiki/GettingStarted

That doesn't install into the system folder, but into a user folder.
It's unfortunate that pip still destroys stuff by default.


ps. it looks like you need to sign up to the mailing list at:
https://www.pygame.org/wiki/info#Mailing%20List
Seems your post is just on the google mirror of the mailing list.
Sorry for the confusion.


On Sunday, February 18, 2018 at 4:07:59 AM UTC+1, SeanSF wrote:
>
> Hey all, so it appears that installing pygame on the newer OSX versions is 
> extremely problematic. On a friend's computer I tried pip and easy_install, 
> and both ran into conflicts with the system python and root/nonroot install 
> paths.
>
> Rather than get into the specific problem here, can I ask the simple 
> question -- is anybody working on or actively maintaining a an OSX homebrew 
> tap for pygame? If not, I might jump into the fray and give it a shot.
>
> This way we can get back to just 'brew install python-pygame' and you're 
> done.
>
> -- 
> A musician must make music, an artist must paint, a poet must write, if he 
> is to be ultimately at peace with himself.
> - Abraham Maslow
>