[pygame] Re: [pygame] Re: [pygame] Tutorial de Chimp traducido al Español.

[Andrew Baker]

Ay, que bueno.  Muchas gracias!

On Sun, Aug 28, 2022, 6:34 AM Лёха <007007007a...@gmail.com> wrote:

> Good work, but I bad understand Spanish and 50/50 understand English
>
> Вс, 28 авг. 2022 г. в 6:23 PM, René Dudfield :
>
>> Hola,
>>
>> Hay una traducción del tutorial de Chimp al español aquí:
>> https://github.com/pygame/pygame/pull/3421
>>
>> De un nuevo colaborador.
>>
>> ¿Es tu español bueno? Por favor, comenta el pull request :)
>>
>> Saludos cordiales,
>>
>

Re: [pygame] Re: Pygame Read MIDI Input

[René Dudfield]

Good!

import pygame.examples.midi
print(pygame.examples.midi.__file__)

Re: [pygame] Re: Starting the pygame 2 series

[Andrew Baker]

Totally awesome!

On Fri, Oct 30, 2020 at 5:15 AM Victor Blomqvist  wrote:

> Congratulations Pygame! Great work by all of you!
>
> On Wed, Oct 28, 2020 at 7:10 PM René Dudfield  wrote:
>
>>
>>  ,--.
>> |  oo|
>> |  ~~| o  o  o  o  o  o  o  o  o  o  o  o  o
>> |/\/\|
>>python3  -m pip install pygame==2.0.0
>>
>> The 28th of October 2020 is the pygame 
>> 2.0 release date, because pygame turns 20 years of age.
>> [image: pygame-head-party.png]
>> What's the best feature of pygame 2? Maybe it's "*backwards
>> compatibility*". For many, many apps pygame 2 is backwards compatible.
>> Have an pygame app from the year 2000? It will probably work. We still have
>> some known issues and open backwards compatibility issues(see below), but a
>> lot of things work just as they did before. Yes, we still have python 2
>> support.
>>
>> How does one summarize the 3306 changes since we started the pygame 2
>> series in July of 2018 based on patches going back to 2012 and even earlier?
>>
>>- Support for Metal, Direct 3d, Vulkan, OpenGL 3.0+ in various
>>profiles (core, compatibility, debug, robust, etc), OpenGL ES, and other
>>modern hardware accelerated video APIs across many platforms.
>>- SSE2/Neon assembly image drawing. Much faster drawing routines,
>>image loading, and alpha blending.
>>- Type Hints, for code completion (and to help you make the squiggly
>>lines disappear) in editors and IDEs.
>>- Code cleanup, using lots of code robustness tools like static
>>analyzers, and automated CI/CD. We've been able to help dozens of people
>>new to community projects contribute. We have lots of work to go on code
>>quality, but we're currently the highest rated Python and highest rate C
>>large project on LGTM.
>>- Many, many bug fixes including in our pygame.draw routines,
>>pygame.math(for vectors), and pygame.mask for pixel perfect collision
>>detection.
>>- better support for pypy (the fast JIT based implementation of
>>python).
>>- libsdl version 2 support. Technically pygame 2.0 still works with
>>SDL 1, but we recommend SDL2 which is vastly improved over SDL1 for most
>>use cases. Probably we will remove SDL 1 support starting pygame 2.1.
>>- Touch support (multitouch, gestures, etc)
>>- Audio input support (make games with your microphone!).
>>- Message alert boxes (Press OK, or Cancel).
>>- Better keyboard support. Proper unicode input and IME support.
>>- Much improved game controller support.
>>- Better image and audio format support. Including: webp, 32bit wav
>>files, and much more reliable mp3 support.
>>- Multiple display support, and multiple window support (multi window
>>support is still experimental, more will come in pygame 2.1).
>>- Android support through python for android (fork of pygame subset
>>for android). Better documentation, and better support will come in future
>>releases.
>>- to make distributing your apps easier, a built in "pyinstaller
>>hook"and compatibility with cxfreeze.
>>- binary "wheels" on many platforms and versions of python from the
>>old python 2.7 - to the latest python 3.9 (and with pypy!).
>>- lots of quality of life improvements like Surface.fill('black')
>>instead of Surface.fill(pygame.Color(0, 0, 0)). Also keywords are
>>supported for many more function arguments. You can draw rounded corners 
>> on
>>rects.
>>- plenty of new examples, like python3 -m pygame.examples.font_viewer,
>>and python3 -m pygame.examples.music_drop_fade. Additionally the
>>example source code has been cleaned up a lot to follow a more current
>>python style.
>>- Hundreds of documentation improvements, include a new Korean
>>tutorial.
>>- a special SCALED mode which takes low pixel games and automatically
>>translates them to a larger window. Imagine your 320x200 resolution game 
>> of
>>glorious pixel art... on modern screens that would be a very tiny windows.
>>Now with SCALED it shows up big on a Full HD screen, or even a 4K/8K 
>> screen
>>and the translation of mouse coordinates and up-scaling of pixels is done
>>for you (hardware accelerated of course).
>>
>> That was a summary of some of the goodies in pygame 2. We will be
>> releasing more articles and tutorials on new features as time goes on. You
>> can also look at the previous release notes for more info (see end of this
>> post).
>> thank you 🎉
>>
>> Probably one of the better realizations thinking about pygame on its 20th
>> birthday is that there is a much larger group of people who have
>> contributed to crafting pygame in recent years. Some have moved onto other
>> things like jobs, family or writing cookbooks in the Canadian wilderness.
>> Much respect for volunteering time to a community project like pygame.
>>
>> *Firstly thanks to the pygame team members* who contributed to the
>> p

Re: [pygame] Re: Starting the pygame 2 series

[Victor Blomqvist]

Congratulations Pygame! Great work by all of you!

On Wed, Oct 28, 2020 at 7:10 PM René Dudfield  wrote:

>
>  ,--.
> |  oo|
> |  ~~| o  o  o  o  o  o  o  o  o  o  o  o  o
> |/\/\|
>python3  -m pip install pygame==2.0.0
>
> The 28th of October 2020 is the pygame 
> 2.0 release date, because pygame turns 20 years of age.
> [image: pygame-head-party.png]
> What's the best feature of pygame 2? Maybe it's "*backwards compatibility*".
> For many, many apps pygame 2 is backwards compatible. Have an pygame app
> from the year 2000? It will probably work. We still have some known issues
> and open backwards compatibility issues(see below), but a lot of things
> work just as they did before. Yes, we still have python 2 support.
>
> How does one summarize the 3306 changes since we started the pygame 2
> series in July of 2018 based on patches going back to 2012 and even earlier?
>
>- Support for Metal, Direct 3d, Vulkan, OpenGL 3.0+ in various
>profiles (core, compatibility, debug, robust, etc), OpenGL ES, and other
>modern hardware accelerated video APIs across many platforms.
>- SSE2/Neon assembly image drawing. Much faster drawing routines,
>image loading, and alpha blending.
>- Type Hints, for code completion (and to help you make the squiggly
>lines disappear) in editors and IDEs.
>- Code cleanup, using lots of code robustness tools like static
>analyzers, and automated CI/CD. We've been able to help dozens of people
>new to community projects contribute. We have lots of work to go on code
>quality, but we're currently the highest rated Python and highest rate C
>large project on LGTM.
>- Many, many bug fixes including in our pygame.draw routines,
>pygame.math(for vectors), and pygame.mask for pixel perfect collision
>detection.
>- better support for pypy (the fast JIT based implementation of
>python).
>- libsdl version 2 support. Technically pygame 2.0 still works with
>SDL 1, but we recommend SDL2 which is vastly improved over SDL1 for most
>use cases. Probably we will remove SDL 1 support starting pygame 2.1.
>- Touch support (multitouch, gestures, etc)
>- Audio input support (make games with your microphone!).
>- Message alert boxes (Press OK, or Cancel).
>- Better keyboard support. Proper unicode input and IME support.
>- Much improved game controller support.
>- Better image and audio format support. Including: webp, 32bit wav
>files, and much more reliable mp3 support.
>- Multiple display support, and multiple window support (multi window
>support is still experimental, more will come in pygame 2.1).
>- Android support through python for android (fork of pygame subset
>for android). Better documentation, and better support will come in future
>releases.
>- to make distributing your apps easier, a built in "pyinstaller
>hook"and compatibility with cxfreeze.
>- binary "wheels" on many platforms and versions of python from the
>old python 2.7 - to the latest python 3.9 (and with pypy!).
>- lots of quality of life improvements like Surface.fill('black')
>instead of Surface.fill(pygame.Color(0, 0, 0)). Also keywords are
>supported for many more function arguments. You can draw rounded corners on
>rects.
>- plenty of new examples, like python3 -m pygame.examples.font_viewer,
>and python3 -m pygame.examples.music_drop_fade. Additionally the
>example source code has been cleaned up a lot to follow a more current
>python style.
>- Hundreds of documentation improvements, include a new Korean
>tutorial.
>- a special SCALED mode which takes low pixel games and automatically
>translates them to a larger window. Imagine your 320x200 resolution game of
>glorious pixel art... on modern screens that would be a very tiny windows.
>Now with SCALED it shows up big on a Full HD screen, or even a 4K/8K screen
>and the translation of mouse coordinates and up-scaling of pixels is done
>for you (hardware accelerated of course).
>
> That was a summary of some of the goodies in pygame 2. We will be
> releasing more articles and tutorials on new features as time goes on. You
> can also look at the previous release notes for more info (see end of this
> post).
> thank you 🎉
>
> Probably one of the better realizations thinking about pygame on its 20th
> birthday is that there is a much larger group of people who have
> contributed to crafting pygame in recent years. Some have moved onto other
> things like jobs, family or writing cookbooks in the Canadian wilderness.
> Much respect for volunteering time to a community project like pygame.
>
> *Firstly thanks to the pygame team members* who contributed to the pygame
> 2 series, new and old...
>
> David Lönnhager (@dlon ) | René Dudfield (@illume
> ) | Charles (@charlesej
> 

Re: [pygame] Re: Starting the pygame 2 series

[Michael Lutynski]

This is a huge achievement!  ＼(^o^)／ 


Thank you to all the devs! :)


~ Michael


On Wednesday, October 28, 2020 11:10:32 AM PDT you wrote:
>  ,--.
> |  oo|
> |  ~~| o  o  o  o  o  o  o  o  o  o  o  o  o
> |/\/\|
>python3  -m pip install pygame==2.0.0
> 
> The 28th of October 2020 is the pygame  2.0
> release date, because pygame turns 20 years of age.
> 

Re: [pygame] Re: Starting the pygame 2 series

[claudio canepa]

Congratulations all off pygame team & contributors!!


On Wed, Oct 28, 2020 at 3:10 PM René Dudfield  wrote:

>
>  ,--.
> |  oo|
> |  ~~| o  o  o  o  o  o  o  o  o  o  o  o  o
> |/\/\|
>python3  -m pip install pygame==2.0.0
>
> The 28th of October 2020 is the pygame 
> 2.0 release date, because pygame turns 20 years of age.
> [image: pygame-head-party.png]
> What's the best feature of pygame 2? Maybe it's "*backwards compatibility*".
> For many, many apps pygame 2 is backwards compatible. Have an pygame app
> from the year 2000? It will probably work. We still have some known issues
> and open backwards compatibility issues(see below), but a lot of things
> work just as they did before. Yes, we still have python 2 support.
>
> How does one summarize the 3306 changes since we started the pygame 2
> series in July of 2018 based on patches going back to 2012 and even earlier?
>
>- Support for Metal, Direct 3d, Vulkan, OpenGL 3.0+ in various
>profiles (core, compatibility, debug, robust, etc), OpenGL ES, and other
>modern hardware accelerated video APIs across many platforms.
>- SSE2/Neon assembly image drawing. Much faster drawing routines,
>image loading, and alpha blending.
>- Type Hints, for code completion (and to help you make the squiggly
>lines disappear) in editors and IDEs.
>- Code cleanup, using lots of code robustness tools like static
>analyzers, and automated CI/CD. We've been able to help dozens of people
>new to community projects contribute. We have lots of work to go on code
>quality, but we're currently the highest rated Python and highest rate C
>large project on LGTM.
>- Many, many bug fixes including in our pygame.draw routines,
>pygame.math(for vectors), and pygame.mask for pixel perfect collision
>detection.
>- better support for pypy (the fast JIT based implementation of
>python).
>- libsdl version 2 support. Technically pygame 2.0 still works with
>SDL 1, but we recommend SDL2 which is vastly improved over SDL1 for most
>use cases. Probably we will remove SDL 1 support starting pygame 2.1.
>- Touch support (multitouch, gestures, etc)
>- Audio input support (make games with your microphone!).
>- Message alert boxes (Press OK, or Cancel).
>- Better keyboard support. Proper unicode input and IME support.
>- Much improved game controller support.
>- Better image and audio format support. Including: webp, 32bit wav
>files, and much more reliable mp3 support.
>- Multiple display support, and multiple window support (multi window
>support is still experimental, more will come in pygame 2.1).
>- Android support through python for android (fork of pygame subset
>for android). Better documentation, and better support will come in future
>releases.
>- to make distributing your apps easier, a built in "pyinstaller
>hook"and compatibility with cxfreeze.
>- binary "wheels" on many platforms and versions of python from the
>old python 2.7 - to the latest python 3.9 (and with pypy!).
>- lots of quality of life improvements like Surface.fill('black')
>instead of Surface.fill(pygame.Color(0, 0, 0)). Also keywords are
>supported for many more function arguments. You can draw rounded corners on
>rects.
>- plenty of new examples, like python3 -m pygame.examples.font_viewer,
>and python3 -m pygame.examples.music_drop_fade. Additionally the
>example source code has been cleaned up a lot to follow a more current
>python style.
>- Hundreds of documentation improvements, include a new Korean
>tutorial.
>- a special SCALED mode which takes low pixel games and automatically
>translates them to a larger window. Imagine your 320x200 resolution game of
>glorious pixel art... on modern screens that would be a very tiny windows.
>Now with SCALED it shows up big on a Full HD screen, or even a 4K/8K screen
>and the translation of mouse coordinates and up-scaling of pixels is done
>for you (hardware accelerated of course).
>
> That was a summary of some of the goodies in pygame 2. We will be
> releasing more articles and tutorials on new features as time goes on. You
> can also look at the previous release notes for more info (see end of this
> post).
> thank you 🎉
>
> Probably one of the better realizations thinking about pygame on its 20th
> birthday is that there is a much larger group of people who have
> contributed to crafting pygame in recent years. Some have moved onto other
> things like jobs, family or writing cookbooks in the Canadian wilderness.
> Much respect for volunteering time to a community project like pygame.
>
> *Firstly thanks to the pygame team members* who contributed to the pygame
> 2 series, new and old...
>
> David Lönnhager (@dlon ) | René Dudfield (@illume
> ) | Charles (@charlesej
> 

Re: [pygame] Re: Starting the pygame 2 series

[Thomas Kluyver]

Congratulations René and everyone involved in this! I know a huge amount of
time and effort has gone in to this point, so it's great to see it in a
release.

Thomas

On Wed, 28 Oct 2020 at 18:10, René Dudfield  wrote:

>
>  ,--.
> |  oo|
> |  ~~| o  o  o  o  o  o  o  o  o  o  o  o  o
> |/\/\|
>python3  -m pip install pygame==2.0.0
>
> The 28th of October 2020 is the pygame 
> 2.0 release date, because pygame turns 20 years of age.
> [image: pygame-head-party.png]
> What's the best feature of pygame 2? Maybe it's "*backwards compatibility*".
> For many, many apps pygame 2 is backwards compatible. Have an pygame app
> from the year 2000? It will probably work. We still have some known issues
> and open backwards compatibility issues(see below), but a lot of things
> work just as they did before. Yes, we still have python 2 support.
>
> How does one summarize the 3306 changes since we started the pygame 2
> series in July of 2018 based on patches going back to 2012 and even earlier?
>
>- Support for Metal, Direct 3d, Vulkan, OpenGL 3.0+ in various
>profiles (core, compatibility, debug, robust, etc), OpenGL ES, and other
>modern hardware accelerated video APIs across many platforms.
>- SSE2/Neon assembly image drawing. Much faster drawing routines,
>image loading, and alpha blending.
>- Type Hints, for code completion (and to help you make the squiggly
>lines disappear) in editors and IDEs.
>- Code cleanup, using lots of code robustness tools like static
>analyzers, and automated CI/CD. We've been able to help dozens of people
>new to community projects contribute. We have lots of work to go on code
>quality, but we're currently the highest rated Python and highest rate C
>large project on LGTM.
>- Many, many bug fixes including in our pygame.draw routines,
>pygame.math(for vectors), and pygame.mask for pixel perfect collision
>detection.
>- better support for pypy (the fast JIT based implementation of
>python).
>- libsdl version 2 support. Technically pygame 2.0 still works with
>SDL 1, but we recommend SDL2 which is vastly improved over SDL1 for most
>use cases. Probably we will remove SDL 1 support starting pygame 2.1.
>- Touch support (multitouch, gestures, etc)
>- Audio input support (make games with your microphone!).
>- Message alert boxes (Press OK, or Cancel).
>- Better keyboard support. Proper unicode input and IME support.
>- Much improved game controller support.
>- Better image and audio format support. Including: webp, 32bit wav
>files, and much more reliable mp3 support.
>- Multiple display support, and multiple window support (multi window
>support is still experimental, more will come in pygame 2.1).
>- Android support through python for android (fork of pygame subset
>for android). Better documentation, and better support will come in future
>releases.
>- to make distributing your apps easier, a built in "pyinstaller
>hook"and compatibility with cxfreeze.
>- binary "wheels" on many platforms and versions of python from the
>old python 2.7 - to the latest python 3.9 (and with pypy!).
>- lots of quality of life improvements like Surface.fill('black')
>instead of Surface.fill(pygame.Color(0, 0, 0)). Also keywords are
>supported for many more function arguments. You can draw rounded corners on
>rects.
>- plenty of new examples, like python3 -m pygame.examples.font_viewer,
>and python3 -m pygame.examples.music_drop_fade. Additionally the
>example source code has been cleaned up a lot to follow a more current
>python style.
>- Hundreds of documentation improvements, include a new Korean
>tutorial.
>- a special SCALED mode which takes low pixel games and automatically
>translates them to a larger window. Imagine your 320x200 resolution game of
>glorious pixel art... on modern screens that would be a very tiny windows.
>Now with SCALED it shows up big on a Full HD screen, or even a 4K/8K screen
>and the translation of mouse coordinates and up-scaling of pixels is done
>for you (hardware accelerated of course).
>
> That was a summary of some of the goodies in pygame 2. We will be
> releasing more articles and tutorials on new features as time goes on. You
> can also look at the previous release notes for more info (see end of this
> post).
> thank you 🎉
>
> Probably one of the better realizations thinking about pygame on its 20th
> birthday is that there is a much larger group of people who have
> contributed to crafting pygame in recent years. Some have moved onto other
> things like jobs, family or writing cookbooks in the Canadian wilderness.
> Much respect for volunteering time to a community project like pygame.
>
> *Firstly thanks to the pygame team members* who contributed to the pygame
> 2 series, new and old...
>
> David Lönnhager (@dlon 

Re: [pygame] Re: Starting the pygame 2 series

[René Dudfield]

 ,--.
|  oo|
|  ~~| o  o  o  o  o  o  o  o  o  o  o  o  o
|/\/\|
   python3  -m pip install pygame==2.0.0

The 28th of October 2020 is the pygame  2.0
release date, because pygame turns 20 years of age.
[image: pygame-head-party.png]
What's the best feature of pygame 2? Maybe it's "*backwards compatibility*".
For many, many apps pygame 2 is backwards compatible. Have an pygame app
from the year 2000? It will probably work. We still have some known issues
and open backwards compatibility issues(see below), but a lot of things
work just as they did before. Yes, we still have python 2 support.

How does one summarize the 3306 changes since we started the pygame 2
series in July of 2018 based on patches going back to 2012 and even earlier?

   - Support for Metal, Direct 3d, Vulkan, OpenGL 3.0+ in various profiles
   (core, compatibility, debug, robust, etc), OpenGL ES, and other modern
   hardware accelerated video APIs across many platforms.
   - SSE2/Neon assembly image drawing. Much faster drawing routines, image
   loading, and alpha blending.
   - Type Hints, for code completion (and to help you make the squiggly
   lines disappear) in editors and IDEs.
   - Code cleanup, using lots of code robustness tools like static
   analyzers, and automated CI/CD. We've been able to help dozens of people
   new to community projects contribute. We have lots of work to go on code
   quality, but we're currently the highest rated Python and highest rate C
   large project on LGTM.
   - Many, many bug fixes including in our pygame.draw routines,
   pygame.math(for vectors), and pygame.mask for pixel perfect collision
   detection.
   - better support for pypy (the fast JIT based implementation of python).
   - libsdl version 2 support. Technically pygame 2.0 still works with SDL
   1, but we recommend SDL2 which is vastly improved over SDL1 for most use
   cases. Probably we will remove SDL 1 support starting pygame 2.1.
   - Touch support (multitouch, gestures, etc)
   - Audio input support (make games with your microphone!).
   - Message alert boxes (Press OK, or Cancel).
   - Better keyboard support. Proper unicode input and IME support.
   - Much improved game controller support.
   - Better image and audio format support. Including: webp, 32bit wav
   files, and much more reliable mp3 support.
   - Multiple display support, and multiple window support (multi window
   support is still experimental, more will come in pygame 2.1).
   - Android support through python for android (fork of pygame subset for
   android). Better documentation, and better support will come in future
   releases.
   - to make distributing your apps easier, a built in "pyinstaller
   hook"and compatibility with cxfreeze.
   - binary "wheels" on many platforms and versions of python from the old
   python 2.7 - to the latest python 3.9 (and with pypy!).
   - lots of quality of life improvements like Surface.fill('black')
   instead of Surface.fill(pygame.Color(0, 0, 0)). Also keywords are
   supported for many more function arguments. You can draw rounded corners on
   rects.
   - plenty of new examples, like python3 -m pygame.examples.font_viewer,
   and python3 -m pygame.examples.music_drop_fade. Additionally the example
   source code has been cleaned up a lot to follow a more current python style.
   - Hundreds of documentation improvements, include a new Korean tutorial.
   - a special SCALED mode which takes low pixel games and automatically
   translates them to a larger window. Imagine your 320x200 resolution game of
   glorious pixel art... on modern screens that would be a very tiny windows.
   Now with SCALED it shows up big on a Full HD screen, or even a 4K/8K screen
   and the translation of mouse coordinates and up-scaling of pixels is done
   for you (hardware accelerated of course).

That was a summary of some of the goodies in pygame 2. We will be releasing
more articles and tutorials on new features as time goes on. You can also
look at the previous release notes for more info (see end of this post).
thank you 🎉

Probably one of the better realizations thinking about pygame on its 20th
birthday is that there is a much larger group of people who have
contributed to crafting pygame in recent years. Some have moved onto other
things like jobs, family or writing cookbooks in the Canadian wilderness.
Much respect for volunteering time to a community project like pygame.

*Firstly thanks to the pygame team members* who contributed to the pygame 2
series, new and old...

David Lönnhager (@dlon ) | René Dudfield (@illume
) | Charles (@charlesej
) | Dan Lawrence (@MyreMylar
) | Ankith (@ankith26
, Niels Thykier (@nthykier
) | Lenard Lindstrom (@llindstrom
) | Sigurður Sveinn Halldórsson (@siggisv

Re: [pygame] Re: Starting the pygame 2 series

[René Dudfield]

python3 -m pip install pygame=2.0.0.dev24

https://github.com/pygame/pygame/releases/tag/2.0.0.dev24


A bunch of fixes and speedups before the 2.0 release.
Now the default branch on the pygame repo is main
.

@MyreMylar  Dan Lawrence

   - Sets SDL Hint for hidden mouse cursor at window edges when full screen
   #2254 
   - Documents that integers underlying key code constants differ between
   Pygame 1 & 2 #2253 
   - Updates the joystick docs to include controller mappings for X360 &
   PS4 controllers #2252 
   - Updates the docs for toggle_fullscreen() #2251
   
   - New Alpha blitter - fixes and speed ups #2243
   

@siggisv  Sigurður Sveinn Halldórsson

   - Add to test/draw_test.py some unit tests for draw.line() #2247
   

Ankith @ankith26 

   - A small little deletion of obsolete file #2256
   
   - Do MOUSEBUTTONUP event on MOUSEWHEEL #2242
   
   - Fix event.post KEYDOWN/KEYUP #2244
   

Re: [pygame] Re: Starting the pygame 2 series

[BW]

You fixed my blending bug before I could report it. Thank you. :)

On 10/23/2020 2:09 PM, Andrew Baker wrote:

Very nice work, René


On Fri, Oct 23, 2020, 12:49 René Dudfield > wrote:


/
/
/*5 more sleeps* (not including extra naps) until the 20th & 2.0
release day./


A few little releases in a busy few days.

python3 -m pip install pygame==2.0.0.dev22


https://github.com/pygame/pygame/releases/tag/2.0.0.dev22
https://github.com/pygame/pygame/releases/tag/2.0.0.dev20
https://github.com/pygame/pygame/releases/tag/2.0.0.dev18

Several very difficult to find and fix issues with alpha blending
were fixed in this release.

  * First pass at backwards compatible pygame alpha blit
 by @MyreMylar


The new alpha blitter has an SSE2 and arm NEON implementation, and
keeps compatibility with pygame 1.

Also some progress on other issues, including these...

  * Fix twitchy key tests on raspi
 by @ankith26

  * Better unit tests for event module
 by @ankith26

  * Fix messed up SSE 4.2 removal


More compatible manylinux wheels (Ubuntu 18.04 Bionic and CPUs
without SSE 4.2), some documentation improvements, and pygame.midi
fixes.

  * Disable SSE 4.2 stuff because it does not do runtime detection
on old CPUs. 
  * Use manylinux2010 for pypy and manylinux1 for other pythons

  * Doc updates (SDL2 -> pygame 2)
 by @ankith26

  * Fix pygame.midi so tests and example runs on py3 and py2



Thanks to everyone.

ciao!
(for now)



On Tue, Oct 20, 2020 at 9:21 PM René Dudfield mailto:ren...@gmail.com>> wrote:

|pip install pygame==2.0.0.dev16|

The 28^th of October 2020 will be the pygame
 2.0 release date, because
pygame turns 20 years of age.

We reached two important milestones with this pre-release.
Firstly the old game 'solarwolf' is working fine with no known
issues on pygame 2. The second stone we passed by on the road
to PyPy  goodness is that we are
releasing binary wheels for PyPy on mac, windows, and linux.
PyPy is a different implementation of python that is highly
compatible and can be extremely fast.

Here's a little youtube video of solarwolf on PyPy and SDL2
...
solarwolf on SDL2 and pypy


If you watched the video to the end, you'll note there's a
crash. We still have some way to go before everything in
pygame is working with PyPy. "solarwolf" using cpython and
pygame 2 is running deliciously and glitch free.


Critical backwards compatibility fixes for pygame 2

First up, some 'critical' improvements that have been made to
pygame. 'critical' labeled issues are ones are backwards
incompatible issues stopping a pygame 2 release.

Dan Lawrence @MyreMylar 

  * Making RLE flags & RLE behaviour more consistent between
pygame 1 and pygame 2
, so that a
lot more types of surfaces draw correctly and that
"solarwolf" works really nicely.

Ankith @ankith26 

  * Fix repeated VIDEOEXPOSE events
, so apps do
not get dozens of extra nonsensical VIDEOEXPOSE events on
Windows.

René Dudfield @illume 

  * Added portmidi package for conan MacOS
 so that
pygame.midi works on MacOS again.
  * Set icon on macos like the other platforms with SDL2
, so the
default icon is there again for MacOS.


  bugs, worms, shiny-shiny, and such

Dan Lawrence @MyreMylar 

  * Missing mouse_doc.h file

  * Fix for missed braces in get_flags()

  * Adding a premul_alpha helper m

Re: [pygame] Re: Starting the pygame 2 series

[Andrew Baker]

Very nice work, René


On Fri, Oct 23, 2020, 12:49 René Dudfield  wrote:

>
> *5 more sleeps (not including extra naps) until the 20th & 2.0 release
> day.*
>
>
> A few little releases in a busy few days.
>
> python3 -m pip install pygame==2.0.0.dev22
>>
>
> https://github.com/pygame/pygame/releases/tag/2.0.0.dev22
> https://github.com/pygame/pygame/releases/tag/2.0.0.dev20
> https://github.com/pygame/pygame/releases/tag/2.0.0.dev18
>
> Several very difficult to find and fix issues with alpha blending were
> fixed in this release.
>
>- First pass at backwards compatible pygame alpha blit
> by @MyreMylar
>
>
> The new alpha blitter has an SSE2 and arm NEON implementation, and keeps
> compatibility with pygame 1.
>
> Also some progress on other issues, including these...
>
>- Fix twitchy key tests on raspi
> by @ankith26
>
>- Better unit tests for event module
> by @ankith26
>
>- Fix messed up SSE 4.2 removal
>
>
> More compatible manylinux wheels (Ubuntu 18.04 Bionic and CPUs without SSE
> 4.2), some documentation improvements, and pygame.midi fixes.
>
>- Disable SSE 4.2 stuff because it does not do runtime detection on
>old CPUs. 
>- Use manylinux2010 for pypy and manylinux1 for other pythons
>
>- Doc updates (SDL2 -> pygame 2)
> by @ankith26
>
>- Fix pygame.midi so tests and example runs on py3 and py2
>
>
>
> Thanks to everyone.
>
> ciao!
> (for now)
>
>
>
> On Tue, Oct 20, 2020 at 9:21 PM René Dudfield  wrote:
>
>> pip install pygame==2.0.0.dev16
>>
>> The 28th of October 2020 will be the pygame
>>  2.0 release date, because pygame turns
>> 20 years of age.
>>
>> We reached two important milestones with this pre-release. Firstly the
>> old game 'solarwolf' is working fine with no known issues on pygame 2. The
>> second stone we passed by on the road to PyPy 
>> goodness is that we are releasing binary wheels for PyPy on mac, windows,
>> and linux. PyPy is a different implementation of python that is highly
>> compatible and can be extremely fast.
>>
>> Here's a little youtube video of solarwolf on PyPy and SDL2
>> ...
>> [image: solarwolf on SDL2 and pypy]
>> 
>>
>> If you watched the video to the end, you'll note there's a crash. We
>> still have some way to go before everything in pygame is working with PyPy.
>> "solarwolf" using cpython and pygame 2 is running deliciously and glitch
>> free.
>>
>> Critical backwards compatibility fixes for pygame 2
>>
>> First up, some 'critical' improvements that have been made to pygame.
>> 'critical' labeled issues are ones are backwards incompatible issues
>> stopping a pygame 2 release.
>>
>> Dan Lawrence @MyreMylar 
>>
>>- Making RLE flags & RLE behaviour more consistent between pygame 1
>>and pygame 2 , so that a
>>lot more types of surfaces draw correctly and that "solarwolf" works 
>> really
>>nicely.
>>
>> Ankith @ankith26 
>>
>>- Fix repeated VIDEOEXPOSE events
>>, so apps do not get
>>dozens of extra nonsensical VIDEOEXPOSE events on Windows.
>>
>> René Dudfield @illume 
>>
>>- Added portmidi package for conan MacOS
>> so that pygame.midi
>>works on MacOS again.
>>- Set icon on macos like the other platforms with SDL2
>>, so the default icon is
>>there again for MacOS.
>>
>> bugs, worms, shiny-shiny, and such
>>
>> Dan Lawrence @MyreMylar 
>>
>>- Missing mouse_doc.h file
>>
>>- Fix for missed braces in get_flags()
>>
>>- Adding a premul_alpha helper method to Color class
>>
>>- One of the math.c functions still used deprecated UTF functions
>>
>>
>> René Dudfield @illume 
>>
>>- Test that pygame with SDL2 blit gives same results as SDL1 blit
>>
>>- CI speedups 
>>- Skip a lot of failing tests on pypy, build 

Re: [pygame] Re[2]: [pygame] Can the pygame infrastructure be used for non-graphical text-mode games?

[Ian Mallett]

On Thu, Jul 16, 2020 at 3:49 AM  wrote:

> How do i unsubscribe?
>
The same way you subscribed. See directions here:
https://www.pygame.org/wiki/info

Re: [pygame] Re: Starting the pygame 2 series

[René Dudfield]

Thanks Nicholas, and Michael :) *blushes*

Re: [pygame] Re: Starting the pygame 2 series

[Nicholas H.Tollervey]

René,

Words can't describe what a wonderful person you are. Without your
efforts there simply wouldn't be PyGame, and without PyGame there
wouldn't be our wonderful community of Python game makers. I can't speak
for anyone else, but I wanted to publicly acknowledge my gratitude and
respect for you, your work and all that you contribute.

Best wishes,

Nicholas.

On 07/10/2019 10:28, René Dudfield wrote:
> */I'm tired./* Been spending some months on pygame stuff.
> 
> That article(novella) I promised several months ago about
> contemporary C tools is still unfinished(but probably useful).
> http://renesd.blogspot.com/2019/09/post-modern-c-tooling.html
> 
> Learnt lots from writing it. Especially researching how other projects
> do things.
> I tried to include instructions on how to use tools, and further links
> to videos and articles.
> Here's some issues of those tools applied to pygame:
>     https://github.com/pygame/pygame/labels/tooling
> 
> A few people have been helping with these issues,
> but @charlesej in particular has been amazing in going through mountains
> of issues uncovered.
> The pygame code base is significantly cleaner, more portable, and less
> buggy because of it.
> 
> 
> 
> Speaking of bugs, as people have been using the 2.0.0.dev3 release,
> they've been finding various bugs.
> I've labeled all SDL2/pygame 2 related compatibility issues reported by
> people as `*critical*`.
>     https://github.com/pygame/pygame/labels/critical
> 
> These `critical` issues will be my focus as we move forward to shipping
> pygame 2.0.0.
> If you feel like helping out with any of these critical issues, that
> would be highly appreciated.
> 
> - confirm the bug (on your platform).
> - cheer people on in the issues
> - write a minimal working example script so people can reproduce the
> issue.
> - write a test case, or try and clarify the issue
> 
>     https://github.com/pygame/pygame/labels/critical
> 
> 
> 
> Lots more has been going on,
> which I'll expand on in the release notes for the upcoming 2.0.0.dev4
> release.
> (We're 684 commits since the last stable release).
> 
> 
> ps. DaFluffyPotato released a new commercial game using the pygame
> 2.0.0.dev3 release.
> "Drawn Down Abyss" is getting good reviews... check it out:
>     https://www.pygame.org/project/4294
> pps. Feels like progress?
> 



signature.asc
Description: OpenPGP digital signature

Re: [pygame] Re: Starting the pygame 2 series

[Michael Lutinsky]

Wow, amazing work, all around! O_O


*/I'm tired./* Been spending some months on pygame stuff. 




That article(novella) I promised several months ago about 


contemporary C tools is still unfinished(but probably useful).


http://renesd.blogspot.com/2019/09/post-modern-c-tooling.html[1]


Learnt lots from writing it. Especially researching how other projects do 
things.
I tried to include instructions on how to use tools, and further links to 
videos and articles.


Here's some issues of those tools applied to pygame: 


https://github.com/pygame/pygame/labels/tooling[2]


A few people have been helping with these issues, 


but @charlesej in particular has been amazing in going through mountains of 
issues uncovered.
The pygame code base is significantly cleaner, more portable, and less buggy 
because of it.







I've labeled all SDL2/pygame 2 related compatibility issues reported by people 
as `*critical*`.


https://github.com/pygame/pygame/labels/critical[3]


These `critical` issues will be my focus as we move forward to shipping pygame 
2.0.0.
If you feel like helping out with any of these critical issues, that would be 
highly appreciated.


- confirm the bug (on your platform).
- cheer people on in the issues
- write a minimal working example script so people can reproduce the issue.


- write a test case, or try and clarify the issue


_https://github.com/pygame/pygame/labels/critical_






Lots more has been going on, 


which I'll expand on in the release notes for the upcoming 2.0.0.dev4 release.
(We're 684 commits since the last stable release).






ps. DaFluffyPotato released a new commercial game using the pygame 2.0.0.dev3 
release. 


"Drawn Down Abyss" is getting good reviews... check it out:
https://www.pygame.org/project/4294[4]
pps. Feels like progress?








[1] http://renesd.blogspot.com/2019/09/post-modern-c-tooling.html
[2] https://github.com/pygame/pygame/labels/tooling
[3] https://github.com/pygame/pygame/labels/critical
[4] https://www.pygame.org/project/4294

Re: [pygame] Re: Starting the pygame 2 series

[Thomas Kluyver]

On Mon, 15 Jul 2019 at 00:33, René Dudfield  wrote:

> Thanks to @charlesoblack  (first time
> contributor ya!) there is a pygame.Color.lerp() function now. It returns a
> linear interpolation.


It might be an interesting extension to this to allow interpolating in a
colour space based on how humans perceive colour. That could give better
results if you want to make a sequence of shades at regular intervals. If
anyone's interested in this topic, there's a good talk about colour maps in
matplotlib:

https://www.youtube.com/watch?v=xAoljeRJ3lU

Thomas

Re: [pygame] Re: Starting the pygame 2 series

[Daniel Foerster]

This can be done already using a lambda:

color_lerp = lambda pct: color.lerp(color2, pct)


On Mon, Jul 15, 2019, 13:56 Sam Bull  wrote:

> On Mon, 2019-07-15 at 01:32 +0200, René Dudfield wrote:
> > Thanks to @charlesoblack (first time contributor ya!) there is a
> > pygame.Color.lerp() function now. It returns a linear interpolation.
> >
> > >>> color.lerp(color2, 0.0) -> color
> >
> > >>> color.lerp(color2, 0.5) -> halfway_color
> >
> > >>> color.lerp(color2, 1.0) -> color2
>
> That's handy. I wonder if it might even be worth taking it a step further,
> so
> you can just pass an object to a function to update the color progressively
> (i.e. it doesn't need to know the color, it just updates the progress
> value),
> such as:
>
>color_lerp = ColorLerp(color1, color2)
>progress = 0
>while progress < 1:
>progress += 0.1
>set_col(color_lerp.lerp(progress))
>
>
> Or anything along those lines...
>

Re: [pygame] Re: Starting the pygame 2 series

[Sam Bull]

On Mon, 2019-07-15 at 01:32 +0200, René Dudfield wrote:
> Thanks to @charlesoblack (first time contributor ya!) there is a
> pygame.Color.lerp() function now. It returns a linear interpolation.
> 
> >>> color.lerp(color2, 0.0) -> color 
> 
> >>> color.lerp(color2, 0.5) -> halfway_color 
> 
> >>> color.lerp(color2, 1.0) -> color2

That's handy. I wonder if it might even be worth taking it a step further, so
you can just pass an object to a function to update the color progressively
(i.e. it doesn't need to know the color, it just updates the progress value),
such as:

   color_lerp = ColorLerp(color1, color2)
   progress = 0
   while progress < 1:
   progress += 0.1
   set_col(color_lerp.lerp(progress))


Or anything along those lines...


signature.asc
Description: This is a digitally signed message part

Re: The first pygame 2 community game. Are you in? Re: [pygame] Re: About Pygame development

[René Dudfield]

Hello,

so the game jam happened, and more than 14 people took part in making
stuntcat 🐱‍🏍.

Already we have learnt a lot, and used those learnings to drive pygame 2
development.
More info here: https://www.pygame.org/news/2019/1/stuntcat

Re: USEREVENT clash fix, was Re: [pygame] Re: Starting the pygame 2 series

[René Dudfield]

Hi DR0ID,

thanks for your response, and for reviving this.

On Sat, Dec 22, 2018 at 10:34 AM DR0ID  wrote:

> This is a bit cumbersome to use (since I don't know why pygame.NUMEVENTS
> is limited to 32) but will work.
>

NUMEVENTS limited to 32 is because of a SDL1 limitation. We can't raise
that limit directly.

However, it is possible to change things underneath (inside the pygame
functions).
See https://github.com/pygame/pygame/issues/477#issuecomment-407551211

This is what the new API would look like:

ZOG_UP = pg.event.custom_type()ZOG_DOWN = pg.event.custom_type()
pg.event.post(pg.Event(ZOG_DOWN, msg='hello'))
for e in pg.event.get():
if e.type == ZOG_UP:
print('zog goes up!')


Now... what would happen underneath (inside the pygame functions) is that
on SDL1...

   - One custom type would be allocated from the 32 to pygame custom types.

CUSTOM_TYPE = pygame.USEREVENT


   - pygame.USEREVENT would be set to pygame.USEREVENT + 1 (so CUSTOM_TYPE
   is not used by other things).
   - When the python object is created, the SDL structure would use
   CUSTOM_TYPE. however event.type would be the custom type (eg. 'ZOG_UP').
   - pygame.event.post() would first translate this ZOG_UP to use
   CUSTOM_TYPE in the SDL structure.
   - pygame.event.get() and pygame.event.wait() would return an event with
   the type translated from the CUSTOM_TYPE (as used in the internal SDL
   structure) to the custom type (eg. e.type == ZOG_UP).


Does this all make sense?

These problems are solved by this:

   - no way to coordinate custom events between libraries.  Now
   pg.event.custom_type() would be used.
   - the number of custom events is too small. Now pygame would handle this
   translation at the C level.


But there is a strange thing: using mixer.music, mixer.Channel or
> pygame.time.set_timer() objects. They provide an set_endevent() method, but
> only can take an integer (which is almost useless with the NUMEVENTS
> limit). I would have expected to be able to set a custom event there too
> because that would solve it the same way as with normal events.
>
Yeah, it would be nice if these accepted events rather than event ids.

Can you please give some examples of how using these APIs would look taking
events?

Especially when using a timer you normally want many timers bound to
> different ids. If pygame would provide that built-in this would really be
> good (hmm, maybe there should be an additional module for this like for
> sprites).
>

Would you please be able to explain this some more?


cheers,

Re: USEREVENT clash fix, was Re: [pygame] Re: Starting the pygame 2 series

[DR0ID]

On 28.07.2018 12:16, Sam Bull wrote:

On Sat, 2018-07-28 at 09:59 +0200, René Dudfield wrote:

def custom_type():
     """ Return an event type we can use for our own events.
     """

Don't forget to mention in the documentation that StopIteration will be raised
if there are no more event types available.



Hi there

Sorry for the late response.

You can prevent the USEREVENT clash if you use a custom event construct 
like this (or at least almost):



pygame.event.post(pygame.event.Event(pygame.USEREVENT, {"id":1223434234, "num":34, 
"value":"bla"}))

Using this allows you do define any value for the id field you need. 
Also you can add custom properties (in this example like 'num' and 
'value').  But then you will have a if elif else dispatching construct 
within the elif block handling the USEREVENT.


This extra values can be read like normal event attributes like this:

print(event)
print(event.id)
print(event.num)
print(event.value)

This is a bit cumbersome to use (since I don't know why pygame.NUMEVENTS 
is limited to 32) but will work.


But there is a strange thing: using mixer.music, mixer.Channel or 
pygame.time.set_timer() objects. They provide an set_endevent() method, 
but only can take an integer (which is almost useless with the NUMEVENTS 
limit). I would have expected to be able to set a custom event there too 
because that would solve it the same way as with normal events.


Especially when using a timer you normally want many timers bound to 
different ids. If pygame would provide that built-in this would really 
be good (hmm, maybe there should be an additional module for this like 
for sprites).



I see only two ways: Either raise the NUMEVENTS limit to a high number 
e.g. >1000 or bigger.


Or

Allow custom events everywhere.


For libraries or classes using an USEREVENT maybe the actual event 
number should be passed somehow so each application/game can use the 
event numbers as they fit best.


~DR0ID


Below my test script:


# -*- coding: utf-8 -*- from __future__import print_function, division

import logging

logging.basicConfig()
import pygame

logger = logging.getLogger(__name__)

SCREENSIZE =800, 600 def main():

pygame.init()
# screen = pygame.display.set_mode(SCREENSIZE, pygame.RESIZABLE | 
pygame.SRCALPHA, 32) screen = pygame.display.set_mode(SCREENSIZE)


running =True while running:
# events for eventin pygame.event.get():

if event.type == pygame.QUIT:
running =False elif event.type == pygame.KEYDOWN:
if event.key == pygame.K_ESCAPE:
running =False elif event.key == pygame.K_SPACE:
pygame.event.post(pygame.event.Event(pygame.USEREVENT, {"id":1223434234, 
"num":34, "value":"bla"}))
elif event.key == pygame.K_m:

pygame.mixer.music.set_endevent(pygame.event.Event(pygame.USEREVENT, {id:999}))
elif event.type == pygame.USEREVENT:
print(event)
print(event.id)
print(event.num)
print(event.value)
# dispatch here according to id if event.id ==0:
pass elif event.id ==3:
pass else:
pass # and so on # draw pygame.display.flip()
screen.fill((255, 0, 255))

pygame.quit()


if __name__ =='__main__':
main()

The first pygame 2 community game. Are you in? Re: [pygame] Re: About Pygame development

[René Dudfield]

What is a 🐱‍🏍? *[0].

Following on from the "About Pygame development
" email
thread...


One topic of that conversation was doing a community game in there for
reasons(see below).

I would like to do a *pygame 2 community game* to submit in the:

   - https://ldjam.com/
   - https://itch.io/jam/game-off-2018 (GameOff github jam)

Ludumdare(ldjam) starts in 3 days, 7 hours. Theme not selected yet.
GameOff finishes in 4 days 2 hours. *Theme is "Hybrid*", Jam already
started.

So, the Jams finish in 4.1 days.

Are you in?
If so join the web based chatroom (discord) in
the "#communitygame" channel.
Our repo: https://github.com/pygame/stuntcat

I'm trying to form a team now.

... read more?...

click
loading...
loading...
buffering...
loading...
refresh...
loading...


So why do this?
My reasons for doing this are to push me to get pygame 2 features done that
are actually useful in apps (Write Games, Not Engines
).
It will be a good testbed for prototyping as well.

I will also try to get the game into Steam, and any other app stores.
Because distributing pygame 2 games is also important,
and improving the tooling and documentation around that is also important.

The pygame 2 community game serves these purposes.

   - guiding and motivating pygame 2 development (make games not engines)
   - raising funds towards pygame 2 developments (or losing money on steam
   signup costs)
   - making an open source pygame 2 game
   - improving the work flow for people releasing games/apps.
   - helping to guide improvements on the pygame website
   - trying out new technology and techniques

It's about 4-5 days, and then there will be some more days to try and
distribute the game further.

- License for code will be the pygame license (LGPL, but you can keep your
parts of course!)
- Art assets license will be some form of permissive creative commons. So
technically anyone should be able to distribute it following those licenses
(and even sell it).

Contributors will also:

   - be in the credits on the pygame website, game website, in game, promo
   pages
   - have their link (to patreon twitter github etc) in their too
   - hopefully enjoy themselves, and maybe learn something

Also interested in people who want this game to use their library.
Especially if you will us use the library or improve it as part of the Jam.



Anyone who wants to be involved can join the discord channel
web based chatroom (discord) in the
"#communitygame" channel.
Please let us know if you want to be involved and how :)
*[0] (We came up with a repo name... we were perhaps thinking something
like "Speedy the stunt cat" or "stuntcat" Did you know there is this whole
weird genre of stunt cat games, and that stunt cat emojis are a thing?
🐱‍🏍 Also, @claudeb's first cat was called Speedy, and was a stunt cat. So
that's the repo name. )



--
*This email in webpage form:*

*https://renesd.blogspot.com/2018/11/first-pygame-2-community-game-starting.html
*

Re: [pygame] Re: About Pygame development

[René Dudfield]

(Oops. Somehow I didn't press send on this reply it seems.)
--

Hello!

Don't think I was at the dojo for that one, but it does sound fun.
Well, I do remember one where we made a random maze generator.
Maybe that was part of it?
Also there was a pyweek when some ldndojo people tried to make a game
called:
Woger the Wibblly Wobbly Wombat.
8 years ago now!? wow

Yeah, ok... good idea about putting that in a blog post.
I'd be interested to read something on your experiences too :)

Yeah, the "Big Buck Bunny" film was one of the blender open projects.
Ton(another tall Dutch person) of Blender wrote some interesting essays
about it back in the day,
but I can't find them at the moment.
I did find this 'The making of Big Buck Bunny' thing on youtube which was
interesting.
There are some parts about involvement of the community.
https://www.youtube.com/watch?v=Pr8iM8kAJOw

But they have done several more since then, so perhaps they have more
'making of's or post mortems out there.
(here is Making of Agent 327, their 2017 short they are hoping to turn into
a feature film next)
https://www.youtube.com/watch?v=JKlgCnp_57M
So that took them 10 years to get up to trying to make a movie from all
those short films.

There were definitely many UX improvements after and during these projects
to Blender.
I just read they have some sort of 'cloud' subscriptions which they say is
their biggest income now.
But I guess they hope the movie will sell,
and let them move up to a planned 10 developers working on Blender for the
Institute.
https://www.blender.org/institute/
https://www.blender.org/foundation/



This is the Gimp animation project patreon page has interesting posts about
their gimp work:
https://www.patreon.com/zemarmot/posts
And on their blog(starting 2012). It shows they are a major contributor for
Gimp of recent.
https://girinstud.io/news/2018/04/zemarmot-main-contributor-of-gimp-2-10-0-rc1/

And yeah, they helped with a whole bunch of UX improvements and pushed Gimp
through to a release (after 6 years of big internal changes).
Despite the tiny amount of funding, they made a massive impact to Gimp.
Little things like 'recovery on crash', and 'do not wait until all fonts
are read before app can be used' are what
you need when you are using it in production. You also need to release it.


cheers,



On Wed, Aug 22, 2018 at 12:56 PM Nicholas H.Tollervey 
wrote:

> Rene,
>
> The OP is wonderful to read, and so much of it chimes with my experience
> in floss development. Perhaps turn it into a blog post so people can
> point to it and share it?
>
> I love Thomas's idea of a PyGame "game" - it reminds me of Blender's
> "Big Buck Bunny" film where all the assets, source and so on were made
> available so people could see "how it was done" with Blender.
>
> Do you remember in the early days of the London Python Code Dojo we
> collaboratively created a text based adventure game? Each month we'd
> choose an aspect of such a game, make it work in groups and then, at the
> end of the show and tell, merge the democratically elected "blessed"
> solution to become the basis of the next month's task. Might that be a
> modus operandi for such a game?
>
> Just throwing out thoughts...
>
> N.
>
> On 22/08/18 11:24, René Dudfield wrote:
> > Weatbag is a funny name, in the best ever way :)
> > Yeah, this sounds like a interesting idea.
> > Where each person can create a different module for a separate part of
> > the game world.
> >
> > I think the reddit group tried a couple of collaborative games too.
> > I'm pretty sure minecraft came about as part of this idea of a
> > collaborative game.
> > At the time there was a python game where people could also write bots
> > that would battle each other.
> >
> > Yeah, could lord.mauve be convinced to do such a game in pyweek?
> > Pretty fun idea IMHO.
> >
> >
> > ---
> >
> > But the direction I was thinking of was more in the line of the Blender
> > short films (open projects).
> > https://www.blender.org/about/projects/
> >
> > This would be a commercial project funded by either a publisher, crowd
> > funding, grants, or some combination of these.
> > The team would be made up from people in the pygame community. A
> > pyweek/ludumdare winner as programmer and designer, a musician
> > (hopefully someone using pygame to make music!), a gfx artist(again
> > someone using pygame), someone working on pygame tools to support the
> > production, and perhaps someone working on project management and
> marketing.
> > In the same way as the Blender open short film projects work, pygame
> > development by the tools programmer would be driven by the games needs,
> > and then these improvements would be available for other people using
> > pygame. Also, the resulting game should hopefully be of higher quality
> > than other productions. And of course it would be an open project
> > (transparent, and the results released as FLOSS).
> >
> >
> >
> >
> >
> >
> >
> > On Tuesday, August 21, 2018, Th

Re: [pygame] Re: About Pygame development

[Nicholas H.Tollervey]

Rene,

The OP is wonderful to read, and so much of it chimes with my experience
in floss development. Perhaps turn it into a blog post so people can
point to it and share it?

I love Thomas's idea of a PyGame "game" - it reminds me of Blender's
"Big Buck Bunny" film where all the assets, source and so on were made
available so people could see "how it was done" with Blender.

Do you remember in the early days of the London Python Code Dojo we
collaboratively created a text based adventure game? Each month we'd
choose an aspect of such a game, make it work in groups and then, at the
end of the show and tell, merge the democratically elected "blessed"
solution to become the basis of the next month's task. Might that be a
modus operandi for such a game?

Just throwing out thoughts...

N.

On 22/08/18 11:24, René Dudfield wrote:
> Weatbag is a funny name, in the best ever way :)
> Yeah, this sounds like a interesting idea.
> Where each person can create a different module for a separate part of
> the game world.
> 
> I think the reddit group tried a couple of collaborative games too.
> I'm pretty sure minecraft came about as part of this idea of a
> collaborative game.
> At the time there was a python game where people could also write bots
> that would battle each other.
> 
> Yeah, could lord.mauve be convinced to do such a game in pyweek?
> Pretty fun idea IMHO.
> 
> 
> ---
> 
> But the direction I was thinking of was more in the line of the Blender
> short films (open projects).
> https://www.blender.org/about/projects/
> 
> This would be a commercial project funded by either a publisher, crowd
> funding, grants, or some combination of these.
> The team would be made up from people in the pygame community. A
> pyweek/ludumdare winner as programmer and designer, a musician
> (hopefully someone using pygame to make music!), a gfx artist(again
> someone using pygame), someone working on pygame tools to support the
> production, and perhaps someone working on project management and marketing.
> In the same way as the Blender open short film projects work, pygame
> development by the tools programmer would be driven by the games needs,
> and then these improvements would be available for other people using
> pygame. Also, the resulting game should hopefully be of higher quality
> than other productions. And of course it would be an open project
> (transparent, and the results released as FLOSS).
> 
> 
> 
> 
> 
> 
> 
> On Tuesday, August 21, 2018, Thomas Kluyver  > wrote:
> 
> Thanks René,
> 
> I think there's a lot of interesting ideas in your message. One in
> particular that caught my attention:
> 
> On Tue, 21 Aug 2018 at 17:24, René Dudfield  > wrote:
> 
> It could be pretty Epic to have some sort of 'pygame community
> game'.
> 
> 
> A few years back, I tried to make a collaboratively developed text
> adventure game which I called Weatbag, for 'Written by everyone all
> together, the big adventure game'. It didn't really go anywhere, but
> I learned that the idea wasn't new - people called such games
> Multi-User Dungeons, or MUDs. I still think it could be a really fun
> idea, and I'd be interested to see it extended to a game with simple
> graphics.
> 
> The idea with Weatbag was that the user could move between squares
> on a NESW grid, with the information about each square stored in a
> separate module. Any square which didn't already exist could be
> claimed by submitting a pull request to add something there. I
> wonder if it would be possible to do something similar with a
> graphical game? Maybe with a collection of sprites and textures to
> use so people could compose a simple scene without having to create
> new artwork?
> 
> Maybe this could be a fun project for a future pyweek or something -
> put together enough of a game to be playable, and build a framework
> for outside contributors to easily extend the game after the contest.
> 
> Thomas
> 



signature.asc
Description: OpenPGP digital signature

Re: [pygame] Re: About Pygame development

[Thomas Kluyver]

Thanks René,

I think there's a lot of interesting ideas in your message. One in
particular that caught my attention:

On Tue, 21 Aug 2018 at 17:24, René Dudfield  wrote:

> It could be pretty Epic to have some sort of 'pygame community game'.
>

A few years back, I tried to make a collaboratively developed text
adventure game which I called Weatbag, for 'Written by everyone all
together, the big adventure game'. It didn't really go anywhere, but I
learned that the idea wasn't new - people called such games Multi-User
Dungeons, or MUDs. I still think it could be a really fun idea, and I'd be
interested to see it extended to a game with simple graphics.

The idea with Weatbag was that the user could move between squares on a
NESW grid, with the information about each square stored in a separate
module. Any square which didn't already exist could be claimed by
submitting a pull request to add something there. I wonder if it would be
possible to do something similar with a graphical game? Maybe with a
collection of sprites and textures to use so people could compose a simple
scene without having to create new artwork?

Maybe this could be a fun project for a future pyweek or something - put
together enough of a game to be playable, and build a framework for outside
contributors to easily extend the game after the contest.

Thomas

Re: [pygame] Re: Starting the pygame 2 series

[Chris Handy]

My daytime job is writing cross-platform code in Python; I'm happy to help
out with either Windows, Linux or Mac builds.

On 1 August 2018 at 04:54, Luke Paireepinart  wrote:

> Sounds reasonable to major version up with SDL. Is there a sponsor on the
> list for the windows builds of pygame? If not, I would love to volunteer
> for this.
>
>
> On Tue, Jul 31, 2018, 7:29 AM René Dudfield  wrote:
>
>> So. I've been thinking how to have SDL2 and SDL1 releases on pypi at the
>> same time.
>>
>> 1.9.5.devX releases, with SDL1 being compiled in.
>> 2.0.0.devX releases, using SDL2 stuff.
>>
>> The benefit is that we can:
>>
>>- 'release early, release often'. The fact is most people only test,
>>or try things out once things are released.
>>- we need help testing a SDL2 pygame, and having it on pypi makes
>>that easy for people. My guess is only 2-3 people have tried the SDL2
>>branch so far for example.
>>- there's only one tree, which is easier to maintain than separate
>>branches.
>>- we also need help testing SDL1 stuff, to make sure it hasn't broken.
>>
>>
>>
>> *Step 1.*
>> The first step is to get the continuous releases working, and I'll reset
>> the version number in git master to 1.9.5.dev0
>> Each merge into master will do a release to pypi as 1.9.5.devX, where X
>> is the number of commits since the last release tag (1.9.4).
>>
>>
>> *Step 2.*
>> Unfortunately I don't see a way to merge the SDL2 branch in incrementally.
>> So I'll do a big merge of the SDL2 stuff into master.
>> With SDL1 being the default.
>>
>> *Step 3.*
>> Do the repo files cleanup (mentioned earlier).
>>
>>
>> *Step 4.*
>> Get pygame 2 working on non-linux platforms.
>> Get continuous deploys working for pygame 2.0.0.devX.
>>
>> *Step 5.*
>> There will be a pygame 1.9.5 release with the API cleanup, and disabled
>> SDL2 support.
>> Including other platform fixes (like how *BSD pygame is broken currently).
>>
>>
>> So, that's the plan.
>>
>

Re: [pygame] Re: Starting the pygame 2 series

[Luke Paireepinart]

Sounds reasonable to major version up with SDL. Is there a sponsor on the
list for the windows builds of pygame? If not, I would love to volunteer
for this.

On Tue, Jul 31, 2018, 7:29 AM René Dudfield  wrote:

> So. I've been thinking how to have SDL2 and SDL1 releases on pypi at the
> same time.
>
> 1.9.5.devX releases, with SDL1 being compiled in.
> 2.0.0.devX releases, using SDL2 stuff.
>
> The benefit is that we can:
>
>- 'release early, release often'. The fact is most people only test,
>or try things out once things are released.
>- we need help testing a SDL2 pygame, and having it on pypi makes that
>easy for people. My guess is only 2-3 people have tried the SDL2 branch so
>far for example.
>- there's only one tree, which is easier to maintain than separate
>branches.
>- we also need help testing SDL1 stuff, to make sure it hasn't broken.
>
>
>
> *Step 1.*
> The first step is to get the continuous releases working, and I'll reset
> the version number in git master to 1.9.5.dev0
> Each merge into master will do a release to pypi as 1.9.5.devX, where X is
> the number of commits since the last release tag (1.9.4).
>
>
> *Step 2.*
> Unfortunately I don't see a way to merge the SDL2 branch in incrementally.
> So I'll do a big merge of the SDL2 stuff into master.
> With SDL1 being the default.
>
> *Step 3.*
> Do the repo files cleanup (mentioned earlier).
>
>
> *Step 4.*
> Get pygame 2 working on non-linux platforms.
> Get continuous deploys working for pygame 2.0.0.devX.
>
> *Step 5.*
> There will be a pygame 1.9.5 release with the API cleanup, and disabled
> SDL2 support.
> Including other platform fixes (like how *BSD pygame is broken currently).
>
>
> So, that's the plan.
>

Re: USEREVENT clash fix, was Re: [pygame] Re: Starting the pygame 2 series

[Sam Bull]

On Sat, 2018-07-28 at 09:59 +0200, René Dudfield wrote:
> > def custom_type():
> >     """ Return an event type we can use for our own events.
> >     """

Don't forget to mention in the documentation that StopIteration will be raised
if there are no more event types available.

signature.asc
Description: This is a digitally signed message part

USEREVENT clash fix, was Re: [pygame] Re: Starting the pygame 2 series

[René Dudfield]

Hello,

how about this below for the custom event type API? Then we hide the
USEREVENT in the docs, and suggest people use this. Then libraries can
exist without stomping over each others events. Also, I think custom_type
is a bit of a better name. Because it's an event type(not an event), and
it's custom.

What do you reckon?

PIRATE_APPROACH = pygame.event.custom_type()
>
> e = pygame.event.Event(PIRATE_APPROACH, num=5)
> pygame.event.post(e)
>
> for e in events:
> if e.type == PIRATE_APPROACH:
> print('pirates are coming!')
>


It would be implemented something like this (thanks Sam!)

_CUSTOM_EVENT = iter(range(pygame.constants.USEREVENT,
> pygame.constants.NUMEVENTS))
>
> def custom_type():
> """ Return an event type we can use for our own events.
> """
> return next(_CUSTOM_EVENT)
>

Issue is here:
https://github.com/pygame/pygame/issues/477

Re: [pygame] Re: Starting the pygame 2 series

[René Dudfield]

Good idea to clean up that part :)

Re: [pygame] Re: Starting the pygame 2 series

[Sam Bull]

One small thing I've been thinking about for a while, is that it would be useful
to stop encouraging developers to use USEREVENT directly, and add a mechanism to
generate custom events. I've finally written up my thoughts here:
https://github.com/pygame/pygame/issues/477

Might be a good thing to have done for Pygame 2, even if it is a relatively
small detail.

> On Thu, Jul 19, 2018 at 12:06 PM, René Dudfield  wrote:
> > Hello,
> > 
> > with 1.9.4 out, it's time to start the 2.0 series. (right?)
> > https://github.com/pygame/pygame/pull/471
> > 
> > Which means something like...
> > keeping everything working as we work...
> > beginning to slowly merge in Lenard's work on the SDL2, and C API clean up
> > branches.
> > finish the work which will allow continuous releases without us manually
> > dealing with 40+ builds. We will need lots of help testing SDL2 stuff.
> > clean things up
> > 
> > cheers,
> > 


signature.asc
Description: This is a digitally signed message part

Re: [pygame] Re: Some way to pickle or otherwise save a pygame.mixer.Sound object?

[Alec Bennett]

On Sat, Jun 9, 2018 at 12:44 PM, Christopher Night 
wrote:

> Just to be clear, you need to play two different multi-minute sounds at
> once?
>

There's a library of long songs, and a library of short sound effects.
There's never more than one long song playing at a time.

>
> why don't you just preload the 3-second one into a pygame.mixer.Sound
> object and play it whenever you need it, and play the 13-minute one with
> pygame.mixer.music?
>

D'oh! Good idea, I'm embarrassed that I didn't think of it. Done and
problem solved.

Re: [pygame] Re: Some way to pickle or otherwise save a pygame.mixer.Sound object?

[Luke Paireepinart]

The wav format is not super complicated, you could split every track into
15 second chunks and read them off disk as needed so you always have one
extra 15 second chunk than you currently need. You could probably even make
fake file objects that mapped to the same file on disk using seeks, and use
that to buffer over the files. Then you could throw out the buffers as they
were used up.

On Sat, Jun 9, 2018, 2:45 PM Christopher Night 
wrote:

> Just to be clear, you need to play two different multi-minute sounds at
> once?
>
> Because your example has one 13-minute track and one 3-second track. If
> those are the sounds you need to play at the same time, why don't you just
> preload the 3-second one into a pygame.mixer.Sound object and play it
> whenever you need it, and play the 13-minute one with pygame.mixer.music?
>
> On Fri, Jun 8, 2018 at 7:48 PM Alec Bennett  wrote:
>
>> I see that pygame.mixer.Sound supports OGG, I guess I should try that.
>>> I've never used OGG before, and I wonder if it supports OGG if MP3 would be
>>> an easy addition?
>>>
>>
>> Well so much for using OGG (and probably MP3) to speed up preloading.
>> With my 13 minute mono soundfiles, it takes 7.3 seconds to preload the wav
>> file (44.1hz, 16 bit, mono) and 43.6 seconds to preload the OGG file... I
>> have a feeling it's uncompressing it during preload.
>>
>>>
>> My project needs polyphony, but really only the ability to play two
>> sounds at once. I'm currently using this method because it supports that:
>>
>>>
>> channel = 1 # or 2
>>
>>> sound_obj = pygame.mixer.Sound("whatever.wav") # long preload at this
>> step
>>
>>> channel = pygame.mixer.Channel(channel)
>>
>>> channel.play(sound_obj)
>>
>>>
>> This method of playing MP3 works beautifully without preloading, but can
>> only play one sound at a time:
>>
>>>
>> pygame.mixer.init()
>>
>>> pygame.mixer.music.load("whatever.mp3")
>>
>>> pygame.mixer.music.play()
>>
>>> pygame.event.wait()
>>
>>>
>> I don't imagine anyone knows of a way to play two sound files
>> simultaneously using  pygame.mixer.music? Or some other solution in Python
>> under Linux that would do it reliably? I suppose I could slave two
>> instances of mplayer, but I'd of course prefer to not be forking out
>> processes.
>>
>> If anyone's curious about the files I'm trying to load, I posted some
>> test files here:
>>
>> sinkingsensation.com/dropbox/icecream.zip
>>
>>
>>
>>
>> On Thu, Jun 7, 2018 at 2:30 PM, Alec Bennett  wrote:
>>
>>>
>>>
>>> On Thu, Jun 7, 2018 at 7:59 AM, Christopher Night <
>>> cosmologi...@gmail.com> wrote:
>>>
 I recommend saving the sound as a raw buffer. First in a separate
 script:

 sound = pygame.mixer.Sound("music1.wav")
 open("music1.buf", "wb").write(sound.get_raw())

 Then in your game:
 sound = pygame.mixer.Sound(buffer=open("music1.buf", "rb").read())

 I found about 4x speedup of reading a large file on my desktop using
 this method. That may or may not be enough for you, especially if you
 combine with other tips in this thread.

>>>
>>>
>>> Very interesting. Will try this when I'm working on this tonight.
>>>
>>>
>>>
>>>
>>>
>>

Re: [pygame] Re: Some way to pickle or otherwise save a pygame.mixer.Sound object?

[Christopher Night]

Just to be clear, you need to play two different multi-minute sounds at
once?

Because your example has one 13-minute track and one 3-second track. If
those are the sounds you need to play at the same time, why don't you just
preload the 3-second one into a pygame.mixer.Sound object and play it
whenever you need it, and play the 13-minute one with pygame.mixer.music?

On Fri, Jun 8, 2018 at 7:48 PM Alec Bennett  wrote:

> I see that pygame.mixer.Sound supports OGG, I guess I should try that.
>> I've never used OGG before, and I wonder if it supports OGG if MP3 would be
>> an easy addition?
>>
>
> Well so much for using OGG (and probably MP3) to speed up preloading. With
> my 13 minute mono soundfiles, it takes 7.3 seconds to preload the wav file
> (44.1hz, 16 bit, mono) and 43.6 seconds to preload the OGG file... I have a
> feeling it's uncompressing it during preload.
>
>>
> My project needs polyphony, but really only the ability to play two sounds
> at once. I'm currently using this method because it supports that:
>
>>
> channel = 1 # or 2
>
>> sound_obj = pygame.mixer.Sound("whatever.wav") # long preload at this step
>
>> channel = pygame.mixer.Channel(channel)
>
>> channel.play(sound_obj)
>
>>
> This method of playing MP3 works beautifully without preloading, but can
> only play one sound at a time:
>
>>
> pygame.mixer.init()
>
>> pygame.mixer.music.load("whatever.mp3")
>
>> pygame.mixer.music.play()
>
>> pygame.event.wait()
>
>>
> I don't imagine anyone knows of a way to play two sound files
> simultaneously using  pygame.mixer.music? Or some other solution in Python
> under Linux that would do it reliably? I suppose I could slave two
> instances of mplayer, but I'd of course prefer to not be forking out
> processes.
>
> If anyone's curious about the files I'm trying to load, I posted some test
> files here:
>
> sinkingsensation.com/dropbox/icecream.zip
>
>
>
>
> On Thu, Jun 7, 2018 at 2:30 PM, Alec Bennett  wrote:
>
>>
>>
>> On Thu, Jun 7, 2018 at 7:59 AM, Christopher Night > > wrote:
>>
>>> I recommend saving the sound as a raw buffer. First in a separate script:
>>>
>>> sound = pygame.mixer.Sound("music1.wav")
>>> open("music1.buf", "wb").write(sound.get_raw())
>>>
>>> Then in your game:
>>> sound = pygame.mixer.Sound(buffer=open("music1.buf", "rb").read())
>>>
>>> I found about 4x speedup of reading a large file on my desktop using
>>> this method. That may or may not be enough for you, especially if you
>>> combine with other tips in this thread.
>>>
>>
>>
>> Very interesting. Will try this when I'm working on this tonight.
>>
>>
>>
>>
>>
>

Re: [pygame] Re: Some way to pickle or otherwise save a pygame.mixer.Sound object?

[Alec Bennett]

>
> I see that pygame.mixer.Sound supports OGG, I guess I should try that.
> I've never used OGG before, and I wonder if it supports OGG if MP3 would be
> an easy addition?
>

Well so much for using OGG (and probably MP3) to speed up preloading. With
my 13 minute mono soundfiles, it takes 7.3 seconds to preload the wav file
(44.1hz, 16 bit, mono) and 43.6 seconds to preload the OGG file... I have a
feeling it's uncompressing it during preload.

>
My project needs polyphony, but really only the ability to play two sounds
at once. I'm currently using this method because it supports that:

>
channel = 1 # or 2

> sound_obj = pygame.mixer.Sound("whatever.wav") # long preload at this step

> channel = pygame.mixer.Channel(channel)

> channel.play(sound_obj)

>
This method of playing MP3 works beautifully without preloading, but can
only play one sound at a time:

>
pygame.mixer.init()

> pygame.mixer.music.load("whatever.mp3")

> pygame.mixer.music.play()

> pygame.event.wait()

>
I don't imagine anyone knows of a way to play two sound files
simultaneously using  pygame.mixer.music? Or some other solution in Python
under Linux that would do it reliably? I suppose I could slave two
instances of mplayer, but I'd of course prefer to not be forking out
processes.

If anyone's curious about the files I'm trying to load, I posted some test
files here:

sinkingsensation.com/dropbox/icecream.zip




On Thu, Jun 7, 2018 at 2:30 PM, Alec Bennett  wrote:

>
>
> On Thu, Jun 7, 2018 at 7:59 AM, Christopher Night 
> wrote:
>
>> I recommend saving the sound as a raw buffer. First in a separate script:
>>
>> sound = pygame.mixer.Sound("music1.wav")
>> open("music1.buf", "wb").write(sound.get_raw())
>>
>> Then in your game:
>> sound = pygame.mixer.Sound(buffer=open("music1.buf", "rb").read())
>>
>> I found about 4x speedup of reading a large file on my desktop using this
>> method. That may or may not be enough for you, especially if you combine
>> with other tips in this thread.
>>
>
>
> Very interesting. Will try this when I'm working on this tonight.
>
>
>
>
>

Re: [pygame] Re: Some way to pickle or otherwise save a pygame.mixer.Sound object?

[Alec Bennett]

On Thu, Jun 7, 2018 at 7:59 AM, Christopher Night 
wrote:

> I recommend saving the sound as a raw buffer. First in a separate script:
>
> sound = pygame.mixer.Sound("music1.wav")
> open("music1.buf", "wb").write(sound.get_raw())
>
> Then in your game:
> sound = pygame.mixer.Sound(buffer=open("music1.buf", "rb").read())
>
> I found about 4x speedup of reading a large file on my desktop using this
> method. That may or may not be enough for you, especially if you combine
> with other tips in this thread.
>


Very interesting. Will try this when I'm working on this tonight.

Re: [pygame] Re: Some way to pickle or otherwise save a pygame.mixer.Sound object?

[Alec Bennett]

>
>
>
> A second solution is to load the sounds in the background of the game,
> especially if you're going to launch on a menu where the sounds won't be
> needed. You can pre-populate a dictionary with dummy sounds and use a
> thread to go through and load each sound into the dictionary while the user
> interacts with the menu.
>
> SOUND_PATH_MAPPING = {'horn_funny': 'horn_funny.ogg', 'horn_sad': 
> 'extra_sounds/horn_sad.wav'}
>
> SOUNDS = {name: None for name in SOUND_PATH_MAPPING}
>
> def load_sounds():
>
> for name, path in SOUND_PATH_MAPPING:
>
> SOUNDS[name] = pygame.mixer.Sound(path)
>
>
> def load_sounds_background():
>
> thread.start_new_thread(load_sounds, ())
>
>
>

There's no menus, it just loads and waits for the user to trigger sounds on
a keypad. I could play a single sound while the other sounds are loading,
but I'd prefer to have it fully functional at startup if possible.

Re: [pygame] Re: Some way to pickle or otherwise save a pygame.mixer.Sound object?

[Christopher Night]

I recommend saving the sound as a raw buffer. First in a separate script:

sound = pygame.mixer.Sound("music1.wav")
open("music1.buf", "wb").write(sound.get_raw())

Then in your game:
sound = pygame.mixer.Sound(buffer=open("music1.buf", "rb").read())

I found about 4x speedup of reading a large file on my desktop using this
method. That may or may not be enough for you, especially if you combine
with other tips in this thread.

On Thu, Jun 7, 2018 at 10:08 AM Daniel Foerster  wrote:

> It looks like you may have missed the alternative solution in my email.
>
> On Thu, Jun 7, 2018, 01:04 Alec Bennett  wrote:
>
>> > I think the answer that sticks out to me is that if these are musical
>> horn sounds, you might consider using pygame.mixer.music, which will stream
>> the sounds as needed.
>>
>> A very good idea, and the route I originally took, but as far as I can
>> tell pygame.mixer.music doesn't support polyphony, and I occasionally need
>> to play multiple sounds at once.
>>
>>
>>
>>
>>
>> On Wed, Jun 6, 2018 at 10:59 PM, Daniel Foerster 
>> wrote:
>>
>>> I think the answer that sticks out to me is that if these are musical
>>> horn sounds, you might consider using pygame.mixer.music, which will stream
>>> the sounds as needed. However, this won't work if you have other music
>>> playing or if you want multiple horns to be able to play at the same time.
>>>
>>> A second solution is to load the sounds in the background of the game,
>>> especially if you're going to launch on a menu where the sounds won't be
>>> needed. You can pre-populate a dictionary with dummy sounds and use a
>>> thread to go through and load each sound into the dictionary while the user
>>> interacts with the menu.
>>>
>>> SOUND_PATH_MAPPING = {'horn_funny': 'horn_funny.ogg', 'horn_sad': 
>>> 'extra_sounds/horn_sad.wav'}
>>>
>>> SOUNDS = {name: None for name in SOUND_PATH_MAPPING}
>>>
>>> def load_sounds():
>>>
>>> for name, path in SOUND_PATH_MAPPING:
>>>
>>> SOUNDS[name] = pygame.mixer.Sound(path)
>>>
>>>
>>> def load_sounds_background():
>>>
>>> thread.start_new_thread(load_sounds, ())
>>>
>>>
>>> If there's a legitimate chance that the player might try to use the horn
>>> sounds before they've finished loading, just have the horn logic check for
>>> Nones before trying to play or have a dummy sound object with a play method
>>> that does nothing.
>>>
>>> A full example of how you might do this with a class:
>>> https://gist.github.com/pydsigner/231c0812f9f91050dd83c744d6d5dc4b
>>>
>>> On Thu, Jun 7, 2018 at 12:31 AM, Alec Bennett 
>>> wrote:
>>>
 Sorry, I left out the line where I try to save the file:

 > pickle.dump( sound_obj, open( "sound.pickled", "wb" ) )



 On Wed, Jun 6, 2018 at 10:29 PM, Alec Bennett 
 wrote:

> I'm building a musical horn for my car with PyGame, and it works
> perfectly, but since it needs to load each of the 20 sounds on startup it
> takes about 30 seconds to load. I'm running it on a Raspberry Pi, which
> doesn't help of course.
>
> I thought I'd simply save the Sound objects as pickle objects, but
> that produces an error:
>
> > sound_obj = pygame.mixer.Sound("whatever.wav")
>
> > can't pickle Sound objects
>
> I also tried the dill module (https://github.com/uqfoundation/dill)
> but with similar results:
>
> > sound_obj = pygame.mixer.Sound("whatever.wav")
>
> > Can't pickle : it's not found as __builtin__.Sound
>
> I don't imagine can think of some clever way to save the preloaded
> Sounds, or otherwise speed up the load times?
>
>
>
>
>

>>>
>>

Re: [pygame] Re: Some way to pickle or otherwise save a pygame.mixer.Sound object?

[Daniel Foerster]

It looks like you may have missed the alternative solution in my email.

On Thu, Jun 7, 2018, 01:04 Alec Bennett  wrote:

> > I think the answer that sticks out to me is that if these are musical
> horn sounds, you might consider using pygame.mixer.music, which will stream
> the sounds as needed.
>
> A very good idea, and the route I originally took, but as far as I can
> tell pygame.mixer.music doesn't support polyphony, and I occasionally need
> to play multiple sounds at once.
>
>
>
>
>
> On Wed, Jun 6, 2018 at 10:59 PM, Daniel Foerster 
> wrote:
>
>> I think the answer that sticks out to me is that if these are musical
>> horn sounds, you might consider using pygame.mixer.music, which will stream
>> the sounds as needed. However, this won't work if you have other music
>> playing or if you want multiple horns to be able to play at the same time.
>>
>> A second solution is to load the sounds in the background of the game,
>> especially if you're going to launch on a menu where the sounds won't be
>> needed. You can pre-populate a dictionary with dummy sounds and use a
>> thread to go through and load each sound into the dictionary while the user
>> interacts with the menu.
>>
>> SOUND_PATH_MAPPING = {'horn_funny': 'horn_funny.ogg', 'horn_sad': 
>> 'extra_sounds/horn_sad.wav'}
>>
>> SOUNDS = {name: None for name in SOUND_PATH_MAPPING}
>>
>> def load_sounds():
>>
>> for name, path in SOUND_PATH_MAPPING:
>>
>> SOUNDS[name] = pygame.mixer.Sound(path)
>>
>>
>> def load_sounds_background():
>>
>> thread.start_new_thread(load_sounds, ())
>>
>>
>> If there's a legitimate chance that the player might try to use the horn
>> sounds before they've finished loading, just have the horn logic check for
>> Nones before trying to play or have a dummy sound object with a play method
>> that does nothing.
>>
>> A full example of how you might do this with a class:
>> https://gist.github.com/pydsigner/231c0812f9f91050dd83c744d6d5dc4b
>>
>> On Thu, Jun 7, 2018 at 12:31 AM, Alec Bennett  wrote:
>>
>>> Sorry, I left out the line where I try to save the file:
>>>
>>> > pickle.dump( sound_obj, open( "sound.pickled", "wb" ) )
>>>
>>>
>>>
>>> On Wed, Jun 6, 2018 at 10:29 PM, Alec Bennett 
>>> wrote:
>>>
 I'm building a musical horn for my car with PyGame, and it works
 perfectly, but since it needs to load each of the 20 sounds on startup it
 takes about 30 seconds to load. I'm running it on a Raspberry Pi, which
 doesn't help of course.

 I thought I'd simply save the Sound objects as pickle objects, but that
 produces an error:

 > sound_obj = pygame.mixer.Sound("whatever.wav")

 > can't pickle Sound objects

 I also tried the dill module (https://github.com/uqfoundation/dill)
 but with similar results:

 > sound_obj = pygame.mixer.Sound("whatever.wav")

 > Can't pickle : it's not found as __builtin__.Sound

 I don't imagine can think of some clever way to save the preloaded
 Sounds, or otherwise speed up the load times?





>>>
>>
>

Re: [pygame] Re: Some way to pickle or otherwise save a pygame.mixer.Sound object?

[Alec Bennett]

> I think the answer that sticks out to me is that if these are musical
horn sounds, you might consider using pygame.mixer.music, which will stream
the sounds as needed.

A very good idea, and the route I originally took, but as far as I can tell
pygame.mixer.music doesn't support polyphony, and I occasionally need to
play multiple sounds at once.





On Wed, Jun 6, 2018 at 10:59 PM, Daniel Foerster 
wrote:

> I think the answer that sticks out to me is that if these are musical horn
> sounds, you might consider using pygame.mixer.music, which will stream the
> sounds as needed. However, this won't work if you have other music playing
> or if you want multiple horns to be able to play at the same time.
>
> A second solution is to load the sounds in the background of the game,
> especially if you're going to launch on a menu where the sounds won't be
> needed. You can pre-populate a dictionary with dummy sounds and use a
> thread to go through and load each sound into the dictionary while the user
> interacts with the menu.
>
> SOUND_PATH_MAPPING = {'horn_funny': 'horn_funny.ogg', 'horn_sad': 
> 'extra_sounds/horn_sad.wav'}
>
> SOUNDS = {name: None for name in SOUND_PATH_MAPPING}
>
> def load_sounds():
>
> for name, path in SOUND_PATH_MAPPING:
>
> SOUNDS[name] = pygame.mixer.Sound(path)
>
>
> def load_sounds_background():
>
> thread.start_new_thread(load_sounds, ())
>
>
> If there's a legitimate chance that the player might try to use the horn
> sounds before they've finished loading, just have the horn logic check for
> Nones before trying to play or have a dummy sound object with a play method
> that does nothing.
>
> A full example of how you might do this with a class:
> https://gist.github.com/pydsigner/231c0812f9f91050dd83c744d6d5dc4b
>
> On Thu, Jun 7, 2018 at 12:31 AM, Alec Bennett  wrote:
>
>> Sorry, I left out the line where I try to save the file:
>>
>> > pickle.dump( sound_obj, open( "sound.pickled", "wb" ) )
>>
>>
>>
>> On Wed, Jun 6, 2018 at 10:29 PM, Alec Bennett  wrote:
>>
>>> I'm building a musical horn for my car with PyGame, and it works
>>> perfectly, but since it needs to load each of the 20 sounds on startup it
>>> takes about 30 seconds to load. I'm running it on a Raspberry Pi, which
>>> doesn't help of course.
>>>
>>> I thought I'd simply save the Sound objects as pickle objects, but that
>>> produces an error:
>>>
>>> > sound_obj = pygame.mixer.Sound("whatever.wav")
>>>
>>> > can't pickle Sound objects
>>>
>>> I also tried the dill module (https://github.com/uqfoundation/dill) but
>>> with similar results:
>>>
>>> > sound_obj = pygame.mixer.Sound("whatever.wav")
>>>
>>> > Can't pickle : it's not found as __builtin__.Sound
>>>
>>> I don't imagine can think of some clever way to save the preloaded
>>> Sounds, or otherwise speed up the load times?
>>>
>>>
>>>
>>>
>>>
>>
>

Re: [pygame] Re: Some way to pickle or otherwise save a pygame.mixer.Sound object?

[Daniel Foerster]

I think the answer that sticks out to me is that if these are musical horn
sounds, you might consider using pygame.mixer.music, which will stream the
sounds as needed. However, this won't work if you have other music playing
or if you want multiple horns to be able to play at the same time.

A second solution is to load the sounds in the background of the game,
especially if you're going to launch on a menu where the sounds won't be
needed. You can pre-populate a dictionary with dummy sounds and use a
thread to go through and load each sound into the dictionary while the user
interacts with the menu.

SOUND_PATH_MAPPING = {'horn_funny': 'horn_funny.ogg', 'horn_sad':
'extra_sounds/horn_sad.wav'}

SOUNDS = {name: None for name in SOUND_PATH_MAPPING}

def load_sounds():

for name, path in SOUND_PATH_MAPPING:

SOUNDS[name] = pygame.mixer.Sound(path)


def load_sounds_background():

thread.start_new_thread(load_sounds, ())


If there's a legitimate chance that the player might try to use the horn
sounds before they've finished loading, just have the horn logic check for
Nones before trying to play or have a dummy sound object with a play method
that does nothing.

A full example of how you might do this with a class:
https://gist.github.com/pydsigner/231c0812f9f91050dd83c744d6d5dc4b

On Thu, Jun 7, 2018 at 12:31 AM, Alec Bennett  wrote:

> Sorry, I left out the line where I try to save the file:
>
> > pickle.dump( sound_obj, open( "sound.pickled", "wb" ) )
>
>
>
> On Wed, Jun 6, 2018 at 10:29 PM, Alec Bennett  wrote:
>
>> I'm building a musical horn for my car with PyGame, and it works
>> perfectly, but since it needs to load each of the 20 sounds on startup it
>> takes about 30 seconds to load. I'm running it on a Raspberry Pi, which
>> doesn't help of course.
>>
>> I thought I'd simply save the Sound objects as pickle objects, but that
>> produces an error:
>>
>> > sound_obj = pygame.mixer.Sound("whatever.wav")
>>
>> > can't pickle Sound objects
>>
>> I also tried the dill module (https://github.com/uqfoundation/dill) but
>> with similar results:
>>
>> > sound_obj = pygame.mixer.Sound("whatever.wav")
>>
>> > Can't pickle : it's not found as __builtin__.Sound
>>
>> I don't imagine can think of some clever way to save the preloaded
>> Sounds, or otherwise speed up the load times?
>>
>>
>>
>>
>>
>

Re: [pygame] Re: `pygame.draw.line(...)` `width`

[Al Sweigart]

I'd also be in favor of this change to squared-off miter joints. I've
noticed the odd endcap behavior in Pygame a long time ago, and it's one
reason that I never used the line drawing function for lines with large
widths.

-Al

On Sat, Apr 28, 2018 at 1:35 PM, Ian Mallett  wrote:

> ​By the way, a solution doesn't even need to use any trigonometry, because
> a squared-off miter joint is by-definition orthogonal to the line. Here's
> some proof-of-concept code:
>
> def rndint(x): return int(round(x))
> def cappedline(surface, color, p0,p1, width=1, rounded=True):
> radius = width * 0.5
> delta = ( p1[0]-p0[0], p1[1]-p0[1] )
> orthog = [ delta[1], -delta[0] ]
> scale = radius / (orthog[0]*orthog[0] + orthog[1]*orthog[1])**0.5
> orthog[0]*=scale; orthog[1]*=scale
> points = [
> ( p0[0]-orthog[0], p0[1]-orthog[1] ),
> ( p0[0]+orthog[0], p0[1]+orthog[1] ),
> ( p1[0]+orthog[0], p1[1]+orthog[1] ),
> ( p1[0]-orthog[0], p1[1]-orthog[1] )
> ]
> pygame.draw.polygon(surface, color, points)
> if rounded:
> #Could have added these to the polygon points instead, but then
> we'd have had to choose a subdivision accuracy.
> pygame.draw.circle(surface, color, (rndint(p0[0]),rndint(p0[1])),
> rndint(radius))
> pygame.draw.circle(surface, color, (rndint(p1[0]),rndint(p1[1])),
> rndint(radius))
> pygame.draw.cappedline = cappedline
>
> Note that this also supports rounded corners by drawing circles on the
> ends, although this is rather limited by the (poor) accuracy of the circle
> drawing routine, and doesn't look fabulous at small widths.
>
> Ian
>

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

[René Dudfield]

I'll merge this in now. Consider it stable(ish).

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

[René Dudfield]

Hi,

here is a PR for Vector changes from our discussion here (and elsewhere).
https://github.com/pygame/pygame/pull/416


   - Tests and fixes for keyword arguments with Vector2 Vector3
   - Tests for Vector2, and Vector3 scalar constructors like GLSL.
   Vector3(1) -> Vector3(1, 1, 1)
   - missing an element is an error now, no zero default. Vector3(1, 2),
   and Vector3(x=1, y=2)  fails.
   - Added magnitude to Vector types, which is an alias for length.
   - pygame.math require import (no missing module).
   - pygame.Vector2 pygame.Vector3 available.
   - Not in pygame.locals for now, to avoid possible breakage with common
   Vector2/Vector3 names.


The one breakage is for when people were doing:
  - Vector2(1), which used to give Vector2(1, 0), and now gives Vector2(1,
1).
  - Vector3(1), which used to give Vector3(1, 0, 0), or Vector3(1,2) which
used to give Vector3(1,2,0).


This should be the last of the changes to the Vector stuff for now to be
released in 1.9.4.
Other things can be added later without breaking backwards compatibility.


ciao,


On Sun, Mar 4, 2018 at 1:32 AM, Greg Ewing 
wrote:

> Russell Jones wrote:
>
>> IDK about physics, but AIUI, Z points from side to side, Y points down
>> and X points diagonally; it's Λ that points up.
>>
>
> Only if your computer screen is oriented vertically.
> If you're using a tablet in your lap, Λ points forward
> and Y points backwards.
>
> So obviously the code should interrogate the orientation
> sensor of the device it's running on, if it has one, to
> figure out the correct naming of the unit vector constants.
>
> --
> Greg
>
>

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

[Greg Ewing]

Russell Jones wrote:
IDK about physics, but AIUI, Z points from side to side, Y points down 
and X points diagonally; it's Λ that points up.


Only if your computer screen is oriented vertically.
If you're using a tablet in your lap, Λ points forward
and Y points backwards.

So obviously the code should interrogate the orientation
sensor of the device it's running on, if it has one, to
figure out the correct naming of the unit vector constants.

--
Greg

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

[Russell Jones]

IDK about physics, but AIUI, Z points from side to side, Y points down and
X points diagonally; it's Λ that points up.

(sorry)

Russell

On 1 March 2018 at 08:43, Greg Ewing  wrote:

> Daniel Pope wrote:
>
> Y points up in real physics?
>>
>
> No, no, no. Z points up in real physics!
>
> --
> Greg
>

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

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

[Daniel Pope]

> As René pointed out in most of the Pymunk examples Y is converted so that
positive Y points up to keep examples consistent and close to "real"
physics.

Y points up in real physics?

This is making my head hurt; I need to go lie -Y. 😜

On Wed, 28 Feb 2018, 22:52 Victor Blomqvist,  wrote:

> Hi,
>
> René sent an email asking if I had any input (as the author of pymunk), so
> here I am. In general I think it seems like a very well versed vector
> library in the making :)
>
> A couple of comments:
> 1. A function that normalizes and returns the length before normalizing in
> one call can be useful and be a little bit faster than doing two calls. In
> the pymunk.vec2d class its called normalize_return_length.
>
> 2. A user asked me why a vector cant be scaled up again after it has been
> scaled down to 0 (which is not supported in the pymunk.vec2d class or
> pygame.math). It would be a very useful feature and also beginner friendly.
> However, I dont see a way to do it in a good way so I havent implemented
> anything.
>
> 3. As René pointed out in most of the Pymunk examples Y is converted so
> that positive Y points up to keep examples consistent and close to "real"
> physics. Would be nice if pygame could handle it easily, maybe something
> you could set in the beginning of you code? But Im not sure if it fits here
> :)
>
> 4. In many cases Pygame methods expect an integer, such as position in
> pygame.draw.circle(). Since Vector2 seems to be a float either some
> automatic rounding or a method Vector2.int_tuple or similar would be
> convenient?
>
> 5. You already do some benchmarking, did you try Pypy?
>
> /Victor
>
>
>
> On Tue, Feb 27, 2018 at 10:55 PM, Ian Mallett  wrote:
>
>> ​(Skims discussion)
>>
>> For e.g. `abs(Vector2(2,-1).elementwise())`, my (C++) library instead
>> handles this as `abs(Vec2(2,-1))`, returning another `Vec2`. In C++, if you
>> weren't expecting that, you get a compile error on whatever happens next,
>> whereas in Python you'll get a `TypeError`, so it's well-defined.
>>
>> If you want the vector's length, I use a function, but perhaps it's more
>> pythonic to use a method: `Vec2(2,-1).getLength()`, or
>> `Vec2(2,-1).getLengthSq()`.
>>
>> If your vector represents a complex number and you're wondering why
>> `abs(...)` shouldn't return a complex modulus, then I ask why you aren't
>> using the built-in `complex`, which is designed for this.
>>
>> Ian
>>
>
>

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

[Victor Blomqvist]

Hi,

René sent an email asking if I had any input (as the author of pymunk), so
here I am. In general I think it seems like a very well versed vector
library in the making :)

A couple of comments:
1. A function that normalizes and returns the length before normalizing in
one call can be useful and be a little bit faster than doing two calls. In
the pymunk.vec2d class its called normalize_return_length.

2. A user asked me why a vector cant be scaled up again after it has been
scaled down to 0 (which is not supported in the pymunk.vec2d class or
pygame.math). It would be a very useful feature and also beginner friendly.
However, I dont see a way to do it in a good way so I havent implemented
anything.

3. As René pointed out in most of the Pymunk examples Y is converted so
that positive Y points up to keep examples consistent and close to "real"
physics. Would be nice if pygame could handle it easily, maybe something
you could set in the beginning of you code? But Im not sure if it fits here
:)

4. In many cases Pygame methods expect an integer, such as position in
pygame.draw.circle(). Since Vector2 seems to be a float either some
automatic rounding or a method Vector2.int_tuple or similar would be
convenient?

5. You already do some benchmarking, did you try Pypy?

/Victor



On Tue, Feb 27, 2018 at 10:55 PM, Ian Mallett  wrote:

> ​(Skims discussion)
>
> For e.g. `abs(Vector2(2,-1).elementwise())`, my (C++) library instead
> handles this as `abs(Vec2(2,-1))`, returning another `Vec2`. In C++, if you
> weren't expecting that, you get a compile error on whatever happens next,
> whereas in Python you'll get a `TypeError`, so it's well-defined.
>
> If you want the vector's length, I use a function, but perhaps it's more
> pythonic to use a method: `Vec2(2,-1).getLength()`, or
> `Vec2(2,-1).getLengthSq()`.
>
> If your vector represents a complex number and you're wondering why
> `abs(...)` shouldn't return a complex modulus, then I ask why you aren't
> using the built-in `complex`, which is designed for this.
>
> Ian
>

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

[Daniel Pope]

> Vector2(x=0, y=0) -> Vector(0, 0)

If rgba and uvst are swizzle attributes, are they also accepted as kwargs?

> However, I feel this single scalar is hard to make
a mistake with accidentally passing in the wrong thing?

I don't think so. I think it could easily happen accidentally, while
refactoring.

On Tue, 27 Feb 2018, 18:19 René Dudfield,  wrote:

> Some good points. Thanks, I appreciate the discussion.
>
>
> On Tue, Feb 27, 2018 at 3:51 PM, Daniel Pope  wrote:
>
>> > Single scalar constructor should Vector2(1) == Vector2(1, 1)
>>
>> This is the kind of situation where I'd follow PEP20: "In the face of
>> ambiguity, refuse the temptation to guess." There's an obvious pitfall if
>> you expected to pass a tuple and you instead pass a scalar or the wrong
>> length tuple - it silently succeeds but constructs the wrong Vector.
>> Perhaps raise a TypeError?
>>
>>
> At the moment Vector2/3 uses keyword arguments.
> Vector2() -> Vector(0, 0)
> ​Vector2(x=0, y=0) -> Vector(0, 0)
> Vector2(1) -> Vector(1, 0)
>
> I'm beginning to think keyword arguments are wrong for this.
> Would maybe prefer to raise a TypeError as you suggest,
>   or follow GLSL behaviour and allow single scalar, error for the others.
>
> These should raise an error for sure?
>   Vector3(1, 1) # oops, I meant to type three 1s.
>   Vector3(some2d_I_thought_was_a_3d) #oops, the incoming value is of a
> different size.
>
> However, I feel this single scalar is hard to make
> a mistake with accidentally passing in the wrong thing?
>   Vector(1)
>
> Keyword arguments are also pretty useless for readability with Vector2/3.
> Because you know it's a 3 element container.
>   Vector3(x=0, y=0, z=0) VS
>   Vector3(0,0,0)
>
> It's fairly common to init vec2/vec3 in GLSL with a single number.
> Eyeballing a few scripts, maybe 10% of usage is single scalar constructor.
> And to be able to have fairly good compatibility with code from shadertoy
> might be nice.
>
>
>
>
>
> > Lower dimensional to higher dimension contructors should work:
>> > Vector3(1, Vector2(2, 3)) == Vector3(1, 2, 3)
>>
>> We don't need this because we have star args:
>>
>> Vector3(1, *Vector2(2, 3))
>>
>
> Yeah, good point.
>
> There is this error message for this case at least:
> >>> Vector3(1, (1,2))
> ValueError: Vector3 must be initialized with 3 real numbers or a
> sequence of 3 real numbers
>
> I don't think the "Lower dimensional to higher dimension constructors
> should work" bit is that important.
> It's not super common in GLSL code I've seen in the wild anyway.
>
> And as you say, we have * notation for this.
>
>
>
>
>
>
> *Some more benchmarking.*
>
> Some timing on python 3.6 (with PyArg_ParseTupleAndKeywords which supports
> keyword arguments).
> Note v3.xyz is the fastest constructor. See below with just
> PyArg_ParseTuple (no speed improvement).
>
>
> v3 = Vector3(0)
>
> %timeit v3.xyz
>
> 1000 loops, best of 3: *83.3 ns per loop*
>
> %timeit Vector3()
> 1000 loops, best of 3: 131 ns per loop
>
> %timeit Vector3(0)
> 100 loops, best of 3: 199 ns per loop
>
> %timeit Vector3(0, 0, 0)
> 100 loops, best of 3: 269 ns per loop
>
> %timeit Vector3(x=0, y=0, z=0)
> 100 loops, best of 3: 426 ns per loop
>
> %timeit Rect((0, 0, 0, 0))
> 1000 loops, best of 3: 184 ns per loop
>
> from numpy import array
> %timeit array((0,0,0))
> 100 loops, best of 3: *919 ns* per loop
>
> assert id(v3) != id(v3.xyz), ".xyz makes a copy"
>
> %timeit (0,0,0)
> 1 loops, best of 3: *14.9 ns* per loop
>
> somevec= (1, 2)
>
> %timeit Vector3(1, *somevec)
> 100 loops, best of 3: 333 ns per loop
>
> %timeit anothervec=v3.xyz;anothervec.xyz = (1, 2, 3)
> 100 loops, best of 3: 221 ns per loop
>
>
>
>
>
> *Now timing with PyArg_ParseTuple.*
> Interestingly, in 3.6 PyArg_ParseTupleAndKeywords and PyArg_ParseTuple
> are the same speed (on this mac laptop anyway).
>
> %timeit Vector3(0)
> 100 loops, best of 3: 198 ns per loop
>
> %timeit Vector3(0, 0, 0)
> 100 loops, best of 3: 276 ns per loop
>
>
> Exactly the same timing as PyArg_ParseTupleAndKeywords pretty much.
>
>
> And now for something kind of funny...
>
> In [11]: from dis import dis
>
> In [12]: def a():
> ...: Vector3(0,0,0)
> ...:
>
> In [13]: def b():
> ...: v3.xyz
> ...:
>
> In [14]: dis(a)
>   2   0 LOAD_GLOBAL  0 (Vector3)
>   2 LOAD_CONST   1 (0)
>   4 LOAD_CONST   1 (0)
>   6 LOAD_CONST   1 (0)
>   8 CALL_FUNCTION3
>  10 POP_TOP
>  12 LOAD_CONST   0 (None)
>  14 RETURN_VALUE
>
> In [15]: dis(b)
>   2   0 LOAD_GLOBAL  0 (v3)
>   2 LOAD_ATTR1 (xyz)
>   4 POP_TOP
>   6 LOAD_CONST   0 (None)
>   8 RETURN_VALUE
>
> An ugly hack would be to
>   avoid those byte code ops,
>   and avoid PyArg_ParseTupleX in CA

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

[Daniel Pope]

> We want to go two left? This is sort of nice.
> >>> velocity + Vector3.left * 2

Christening a particular axis or Vector as "left" had all kinds of
problems. Which way is up? +y, like a graph? -y, like Surface coordinates?
Is it a left-handed or right-handed coordinate system?

On Tue, 27 Feb 2018, 21:56 Ian Mallett,  wrote:

> ​(Skims discussion)
>
> For e.g. `abs(Vector2(2,-1).elementwise())`, my (C++) library instead
> handles this as `abs(Vec2(2,-1))`, returning another `Vec2`. In C++, if you
> weren't expecting that, you get a compile error on whatever happens next,
> whereas in Python you'll get a `TypeError`, so it's well-defined.
>
> If you want the vector's length, I use a function, but perhaps it's more
> pythonic to use a method: `Vec2(2,-1).getLength()`, or
> `Vec2(2,-1).getLengthSq()`.
>
> If your vector represents a complex number and you're wondering why
> `abs(...)` shouldn't return a complex modulus, then I ask why you aren't
> using the built-in `complex`, which is designed for this.
>
> Ian
>

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

[Ian Mallett]

​(Skims discussion)

For e.g. `abs(Vector2(2,-1).elementwise())`, my (C++) library instead
handles this as `abs(Vec2(2,-1))`, returning another `Vec2`. In C++, if you
weren't expecting that, you get a compile error on whatever happens next,
whereas in Python you'll get a `TypeError`, so it's well-defined.

If you want the vector's length, I use a function, but perhaps it's more
pythonic to use a method: `Vec2(2,-1).getLength()`, or
`Vec2(2,-1).getLengthSq()`.

If your vector represents a complex number and you're wondering why
`abs(...)` shouldn't return a complex modulus, then I ask why you aren't
using the built-in `complex`, which is designed for this.

Ian

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

[René Dudfield]

Some static constructors could be useful.

up, down, left, right
forward, back
zero, one, two, ...

>>> velocity = Vector3(1, 2, 3)

We want to go two left? This is sort of nice.
>>> velocity + Vector3.left * 2


>>> Vector3.left


>>> Vector3.right


>>> Vector3.up


They are unit vectors (length 1) in a particular direction.

Plus a few other useful constants.
>>> Vector3.one


etc.



​If I remove PyArg_ParseTuple entirely...
%timeit Vector3()
1000 loops, best of 3: 104 ns per loop

(I guess it'd be around 84ns as a static attribute lookup which constructs
a new vector).

So these special constructors, as well as being readable would be faster.

It'd still be quicker to declare them as variables, and make them immutable.
vec3_left = Vector3(-1, 0, 0)
%timeit vec3_left
1000 loops, best of 3: 24 ns per loop


Note below, how the 'vec3_left' variable is lots quicker.

%timeit velocity + Vector3(-1, 0, 0) * 2
100 loops, best of 3: 451 ns per loop

%timeit velocity + vec3_left * 2
1000 loops, best of 3: 184 ns per loop

We make a pretend Vector3 with a left variable to see how quick it is.
In [27]: class Vector3:
...: pass
...:

In [28]: Vector3.left = vec3_left

%timeit Vector3.vector_left
1000 loops, best of 3: 44.1 ns per loop

In [29]: %timeit velocity + Vector3.left * 2
100 loops, best of 3: 214 ns per loop

So it seems making some immutable vectors would be useful for a 10.2x -
18.8x speedup.
Without immutable vectors, 5.3x speedup.



Plus, I think they'd be more readable, and perhaps instructive.

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

[René Dudfield]

Some good points. Thanks, I appreciate the discussion.


On Tue, Feb 27, 2018 at 3:51 PM, Daniel Pope  wrote:

> > Single scalar constructor should Vector2(1) == Vector2(1, 1)
>
> This is the kind of situation where I'd follow PEP20: "In the face of
> ambiguity, refuse the temptation to guess." There's an obvious pitfall if
> you expected to pass a tuple and you instead pass a scalar or the wrong
> length tuple - it silently succeeds but constructs the wrong Vector.
> Perhaps raise a TypeError?
>
>
At the moment Vector2/3 uses keyword arguments.
Vector2() -> Vector(0, 0)
​Vector2(x=0, y=0) -> Vector(0, 0)
Vector2(1) -> Vector(1, 0)

I'm beginning to think keyword arguments are wrong for this.
Would maybe prefer to raise a TypeError as you suggest,
  or follow GLSL behaviour and allow single scalar, error for the others.

These should raise an error for sure?
  Vector3(1, 1) # oops, I meant to type three 1s.
  Vector3(some2d_I_thought_was_a_3d) #oops, the incoming value is of a
different size.

However, I feel this single scalar is hard to make
a mistake with accidentally passing in the wrong thing?
  Vector(1)

Keyword arguments are also pretty useless for readability with Vector2/3.
Because you know it's a 3 element container.
  Vector3(x=0, y=0, z=0) VS
  Vector3(0,0,0)

It's fairly common to init vec2/vec3 in GLSL with a single number.
Eyeballing a few scripts, maybe 10% of usage is single scalar constructor.
And to be able to have fairly good compatibility with code from shadertoy
might be nice.





> Lower dimensional to higher dimension contructors should work:
> > Vector3(1, Vector2(2, 3)) == Vector3(1, 2, 3)
>
> We don't need this because we have star args:
>
> Vector3(1, *Vector2(2, 3))
>

Yeah, good point.

There is this error message for this case at least:
>>> Vector3(1, (1,2))
ValueError: Vector3 must be initialized with 3 real numbers or a
sequence of 3 real numbers

I don't think the "Lower dimensional to higher dimension constructors
should work" bit is that important.
It's not super common in GLSL code I've seen in the wild anyway.

And as you say, we have * notation for this.






*Some more benchmarking.*

Some timing on python 3.6 (with PyArg_ParseTupleAndKeywords which supports
keyword arguments).
Note v3.xyz is the fastest constructor. See below with just
PyArg_ParseTuple (no speed improvement).


v3 = Vector3(0)

%timeit v3.xyz
1000 loops, best of 3: *83.3 ns per loop*

%timeit Vector3()
1000 loops, best of 3: 131 ns per loop

%timeit Vector3(0)
100 loops, best of 3: 199 ns per loop

%timeit Vector3(0, 0, 0)
100 loops, best of 3: 269 ns per loop

%timeit Vector3(x=0, y=0, z=0)
100 loops, best of 3: 426 ns per loop

%timeit Rect((0, 0, 0, 0))
1000 loops, best of 3: 184 ns per loop

from numpy import array
%timeit array((0,0,0))
100 loops, best of 3: *919 ns* per loop

assert id(v3) != id(v3.xyz), ".xyz makes a copy"

%timeit (0,0,0)
1 loops, best of 3: *14.9 ns* per loop

somevec= (1, 2)

%timeit Vector3(1, *somevec)
100 loops, best of 3: 333 ns per loop

%timeit anothervec=v3.xyz;anothervec.xyz = (1, 2, 3)
100 loops, best of 3: 221 ns per loop





*Now timing with PyArg_ParseTuple.*
Interestingly, in 3.6 PyArg_ParseTupleAndKeywords and PyArg_ParseTuple
are the same speed (on this mac laptop anyway).

%timeit Vector3(0)
100 loops, best of 3: 198 ns per loop

%timeit Vector3(0, 0, 0)
100 loops, best of 3: 276 ns per loop


Exactly the same timing as PyArg_ParseTupleAndKeywords pretty much.


And now for something kind of funny...

In [11]: from dis import dis

In [12]: def a():
...: Vector3(0,0,0)
...:

In [13]: def b():
...: v3.xyz
...:

In [14]: dis(a)
  2   0 LOAD_GLOBAL  0 (Vector3)
  2 LOAD_CONST   1 (0)
  4 LOAD_CONST   1 (0)
  6 LOAD_CONST   1 (0)
  8 CALL_FUNCTION3
 10 POP_TOP
 12 LOAD_CONST   0 (None)
 14 RETURN_VALUE

In [15]: dis(b)
  2   0 LOAD_GLOBAL  0 (v3)
  2 LOAD_ATTR1 (xyz)
  4 POP_TOP
  6 LOAD_CONST   0 (None)
  8 RETURN_VALUE

An ugly hack would be to
  avoid those byte code ops,
  and avoid PyArg_ParseTupleX in CALL_FUNCTION...

And encode numbers in a swizzle-ish attribute.
  Vector3.xyz_1234234235__23423__333 -> Vector3(1234234235, 23423, 333)

Haha... pretty ridiculous. Not a good idea for readability.
But interesting how you can abuse the attribute getter.


It's sort of unfair that tuple construction gets a 18x faster constructor
over extension types in CPython.
But anyway. 3.4x to 11x faster construction than numpy arrays is nice.

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

[Daniel Pope]

> Single scalar constructor should Vector2(1) == Vector2(1, 1)

This is the kind of situation where I'd follow PEP20: "In the face of
ambiguity, refuse the temptation to guess." There's an obvious pitfall if
you expected to pass a tuple and you instead pass a scalar or the wrong
length tuple - it silently succeeds but constructs the wrong Vector.
Perhaps raise a TypeError?

> Lower dimensional to higher dimension contructors should work:
> Vector3(1, Vector2(2, 3)) == Vector3(1, 2, 3)

We don't need this because we have star args:

Vector3(1, *Vector2(2, 3))

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

[René Dudfield]

I've done a much larger review and testing.
Comparing it to different vector implementations,
and looking at how it inter-operates with pygame and OpenGL APIs.

TLDR; these things need to be fixed:
- scalar construction is buggy.
- One naming improvement I'd like help with is .elementwise() ? I think
it's too long.
- float('NaN') and float('inf') behaviour is not tested.
- Construction from Color, and Rect needs to be defined.

There's other useful functionality that could be added later I think.

I'll finish off the narrative documentation and example program,
and then await feedback before the Experimental notice is lifted.
This process has already uncovered a bunch of things that
are missing, so I expect more to pop up.

IMHO, it's already one of the best vector2/vector3 implementations in
python.
And I like that people will be able to use their knowledge of this API with
GLSL (a bit).



*A) GLSL shadling language vectors*

https://en.wikibooks.org/wiki/GLSL_Programming/Vector_and_Matrix_Operations#Components
https://www.khronos.org/registry/OpenGL/specs/gl/GLSLangSpec.4.60.pdf

Here's what I've found missing/different.

1) Single scalar constructor should
Vector2(1) == Vector2(1, 1)
   # currently it makes Vector2(1, 0)

2) Lower dimensional to higher dimension contructors should work:
Vector3(1, Vector2(2, 3)) == Vector3(1, 2, 3)

3) the GLSL documentation uses "component wise", whereas we use
elementwise()
  Additionally, I think elementwise() is quite long, and should probably be
a property.
  A shorter name here would be nice.


4) Missing functions:
abs
abs(Vector2(2,-1).elementwise()) works.
sign
floor
trunc
round
roundEven
ceil
fract
mod
modf
min
max
clamp
mix
step
smoothstep

faceForward are missing
... more


Section 8.3, Common Functions
https://www.khronos.org/registry/OpenGL/specs/gl/GLSLangSpec.4.30.pdf

The functions operate component wise.
Vector2(1, 3).min(Vector2(4, -2)) == Vector2(1, -2)

We have min() and max() in python, but unfortunately they use some weird
magic, and not a dunder magic method.

"Classes that act like numbers"
http://www.diveintopython3.net/special-method-names.html#acts-like-number
  __floor__
  __ceil__
  __trunc__

5) swizzling only there with xyzw

Seems like rgba, and stpq should be available.

{x, y, z, w} Useful when accessing vectors that represent points or normals
{r, g, b, a} Useful when accessing vectors that represent colors
{s, t, p, q} Useful when accessing vectors that represent texture
coordinates

Perhaps vec3.rgb would return a pygame.Color




*B) Compared to the CookBook 2d vector class...*
https://www.pygame.org/wiki/2DVectorClass


missing:
get_angle()
perpendicular
http://mathworld.wolfram.com/PerpendicularVector.html
perpendicular_normal
projection (not in here, but the inverse is the rejection)
https://en.wikipedia.org/wiki/Vector_projection



*C) Compred to box2d vec2*
https://github.com/pybox2d/pypybox2d/blob/master/pypybox2d/src/vec2module.c

missing:
contains() isn't there, but you can do:
  2 in v2
clamp
min
max



*D) pyeuclid*

rotate_around(axis, theta)
https://github.com/ezag/pyeuclid/blob/master/euclid.py#L565
copy()
Rect, and Surface have this in pygame too
Vector2(Vector2(1,2)) work however.



*E) planar*

https://pythonhosted.org/planar/vectorref.html
almost_equals

https://pythonhosted.org/planar/vectorref.html#planar.Vec2.almost_equals
Should be called isclose like python3.5+ math.isclose
https://docs.python.org/3/library/math.html#math.isclose
scaled_to
https://pythonhosted.org/planar/vectorref.html#planar.Vec2.scaled_to
perpendicular
clamped




*Extras*
Additional functionality not done is the buffer stuff. Which is commented
out in math.c
I guess the purpose is to allow a Vector2/3 to act with it's storage coming
in
an array. This would be super useful if you allocated a big array and wanted
to act on one element easily. Again, I think this could come later without
harming
backwards compatibility.

There is partial support in the code for a Vector4.
There's nothing done for 2x2, 3x3 or 4x4 matrix.
Which are all quite useful in games (and in GLSL).
These can all come later without harming backwards compatibility.


*Existing pygame APIs.*

There are some differences between Vector3 and Rect and Color types.

Vectors allow some niceties which people might come to expect from Rect and
Color.
v2[:] = (3,4)
v2.xy = (3,4)
Vector3(0) -> Vector3(0, 0, 0)

Also, Rect has methods like copy() which are missing in Vector3.

Passing a color into pygame gives a very strange result.
>>> Vector2(pygame.Color(2,3,4, 111))


I think Vector3(Color('red')) should work to give you Vector(1, 0, 0).
And Vector3(Color(255, 255, 255)) should give you Vector3(1, 1, 1).

Or maybe not. Maybe it should rais

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

[René Dudfield]

I won't move pygame.math.Vector2/3 into pygame or pygame.locals namespace
for now.
That's potentially breaking things which already have their own Vector2/3.
This type of API change will wait for pygame 2.

Narrative documentation is missing, and I'm working on that now.

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

[René Dudfield]

I fixed a bunch of compiler warnings, added a test for lerp(), and tweaked
the documentation.

Note that the pickle stuff isn't working under pypy.

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

[René Dudfield]

Oh yes. Thanks.

TLDR; those are fixed. Should pygame.Vector2 and Vector2 go in
pygame.locals by default?



a) I fixed it so it returns a Vector2, or Vector3 as is appropriate.
Something like v.xyxy (length==4) returns a tuple.
type(v.xy) == float
type(v.xy) == Vector2
type(v.xyz) == Vector3
type(v.xyzx) == tuple

b) v.x = 3 works again.
c) updated the docs, removed experimental notice.
d) swizzling is now faster than fetching single attributes. (v.xyz is
faster than (v.x, v.y, v.z)).

In [1]: import pygame.math
In [2]: v = pygame.math.Vector3(1,2,3)
In [3]: %timeit v.xyz
The slowest run took 230.33 times longer than the fastest. This could
mean that an intermediate result is being cached.
1000 loops, best of 3: *77.8 ns* per loop
In [4]: %timeit pygame.math.Vector3(v.x, v.y, v.z)
The slowest run took 25.69 times longer than the fastest. This could
mean that an intermediate result is being cached.
100 loops, best of 3: *465 ns* per loop

In [5]: %timeit v.xy
The slowest run took 25.73 times longer than the fastest. This could
mean that an intermediate result is being cached.
1000 loops, best of 3: 73.5 ns per loop
In [6]: %timeit (v.x, v.y)
The slowest run took 18.30 times longer than the fastest. This could
mean that an intermediate result is being cached.
1000 loops, best of 3: 135 ns per loop
In [7]: %timeit pygame.math.Vector2(v.x, v.y)
The slowest run took 31.03 times longer than the fastest. This could
mean that an intermediate result is being cached.
100 loops, best of 3: 353 ns per loop
In [8]: Vector2 = pygame.math.Vector2
In [9]: %timeit Vector2(v.x, v.y)
The slowest run took 13.55 times longer than the fastest. This could
mean that an intermediate result is being cached.
100 loops, best of 3: 310 ns per loop

This was because before it was handling swizzle attribute access by waiting
for an error.

Now, (x,y,z) attribute access is just as fast, and swizzles are a lot
faster.
However other methods are about 10ns slower (on this machine).

In [10]: pygame.math.disable_swizzling()
In [11]: %timeit v.is_normalized()
The slowest run took 28.18 times longer than the fastest. This could
mean that an intermediate result is being cached.
1000 loops, best of 3: 83.3 ns per loop
In [12]: pygame.math.enable_swizzling()
In [13]: %timeit v.is_normalized()
The slowest run took 28.89 times longer than the fastest. This could
mean that an intermediate result is being cached.
1000 loops, best of 3: 94.1 ns per loop


Another downside of Vectors at the moment is that they allocate more slowly
than tuples.
Because python tuples and lists are optimized over normal objects, and use
a memory pool.
However, it's close to list if you use the list() constructor, and 2x
faster than a python object.

In [1]: import pygame.math
In [2]: v=pygame.math.Vector2(1,2)
In [3]: Vector2 = pygame.math.Vector2
In [4]: %timeit Vector2(1.0,2.0)
The slowest run took 11.90 times longer than the fastest. This could
mean that an intermediate result is being cached.
1000 loops, best of 3: 197 ns per loop
In [5]: %timeit (1.0,2.0)
1 loops, best of 3: 14.5 ns per loop
In [6]: %timeit list((1,2))
The slowest run took 5.76 times longer than the fastest. This could
mean that an intermediate result is being cached.
100 loops, best of 3: 205 ns per loop
In [7]: class V(object):
   ...: def __init__(self, x, y):
   ...: self.x = x
   ...: self.y = y
   ...:
In [8]: %timeit V(1,2)
The slowest run took 5.96 times longer than the fastest. This could
mean that an intermediate result is being cached.
100 loops, best of 3: 422 ns per loop


https://github.com/pygame/pygame/pull/403





What about?
1) Putting them in pygame.Vector2, pygame.Vector3 and in pygame.locals?
pygame.math imported by default.

Some other topics/issues... (perhaps all for later?)

- types in python are spelt with a lower case these days (post python 1.5.2
*ahem*).
- We should probably call them vec2, vec3 as per GLSL (and as per python
naming of types).
- We are missing other swizzle attribute names from GLSL, like rgba.
- There is some support in the code for Vector4... but a number of the
methods would need to be written first.
- Now that vectors have this nice slicing/swizzling support... what about
colors and rects?
- Should all types be consistently lower case? color, rect? 'rect' is used
a lot in code... to mean an instance Maybe not.
- there's some commented out code for buffer handling. Useful when you want
a vector to act on a bigger list of data.
- allocation of new vectors could be improved perhaps to approach tuple
speed?




On Sun, Feb 25, 2018 at 12:05 PM, Daniel Pope  wrote:

> Indeed, getting the attribute returns a float so the attribute should be
> settable as a float for consistency.
>
> If users are 

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

[Daniel Pope]

Indeed, getting the attribute returns a float so the attribute should be
settable as a float for consistency.

If users are familiar with GLSL[1], they might be surprised that the type
of vectors returned by swizzle attribute access is not a vector:

>>> from pygame.math import Vector3, enable_swizzling
>>> enable_swizzling()
>>> Vector3()

>>> v = Vector3(1, 2, 3)

>>> v.xy
(1.0, 2.0)
>>> type(v.xy)


[1]
https://en.wikibooks.org/wiki/GLSL_Programming/Vector_and_Matrix_Operations#Components


On Sun, 25 Feb 2018 at 09:38 René Dudfield  wrote:

> Hi,
>
> that's a good point.
>
> TLDR; I think it should be on by default too. There's still a couple of
> issues with doing that.
>
>
> It should have _no_ cost in almost all cases for attribute access. Because
> it first tries normal attribute access.
> See: https://github.com/pygame/pygame/blob/master/src/math.c#L1517
>
> I guess the reason is it's off by default is because it was implemented
> later on, and to leave it on in a buggy state caused issues.
>
> Not a big concern, but turning it on by default will perhaps have annoying
> compatibility issues for people using an old pygame.
> If they forget to turn it on.
>
> There's two test failures once I changed to be enabled by default:
>
> >>> import pygame.math
> >>> v = pygame.math.Vector2(1,2)
> >>> v.x = 3
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: a sequence is expected
> >>> pygame.math.disable_swizzling()
> >>> v.x = 3
> >>> v
> 
>
> These are to do with assignment to a variable.
> https://github.com/pygame/pygame/pull/403
>
>
>
>
> On Sat, Feb 24, 2018 at 7:23 PM, Daniel Pope  wrote:
>
>> Does the Swizzling have a cost if you're not using it? If not I'd be
>> tempted to say it should always be on.
>>
>>
>> On Sat, 24 Feb 2018, 18:00 René Dudfield,  wrote:
>>
>>> Hey hey,
>>>
>>> I noticed the pygame.math vectors couldn't be pickled/unpickled.
>>>
>>> So that has been added here:
>>> https://github.com/pygame/pygame/pull/403
>>>
>>> Could someone please review?
>>>
>>>
>>> cheers,
>>>
>>>
>>>
>>> On Sat, Feb 24, 2018 at 10:30 AM, René Dudfield 
>>> wrote:
>>>
 Hello,

 I'm going to remove the experimental notice from pygame.math in the
 docs.
 https://www.pygame.org/docs/ref/math.html

 It seems fine to me, and I guess no one has plans to change it?


 best regards,

>>>
>>>
>

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

[René Dudfield]

Hi,

that's a good point.

TLDR; I think it should be on by default too. There's still a couple of
issues with doing that.


It should have _no_ cost in almost all cases for attribute access. Because
it first tries normal attribute access.
See: https://github.com/pygame/pygame/blob/master/src/math.c#L1517

I guess the reason is it's off by default is because it was implemented
later on, and to leave it on in a buggy state caused issues.

Not a big concern, but turning it on by default will perhaps have annoying
compatibility issues for people using an old pygame.
If they forget to turn it on.

There's two test failures once I changed to be enabled by default:

>>> import pygame.math
>>> v = pygame.math.Vector2(1,2)
>>> v.x = 3
Traceback (most recent call last):
  File "", line 1, in 
TypeError: a sequence is expected
>>> pygame.math.disable_swizzling()
>>> v.x = 3
>>> v


These are to do with assignment to a variable.
https://github.com/pygame/pygame/pull/403




On Sat, Feb 24, 2018 at 7:23 PM, Daniel Pope  wrote:

> Does the Swizzling have a cost if you're not using it? If not I'd be
> tempted to say it should always be on.
>
>
> On Sat, 24 Feb 2018, 18:00 René Dudfield,  wrote:
>
>> Hey hey,
>>
>> I noticed the pygame.math vectors couldn't be pickled/unpickled.
>>
>> So that has been added here:
>> https://github.com/pygame/pygame/pull/403
>>
>> Could someone please review?
>>
>>
>> cheers,
>>
>>
>>
>> On Sat, Feb 24, 2018 at 10:30 AM, René Dudfield  wrote:
>>
>>> Hello,
>>>
>>> I'm going to remove the experimental notice from pygame.math in the docs.
>>> https://www.pygame.org/docs/ref/math.html
>>>
>>> It seems fine to me, and I guess no one has plans to change it?
>>>
>>>
>>> best regards,
>>>
>>
>>

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

[Daniel Pope]

Does the Swizzling have a cost if you're not using it? If not I'd be
tempted to say it should always be on.

On Sat, 24 Feb 2018, 18:00 René Dudfield,  wrote:

> Hey hey,
>
> I noticed the pygame.math vectors couldn't be pickled/unpickled.
>
> So that has been added here:
> https://github.com/pygame/pygame/pull/403
>
> Could someone please review?
>
>
> cheers,
>
>
>
> On Sat, Feb 24, 2018 at 10:30 AM, René Dudfield  wrote:
>
>> Hello,
>>
>> I'm going to remove the experimental notice from pygame.math in the docs.
>> https://www.pygame.org/docs/ref/math.html
>>
>> It seems fine to me, and I guess no one has plans to change it?
>>
>>
>> best regards,
>>
>
>

Re: [pygame] Re: pygame 1.9.4 release coming up

[DiliupG]

2018 The Year of Python


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On 14 February 2018 at 18:42, René Dudfield  wrote:

> Thanks for the info.
>
> Yeah, I think some of them could be short work.
>
> The event issues are probably the more important to get the core stuff
> going.
>
> The ctypes.pythonapi is unfortunate... since that is what our tests use
> for a lot of the array tests. There's a few BufferProxy errors too. I'm not
> really surprised... that part of the Python C API(s) is really tricky (and
> changed several times over releases). Would need some chats with pypy
> experts to see what the best approach would be. It's possible we could
> compile stuff just for pypy to be used in the tests... or perhaps there is
> another way to get at the objects. https://github.com/pygame/pyga
> me/blob/master/test/test_utils/arrinter.py
>
>
> ps. (Unfortunately, it looks like all the history on that file is lost for
> some reason in our git repo. Damn. Here is the bitbucket link with
> history... https://bitbucket.org/pygame/pygame/history-node/48e19c7b9ee
> 9/test/test_utils/arrinter.py?at=default )
>
>


-- 
Kalasuri Diliup Gabadamudalige

https://dahamgatalu.wordpress.com/
http://soft.diliupg.com/
http://www.diliupg.com

**
This e-mail is confidential. It may also be legally privileged. If you are
not the intended recipient or have received it in error, please delete it
and all copies from your system and notify the sender immediately by return
e-mail. Any unauthorized reading, reproducing, printing or further
dissemination of this e-mail or its contents is strictly prohibited and may
be unlawful. Internet communications cannot be guaranteed to be timely,
secure, error or virus-free. The sender does not accept liability for any
errors or omissions.
**

Re: [pygame] Re: pygame 1.9.4 release coming up

[René Dudfield]

Thanks for the info.

Yeah, I think some of them could be short work.

The event issues are probably the more important to get the core stuff
going.

The ctypes.pythonapi is unfortunate... since that is what our tests use for
a lot of the array tests. There's a few BufferProxy errors too. I'm not
really surprised... that part of the Python C API(s) is really tricky (and
changed several times over releases). Would need some chats with pypy
experts to see what the best approach would be. It's possible we could
compile stuff just for pypy to be used in the tests... or perhaps there is
another way to get at the objects. https://github.com/pygame/pyga
me/blob/master/test/test_utils/arrinter.py


ps. (Unfortunately, it looks like all the history on that file is lost for
some reason in our git repo. Damn. Here is the bitbucket link with
history... https://bitbucket.org/pygame/pygame/history-node/
48e19c7b9ee9/test/test_utils/arrinter.py?at=default )

Re: [pygame] Re: pygame 1.9.4 release coming up

[Stuart Axon]

Great :)

I've had a look at this list of fails before, can't remember here is what I
found (IIRC) -


ctypes.pythonapi
-   pypy devs said this will never be supported in pypy

The others look like they might be pypy bugs, but it obviously need a
little investigation to find out what they are doing that is common.

There are a lot of


TypeError: decoding Unicode is not supported


So this might all be the same bug (I guess pypy is returning unicode
somewhere, where it should not - and pygame then tries to decode it).

A lot of the other errors seem to go into broad classes of error, that
could be broken down, but those are the biggest two.

On 12 February 2018 at 13:05, René Dudfield  wrote:

> Here's the PR enabling pypy on travis so that it is allowed to fail:
>   https://github.com/pygame/pygame/pull/392
>
> And you can see the commit is considered passing, even though there are
> quite a few Fails and Errors in the pypy build.
>   https://travis-ci.org/pygame/pygame/builds/340463723
>
>

Re: [pygame] Re: pygame 1.9.4 release coming up

[Stuart Axon]

Hi René
  I noticed you wrapping up pypy related fixes the other day, will this
release work out of the box, or are there still some failing tests.
Either way, it might be worth mentioning the pypy status in the README.

Cheers
Stuart


On 11 February 2018 at 08:56, René Dudfield  wrote:

> Found the bug reports. Thanks, they're very detailed.
> https://bitbucket.org/pygame/pygame/issues/340/surfaceconver
> t-does-not-remove-the
> https://bitbucket.org/pygame/pygame/issues/341/surfaceset_al
> pha-sets-the-srcalpha-flag
>
>
>
> On Saturday, February 10, 2018, René Dudfield  wrote:
>
>> I'll have a look tomorrow morning. If the issues have a test case in
>> there so the problem can be reproduced, it's much easier to fix. Even
>> better if they are in the unit test format (see pygame repo test/ folder on
>> github)
>>
>>
>>
>> On Saturday, February 10, 2018, MrGumm  wrote:
>>
>>> Please please fix my alpha bug? Which I filed in Nov, I think. :)
>>>
>>> On 2/10/2018 11:37 AM, DiliupG wrote:
>>>
>>> This is great news indeed! :) :) :)
>>> I hope we have tons of new goodies to mess around with...
>>>
>>>
>>> 
>>>  Virus-free.
>>> www.avast.com
>>> 
>>>
>>> On 10 February 2018 at 06:12, René Dudfield  wrote:
>>>
 Hey ya,

 about time for another release I guess?

 Here is the issue to track:
   https://github.com/pygame/pygame/issues/390

 As per docs/howto_release_pygame.txt I'm letting all interested people
 know there is a release coming 'soon'.

 Or not? Is there something horribly broken that wasn't broken in the
 last release? Or something you're almost done with?

 The reason to do a release is that:
 - there are a bunch of fixes in pygame.
 - I'd rather get that stuff released before I start merging in the sdl2
 stuff (which is turned off by default still).


 Here's the checklist as of now.
 - [x] go through the issue tracker, and pull requests to include as
 much as we can.
 - [ ] announce intention to release on mailing list.
 - [ ] prepare the release notes (aka, WHATSNEW).
 - [ ] manual testing on linux
 - [ ] manual testing on mac
 - [ ] manual testing on windows
 - [ ] run a few old games I know to see if things work.
 - [ ] upload wheels to test pypi https://packaging.python.org/g
 uides/using-testpypi/
 - [ ] ask for people to test from test.pypi.org

 I'm updating the release notes now, and then will start figuring out
 how to load wheels onto test pypi.

 Any feedback on this plan, or help appreciated.

 Here's the issue to discuss 1.9.4 release things:
 https://github.com/pygame/pygame/issues/390



 cheers,


>>>
>>>
>>> --
>>> Kalasuri Diliup Gabadamudalige
>>>
>>> https://dahamgatalu.wordpress.com/
>>> http://soft.diliupg.com/
>>> http://www.diliupg.com
>>>
>>> 
>>> **
>>> This e-mail is confidential. It may also be legally privileged. If you
>>> are not the intended recipient or have received it in error, please delete
>>> it and all copies from your system and notify the sender immediately by
>>> return e-mail. Any unauthorized reading, reproducing, printing or further
>>> dissemination of this e-mail or its contents is strictly prohibited and may
>>> be unlawful. Internet communications cannot be guaranteed to be timely,
>>> secure, error or virus-free. The sender does not accept liability for any
>>> errors or omissions.
>>> 
>>> **
>>>
>>>
>>>

Re: [pygame] Re: How much blit costs?

[Radomir Dopieralski]

On Thu, 15 Jun 2017 11:09:21 -0700 (MST)
babaliaris  wrote:

> bw thanks for your answer. The problem is that in the future sprite
> objects would be able to have a Brain object which the programmer can
> attach in order to give functionalities to a sprite object. Because
> my engine does not know which sprites have brains, I must go through
> all of them and run any possible brain scripts every frame.

Well, that is trivial to solve. Just keep a separate list of sprites
that have brains. Also, you only need to call the brain code on them,
and not blit them.

-- 
Radomir Dopieralski

-- 
Radomir Dopieralski

Re: [pygame] Re: Pygame doesn't close properly so I can't delete the file it's using

[Luke Paireepinart]

The wait for it calls can all be done in a loop, is there a reason for
having them all listed out?

On May 28, 2017 4:01 PM, "Gameskiller01"  wrote:

Thank you very much! Using the code:

with open(my_file) as f:
m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)

pygame.mixer.music.load(m)
pygame.mixer.music.play()

m.close()

The code now finally works! I haven't been this happy for a long time!

Full code:

import os
import time
import sys
import getpass
import pip
import mmap
import imp
from contextlib import contextmanager


my_file = "Text To Speech.mp3"
username = getpass.getuser()


@contextmanager
def suppress_output():

with open(os.devnull, "w") as devnull:
old_stdout = sys.stdout
sys.stdout = devnull
try:
yield
finally:
sys.stdout = old_stdout


def check_and_remove_file():

active = pygame.mixer.get_init()
if active != None:
pygame.mixer.music.stop()
pygame.mixer.quit()
pygame.quit()
if os.path.isfile(my_file):
os.remove(my_file)


def wait_for_it(audio_length, greater_than, less_than, time_to_wait):

if (audio_length) >= (greater_than) and (audio_length) < (less_than):
time.sleep((audio_length) + (time_to_wait))


def exiting():

check_and_remove_file()
print("\nGoodbye!")
sys.exit()


def input_for_tts(message):

try:

tts = gTTS(text = input(message))
tts.save('Text To Speech.mp3')

with open(my_file) as f:
m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
audio = MP3(my_file)
audio_length = audio.info.length
try:
pygame.mixer.init()
except pygame.error:
print("\nSorry, no audio device was detected. The code cannot
complete.")
exiting()
pygame.mixer.music.load(m)
pygame.mixer.music.play()
wait_for_it(audio_length, 0, 15, 1)
wait_for_it(audio_length, 15, 30, 2)
wait_for_it(audio_length, 30, 45, 3)
wait_for_it(audio_length, 45, 60, 4)
wait_for_it(audio_length, 60, 75, 5)
wait_for_it(audio_length, 75, 90, 6)
wait_for_it(audio_length, 90, 105, 7)
wait_for_it(audio_length, 105, 120, 8)
wait_for_it(audio_length, 120, 135, 9)
wait_for_it(audio_length, 135, 150, 10)
wait_for_it(audio_length, 150, 165, 11)
wait_for_it(audio_length, 165, 180, 12)
if audio_length >= 180:
time.sleep((audio_length) + 15)
try:
m.close()
check_and_remove_file()
except PermissionError:
imp.reload(pygame)
check_and_remove_file()

except KeyboardInterrupt:

exiting()


with suppress_output():

pkgs = ['mutagen', 'gTTS', 'pygame']
for package in pkgs:
if package not in pip.get_installed_distributions():
pip.main(['install', package])


import pygame
from pygame.locals import *
from gtts import gTTS
from mutagen.mp3 import MP3


check_and_remove_file()


input_for_tts("Hello there " + username + ". This program is\nused to output
the user's input as speech.\nPlease input something for the program to say:
")


while True:

try:

answer = input("\nDo you want to repeat? ").strip().lower()
if answer in ["n", "no", "nah", "nay", "course not", "don't",
"dont", "not"] or "no" in answer or "nah" in answer or "nay" in answer or
"course not" in answer or "don't" in answer or "dont" in answer or "not" in
answer:
exiting()
elif answer in ["y", "yes", "yeah", "course", "ye", "yea", "yh",
"do"] or "yes" in answer or "yeah" in answer or "course" in answer or "ye"
in answer or "yea" in answer or "yh" in answer or "do" in answer:
input_for_tts("\nPlease input something for the program to say:
")
else:
print("\nSorry, I didn't understand that. Please try again with
yes or no.")

except KeyboardInterrupt:

exiting()



--
View this message in context: http://pygame-users.25799.x6.
nabble.com/Pygame-doesn-t-close-properly-so-I-can-t-
delete-the-file-it-s-using-tp3044p3062.html
Sent from the pygame-users mailing list archive at Nabble.com.

Re: [pygame] Re: Pygame doesn't close properly so I can't delete the file it's using

[Games Killer01]

[3]
https://stackoverflow.com/questions/44227094/python-module-to-play-mp3-file

On Sun, May 28, 2017 at 8:25 PM, Martin Kühne  wrote:

> Looks like stackoverflow is slowly choking on OP.
>
> cheers!
> mar77i
>
> [0] https://stackoverflow.com/questions/44221985/
> attributeerror-imageext-when-trying-to-reload-module-pygame
> [1] https://stackoverflow.com/questions/44218304/pygame-
> doesnt-close-an-mp3-file-the-second-time-it-uses-it?rq=1
> [2] https://stackoverflow.com/questions/44219509/pygame-
> doesnt-close-properly-so-i-cant-delete-the-file-its-using?rq=1
>

Re: [pygame] Re: Pygame doesn't close properly so I can't delete the file it's using

[Games Killer01]

[4]
https://stackoverflow.com/questions/44227094/python-module-to-play-mp3-file

On Sun, May 28, 2017 at 8:25 PM, Martin Kühne  wrote:

> Looks like stackoverflow is slowly choking on OP.
>
> cheers!
> mar77i
>
> [0] https://stackoverflow.com/questions/44221985/
> attributeerror-imageext-when-trying-to-reload-module-pygame
> [1] https://stackoverflow.com/questions/44218304/pygame-
> doesnt-close-an-mp3-file-the-second-time-it-uses-it?rq=1
> [2] https://stackoverflow.com/questions/44219509/pygame-
> doesnt-close-properly-so-i-cant-delete-the-file-its-using?rq=1
>

Re: [pygame] Re: Pygame doesn't close properly so I can't delete the file it's using

[Martin Kühne]

Looks like stackoverflow is slowly choking on OP.

cheers!
mar77i

[0] 
https://stackoverflow.com/questions/44221985/attributeerror-imageext-when-trying-to-reload-module-pygame
[1] 
https://stackoverflow.com/questions/44218304/pygame-doesnt-close-an-mp3-file-the-second-time-it-uses-it?rq=1
[2] 
https://stackoverflow.com/questions/44219509/pygame-doesnt-close-properly-so-i-cant-delete-the-file-its-using?rq=1

Re: [pygame] Re: Pygame doesn't close properly so I can't delete the file it's using

[DR0ID]

On 28.05.2017 20:21, Gameskiller01 wrote:

Sorry, I posted the wrong code. That code is from when i was trying to use
Pyglet instead of Pygame to open the file and see if that would work This is
the actual code.

import os
import time
import sys
import getpass
import pip
import imp
from contextlib import contextmanager


my_file = "Text To Speech.mp3"
username = getpass.getuser()


@contextmanager
def suppress_output():

 with open(os.devnull, "w") as devnull:
 old_stdout = sys.stdout
 sys.stdout = devnull
 try:
 yield
 finally:
 sys.stdout = old_stdout


def check_and_remove_file():

 active = pygame.mixer.get_init()
 if active != None:
 pygame.mixer.music.stop()
 pygame.mixer.quit()
 pygame.quit()
 if os.path.isfile(my_file):
 os.remove(my_file)


def wait_for_it(audio_length, greater_than, less_than, time_to_wait):

 if (audio_length) >= (greater_than) and (audio_length) < (less_than):
 time.sleep((audio_length) + (time_to_wait))


def exiting():

 check_and_remove_file()
 print("\nGoodbye!")
 sys.exit()


def input_for_tts(message):

 try:

 tts = gTTS(text = input(message))
 tts.save('Text To Speech.mp3')
 audio = MP3(my_file)
 audio_length = audio.info.length
 try:
 pygame.mixer.init()
 except pygame.error:
 print("\nSorry, no audio device was detected. The code cannot
complete.")
 exiting()
 pygame.mixer.music.load(my_file)
 pygame.mixer.music.play()
 wait_for_it(audio_length, 0, 15, 1)
 wait_for_it(audio_length, 15, 30, 2)
 wait_for_it(audio_length, 30, 45, 3)
 wait_for_it(audio_length, 45, 60, 4)
 wait_for_it(audio_length, 60, 75, 5)
 wait_for_it(audio_length, 75, 90, 6)
 wait_for_it(audio_length, 90, 105, 7)
 wait_for_it(audio_length, 105, 120, 8)
 wait_for_it(audio_length, 120, 135, 9)
 wait_for_it(audio_length, 135, 150, 10)
 wait_for_it(audio_length, 150, 165, 11)
 wait_for_it(audio_length, 165, 180, 12)
 if audio_length >= 180:
 time.sleep((audio_length) + 15)
 try:
 check_and_remove_file()
 except PermissionError:
 imp.reload(pygame)
 check_and_remove_file()

 except KeyboardInterrupt:

 exiting()


with suppress_output():

 pkgs = ['mutagen', 'gTTS', 'pygame']
 for package in pkgs:
 if package not in pip.get_installed_distributions():
 pip.main(['install', package])


import pygame
from pygame.locals import *
from gtts import gTTS
from mutagen.mp3 import MP3


check_and_remove_file()


input_for_tts("Hello there " + username + ". This program is\nused to output
the user's input as speech.\nPlease input something for the program to say:
")


while True:

 try:

 answer = input("\nDo you want to repeat? ").strip().lower()
 if answer in ["n", "no", "nah", "nay", "course not", "don't",
"dont", "not"] or "no" in answer or "nah" in answer or "nay" in answer or
"course not" in answer or "don't" in answer or "dont" in answer or "not" in
answer:
 exiting()
 elif answer in ["y", "yes", "yeah", "course", "ye", "yea", "yh",
"do"] or "yes" in answer or "yeah" in answer or "course" in answer or "ye"
in answer or "yea" in answer or "yh" in answer or "do" in answer:
 input_for_tts("\nPlease input something for the program to say:
")
 else:
 print("\nSorry, I didn't understand that. Please try again with
yes or no.")

 except KeyboardInterrupt:

 exiting()



--
View this message in context: 
http://pygame-users.25799.x6.nabble.com/Pygame-doesn-t-close-properly-so-I-can-t-delete-the-file-it-s-using-tp3044p3057.html
Sent from the pygame-users mailing list archive at Nabble.com.


Hi again

ok... errors happen.

I wonder one thing: can't it be played as a sound? (actually not sure 
how this would help your problem)



The other idea I head is: load the file to memory and close it properly 
after reading it and let pygame read the in memory file (probably as a 
file like object). I'm not sure how easy it would be to do (not sure 
where the limitation are).


~DR0ID

Re: [pygame] Re: Pygame doesn't close properly so I can't delete the file it's using

[DR0ID]

On 28.05.2017 17:57, Gameskiller01 wrote:

def input_for_tts(message):

 try:

 tts = gTTS(text = input(message))
 tts.save('Text To Speech.mp3')
 audio = MP3(my_file)
 audio_length = audio.info.length
 try:
 pygame.mixer.init()
 except pygame.error:
 print("\nSorry, no audio device was detected. The code cannot
complete.")
 exiting()
 bp = pyglet.resource.media(my_file)
 bp.play()



Hi there

Isn't that code playing the file using pyglet?

bp = pyglet.resource.media(my_file)
bp.play()

I wonder, why and what are you using pyglet for?

I don't think that pyglet is using pygame as a audio backend... but I 
might be wrong, but pyglet might lock the file (or whatever backend 
pyglet is using for audio).


Maybe try to remove pyglet (since its only used to play the file?) and 
see how it goes.


Or I may ask the other way around: why and what are you using pygame for?

If the reason you are using pyglet is because it can play mp3 and pygame 
can't, then why bother with pygame at all?



Maybe one of my question will help you figure the problem out.


~DR0ID

Re: [pygame] Re: Pygame doesn't close properly so I can't delete the file it's using

[Martin Kühne]

Please regard distinct issues as distinct.

Yes, opened.close() is the right thing to do as far as opening and
closing files goes.

I think the del pygame.imageext exception is an accident, since
actually, pygame should catch AtrributeError there.

As for the PermissionError; are you sure you didn't have the file open
in another program?
Focus on that part, since the rest is happening accidentally.

cheers!
mar77i

Re: [pygame] Re: Pygame doesn't close properly so I can't delete the file it's using

[Jake b]

That's because my_file is a string, not a file handle.

my_file = "Text To Speech.mp3"



When using with open, the file is closed when the context handler ends


This might be of help:
https://jeffknupp.com/blog/2016/03/07/python-with-context-managers/

Note: In the email, your code did not get posted. I think it has something
to do with nabble. When I clicked on that, then, I do see a couple
different versions.

Re: [pygame] Re: Pygame doesn't close properly so I can't delete the file it's using

[Luke Paireepinart]

Do you have an outer python program with some control loop and inside that
loop you are initializing pygame, generating the mp3, quitting pygame and
then deleting the file in the same program? If so, I don't think that's how
pygame is meant to be used. Why don't you initialize it once and not quit
until the program is terminated? You might need to also purge the event
queue of pygame too. I agree though, need to see code.

On May 28, 2017 8:55 AM, "Noel Garwick"  wrote:

> Could you post the source somewhere?
>
> I think another reason those files are staying locked could be if you
> aren't calling filename.close()
>
> On May 28, 2017 4:19 AM, "Gameskiller01"  wrote:
>
>> It already does.
>>
>>
>>
>> --
>> View this message in context: http://pygame-users.25799.x6.n
>> abble.com/Pygame-doesn-t-close-properly-so-I-can-t-delete-
>> the-file-it-s-using-tp3044p3046.html
>> Sent from the pygame-users mailing list archive at Nabble.com.
>>
>

Re: [pygame] Re: Pygame doesn't close properly so I can't delete the file it's using

[Noel Garwick]

Could you post the source somewhere?

I think another reason those files are staying locked could be if you
aren't calling filename.close()

On May 28, 2017 4:19 AM, "Gameskiller01"  wrote:

> It already does.
>
>
>
> --
> View this message in context: http://pygame-users.25799.x6.
> nabble.com/Pygame-doesn-t-close-properly-so-I-can-t-
> delete-the-file-it-s-using-tp3044p3046.html
> Sent from the pygame-users mailing list archive at Nabble.com.
>

Re: [pygame] Re: Blit method bug?

[Martin Kühne]

On Thu, May 25, 2017 at 6:54 PM, babaliaris  wrote:
> Thank's both of you! I didn't know that pygame uses 16 bits integers (I
> thought it was 32 bits every integer i put in the blit coordinates).
>

How comes you'd think such a thing? Python itself already ships
variable sized integers and keeps track of their size...

> I already thought to blit only images which the rectangle of it is at least
> inside the screen resolution.
> (Excuse me for my english).
>

Read my email again. I think I covered that already [0].

cheers!
mar77i

[0] https://www.pygame.org/docs/ref/rect.html#pygame.Rect.colliderect

Re: [pygame] Re: pygame with SDL2 proposal

[René Dudfield]

Lenard has gone ahead and patched everything with SDL2 defines where
needed, and set the config up with an -SDL2 flag. A lot of it works already
with SDL2.

Some thoughts on a test plan.

I've been setting up some linux machines for testing and development today.
An old Dell laptop(with Ubuntu 16.04), some raspberry pis(Raspbian), and
some virtual machines(Fedora, ...). I'll go through a 'smoke test' a bunch
of different apps and pygame examples next. It's looking pretty good so far.



1) known outstanding issues list.
2) functions with ifdef SDL2 list.
3) manual run through of apps on linux
4) review, and document each SDL2 touched file, one by one.
5) Mac, windows builds.

*1) known outstanding issues list.*
If we make the warnings in the code readable, we can mark it with this.
grep "#warning" src/*

#warning "convert_alpha not implemented."



*2) functions with ifdef SDL2 list.*Make a list of functions different in
SDL2. (Ones which have #ifndef SDL2), this will help us manually test
things. Because I guess these places are more likely to have issues.

There's approximately 22 files with SDL2 in there.



*3) manual run through of apps on linux*
Take pygame.example apps, and a few different apps we know well (solarwolf,
zanthor, an OpenGL one etc).
Make three virtualenvs with pygame 1.9.3, pygame+SDL1, pygame+SDL2.
Display apps side by side, try inputs, try music/sound.

*4) review, and document each SDL2 touched file, one by one.*

For each file or module, we can make a post to the mailing list, and
describe what it does.

The purpose of doing this is to get more eyes looking at it. Also it will
be a chance for us to document it well, and see if our explanations are
understandable.



To: "pygame-users@seul.org" 
Subject: display.c

* A link to the file in github.
* What the module does.
* What the SDL2 changes are.
* How we can test for compatible behaviour.
* A link to relevant SDL2 documentation.
* Refactor C API as we go. (gm prefix, SDL_Rect, mod init)
https://github.com/pygame/pygame/issues/333
* Thoughts on possible clean ups, or things we can make more clear.
* if easy enough, add missing unit tests (we have to test these anyway
right?).

This could be useful for C API documentation.


(I'm going to do display.c first.).




*5) Mac, Windows builds*
When the linux build seems to build ok, we need to get the OSX and windows
builds going.



So... that's the slightly vague test plan. Hopefully by the end of it we
will have a nicer developer guide, cleaner code, along with the SDL2 stuff.



If anyone wants to play on linux...
# sudo apt-get install libsdl2-image-dev libsdl2-dev libsdl2-ttf-dev
libsdl2-mixer-dev python3.5-venv git libfreetype6-dev libportmidi-dev
python3-wheel python3-setuptools python3-dev python3-numpy
git clone g...@github.com:pygame/pygame.git

cd pygame
git checkout -b SDL_patches --track origin/SDL2_patches
python3 config.py -SDL2
python3 setup.py build
python3 setup.py install --user
python3 -m pygame.examples.aliens

Re: [pygame] Re: pygame with SDL2 proposal

[Lenard Lindstrom]

I would add that I have some proof-of-concept code for SDL 2 window and 
renderer support at https://github.com/llindstrom/pygame_SDL2. It 
includes an experimental Cython window module with Window classes added 
to display. See examples/window_render.py for example Python code. It 
can be built on Gnu/Linux if the SDL 2.0.4 (or 2.0.5) library and dev 
files are installed. Tested for Python 2.7.


Lenard Lindstrom

On 17-04-09 01:47 AM, René Dudfield wrote:

(In case there's anyone interested on the list who wants to follow along).

Lenard has been adding the SDL2 patches in these branches.

https://github.com/pygame/pygame/tree/SDL2_patches 


https://github.com/pygame/pygame/tree/SDL2_patches_incomplete

Re: [pygame] Re: pygame with SDL2 proposal

[René Dudfield]

(In case there's anyone interested on the list who wants to follow along).

Lenard has been adding the SDL2 patches in these branches.

https://github.com/pygame/pygame/tree/SDL2_patches
https://github.com/pygame/pygame/tree/SDL2_patches_incomplete

Re: [pygame] Re: pygame with SDL2 proposal

[Lenard Lindstrom]

Hi Ian,

I think people are hung up on option 2), SDL1/SDL2 compile option, 
thinking it means no SDL2 features, or no option 3), transition to SDL2 
only. First, I gather René's proposal to keep Pygame development on a 
single branch is not about freezing the Pygame at SDL1 only 
functionality. Rather it is about logistics: How do we continue to 
distribute Pygame while updating the automated building systems for 
SDL2? How do we avoid breaking every Pygame program that has been 
written up to now?


I won't argue whether be kept as one branch or split into two. But I 
don't think creating an SDL1/SDL2 compiler switch will be overly 
difficult. It will also encourage keeping SDL1 support alive while SDL2 
development proceeds.


Next issue, backwards compatibility. The SDL1/SDL2 compiler switch is 
just the starting point. It is the foundation upon which new, SDL2 
specific code is written. Pygame has become more than a thin wrapper 
over SDL. It should be quicker to add a few new classes to support the 
window/texture/renderer framework of GPL acceleration than to start from 
scratch. Meanwhile Pygame maintains the display surface/blit interface, 
which is also supported in SDL2, for backward compatibility.


Much of the work in adapting Pygame to SDL2 has been done. This will 
reduce the time taken until coding for new SDL2 features begins. Using 
Cython will reduce coding time further, and hopefully allow more people 
to participate. All in all I believe this incremental approach will give 
quicker, more solid, results than writing a new package from scratch.


Finally, I threw together a code example of how I envision Pygame 2 
(taken from 
http://www.willusher.io/sdl2%20tutorials/2013/08/17/lesson-1-hello-world):


# Simple Pygame 2 example using a window, renderer, and texture.

import pygame as pg

pg.display.init()
win = pg.display.Window("Hello World!", (100, 100, 640, 480), 
pg.WINDOW_SHOWN)

ren = win.renderer(-1, pg.RENDERER_ACCELERATED | pg.RENDERER_PRESENTVSYNC)
bmp = pg.image.load("hello.bmp")
tex = ren.texture(bmp)

for i in range(3):
ren.clear()
tex.copy_to_renderer()
ren.present()
pg.time.delay(1000)

pg.quit()


Notice that surfaces, as returned by image.load(), still exist. Also, 
pygame.display.Window is an addition. Module pygame.display functions 
set_mode(),  flip() and, update() remain and work as expected.


Lenard Lindstrom


On 17-03-21 10:31 AM, Ian Mallett wrote:

​​Hi,

On Mon, Mar 20, 2017 at 11:55 PM, René Dudfield > wrote:


There are few people on this mailing list which have a lot of
knowledge about GPU rendering, and Ian is definitely one of them.
I think he was genuinely trying to be helpful. His claim isn't
even controversial - GPU, ASIC, and CPU rendering all have
different trade offs. As do game libraries like pygame.

On Mon, Mar 20, 2017 at 5:18 PM, Leif Theden > wrote:


Ian, you are really trying to make the case that a software
renderer making simple shapes around the on the screen is better
than a GPU?  Why then are basically all games these days using a
GPU?  Please, don't answer it, because I'm not sure if you are
trolling or not, and don't want to risk derailing the tread with
this...honestly quite ludicrous assertion you've made.  The proof
is in the pudding, so to speak, and the pudding is certainly not
software rendering anything.

Thanks René! And to clarify: (1) Leif, the answers to your objections 
are in that wall of text, which is of course why I wrote it. (2) I do 
not troll. (3) You're right that if hardware acceleration is off the 
table, then this conversation is orthogonal here. But, it's unclear to 
me if it /is/ off the table.


At the risk of over-simplification, but in the interest of moving the 
conversation forward, let's try to put the current issues in context. 
As I understand it, the proposals vis-à-vis SDL2 are:


1: Do nothing

2: (Progressively) integrate SDL2 patch into existing pygame with
goal of eventual SDL1/SDL2 compile option (René and Lenard OP,
many detailed variations)

3: Transition (as above or rewrite) to use SDL2 only (various)

. . . any of which implemented with the following options, which are 
not necessarily mutually incompatible:


A: Share/relicense pygame_sdl2
B: Expose a different API designed for performance (for graphics
especially)
C: Base largely on hardware acceleration for performance

D: Expose new SDL2 features in the pygame API

​. . . and under the following serious constraint, which I think is 
accurate:​
On Tue, Mar 21, 2017 at 6:27 AM, Leif Theden > wrote:


Let's be realistic, there are very few people who have the will or
ability to deal with the pygame code base
​​


I'll keep my opinion short: personally, I'm okay with any proposal, 1, 
2, or 3, though I'd pick 3 over 2, despite being a bi

Re: [pygame] Re: pygame with SDL2 proposal

[René Dudfield]

(... just realized ... )

cvs -> svn -> hg -> git
+ bazaar for launchpad pygame ubuntu builds

All the version control systems!

(I think pygame was in the google perforce at some point too)

Re: [pygame] Re: pygame with SDL2 proposal

[René Dudfield]

>
>- Handling of transparent backgrounds on images. Pygame requires extra
>code for this
>- Easily scaling graphics
>- Easily rotating graphics and drawing primitives
>- Not having the graphics coordinates reversed
>- Easy 'scrolling' of games by showing only part of a larger canvas to
>draw on
>- Pygame naming was a bit inconsistent
>
>
>
Thanks Paul. That's some good feedback for what we can improve.

I guess a sprite with scaling, rotation, and easier resource loading could
be used/added to help with a few of those. Then if things were in a group
like LayeredDirty it could handle scrolling. (as a bonus it would work
faster on lower powered machines, since that optimizes layers and dirty
updates). I'm pretty sure an API could be made which made these things
quite nice to use. Maybe a sprite class like this would be an option for
pygame zero as well.

s = Sprite('sheep.png').rotate(30).scale(2)

Internally it could load from data/sheep.png, or ./sheep.png and
automatically handle transparency convert. rotate, and scale what they say.
Internally, they'd call the correct pygame transform functions at draw time.

I haven't looked to closely, but I noticed there have been newer SDL_gfx
releases. Including a release for SDL2. Not sure how a rotated/scaled draw
api would look like. But I guess transforming the inputs could work. Again
a sprite class which was just a line, rect, circle, etc, but it would
handle the transforms internally (using pygame.math vectors internally
perhaps). Or the group could be transformed as well.

l = Line(1,2, 3,4).rotate(30).scale(2)

Just some off the cuff ideas. But I guess a friendlier sprite API could
work to address everything except the reversed coordinates, and naming.


cheers,

Re: [pygame] Re: pygame with SDL2 proposal

[Leif Theden]

Ian, I read the text, and I'll just reiterate that I don't think that your
use case is what the greater community would benefit from.  We agree that
option 3 is the way forward, so I'm happy we have some common ground.

On Tue, Mar 21, 2017 at 12:31 PM, Ian Mallett  wrote:

> ​​Hi,
>
> On Mon, Mar 20, 2017 at 11:55 PM, René Dudfield  wrote:
>
>> There are few people on this mailing list which have a lot of knowledge
>> about GPU rendering, and Ian is definitely one of them. I think he was
>> genuinely trying to be helpful. His claim isn't even controversial - GPU,
>> ASIC, and CPU rendering all have different trade offs. As do game libraries
>> like pygame.
>>
> On Mon, Mar 20, 2017 at 5:18 PM, Leif Theden 
> wrote:
>
>> Ian, you are really trying to make the case that a software renderer
>> making simple shapes around the on the screen is better than a GPU?  Why
>> then are basically all games these days using a GPU?  Please, don't answer
>> it, because I'm not sure if you are trolling or not, and don't want to risk
>> derailing the tread with this...honestly quite ludicrous assertion you've
>> made.  The proof is in the pudding, so to speak, and the pudding is
>> certainly not software rendering anything.
>>
> Thanks René! And to clarify: (1) Leif, the answers to your objections are
> in that wall of text, which is of course why I wrote it. (2) I do not
> troll. (3) You're right that if hardware acceleration is off the table,
> then this conversation is orthogonal here. But, it's unclear to me if it
> *is* off the table.
>
> At the risk of over-simplification, but in the interest of moving the
> conversation forward, let's try to put the current issues in context. As I
> understand it, the proposals vis-à-vis SDL2 are:
>
> 1: Do nothing
>
> 2: (Progressively) integrate SDL2 patch into existing pygame with goal of
> eventual SDL1/SDL2 compile option (René and Lenard OP, many detailed
> variations)
>
> 3: Transition (as above or rewrite) to use SDL2 only (various)
>
> . . . any of which implemented with the following options, which are not
> necessarily mutually incompatible:
>
> A: Share/relicense pygame_sdl2
> B: Expose a different API designed for performance (for graphics
> especially)
> C: Base largely on hardware acceleration for performance
>
> D: Expose new SDL2 features in the pygame API
>
> ​. . . and under the following serious constraint, which I think is
> accurate:​
> On Tue, Mar 21, 2017 at 6:27 AM, Leif Theden 
>  wrote:
>
>> Let's be realistic, there are very few people who have the will or
>> ability to deal with the pygame code base
>> ​​
>>
>
> I'll keep my opinion short: personally, I'm okay with any proposal, 1, 2,
> or 3, though I'd pick 3 over 2, despite being a bit dangerous. At the same
> time, I think option B implies we want to leave our niche (which I'm
> vaguely against) and option C is implausible (again, for our niche). Saving
> work is preferable, but otherwise I don't know enough to say anything about
> A. I support D.
>
> Ian
>

Re: [pygame] Re: pygame with SDL2 proposal

[Leif Theden]

SDL2 will let you create textures from Surfaces, so you could do all your
drawing on a surface, then make a texture out if for rendering.  With
Pygame's existing drawing code, you should be fine, I think.  Maybe it
would be useful to build a class that uses a Surface for drawing pixel
operations, and is linked to a Texture (SDL_TEXTUREACCESS_STREAMING and
SDL_UpdateTexture).  Add warnings that it is not to be used in the general
purpose so people don't just load surfaces from disk and abuse streaming.
Maybe include a special texture for full screen drawing operations?

Pyglet's batches are a pain point, but is inline with how graphics API
work.  It is really convenient to just blit evenrything where you want
things, but in my experience, any pygame/pyglet project ends up
reimplementing SpriteGroups/Batches anyway...So I don't really think that
there is a solution besides, "Just use Groups/Batches from the beginning",
even if that means drawing to textures and sending them with the sprites.
It might even be faster than inducing context switches in OpenGL.



On Tue, Mar 21, 2017 at 12:11 PM, Paul Vincent Craven  wrote:

> I played around with pygame on top of SDL2 a long while back. In case it
> helps, I thought I'd talk about the issues I had.
>
>
>- Lack of support for drawing primitives. For me as an instructor,
>drawing primitives are important. But SDL2 did not support drawing a 3
>pixel wide diagonal line. Everything had to be 1 pixel wide unless you did
>that glx add-on.
>- glx support was an either/or thing. If I did want to draw a wide
>line, I could use glx or whatever they called it. But that was a completely
>different surface than what textures and sprites used. So I couldn't
>combine the two.
>- There wasn't a large community built around SDL2
>
> Eventually, I decided to go with OpenGL to do my graphics, and piggy-back
> on Pyglet for event management with the Arcade library.
>
> Question: Has SDL2 progressed so that you can draw a sprite with texture
> and a thick diagonal line on the same screen?
>
> Breaking away from the PyGame API let me avoid teaching pygame oddities.
> Specifically:
>
>- Handling of transparent backgrounds on images. Pygame requires extra
>code for this
>- Easily scaling graphics
>- Easily rotating graphics and drawing primitives
>- Not having the graphics coordinates reversed
>- Easy 'scrolling' of games by showing only part of a larger canvas to
>draw on
>- Pygame naming was a bit inconsistent
>
> Problems I'm still dealing with:
>
>- Hassle of cross-platform sound support.
>- GPU rendering is SLOW if you don't batch everything up. Pygame is
>faster at drawing primitives than OpenGL is, unless you learn to offload
>the drawing to the GPU. This is fine if you draw all the sprites at once,
>but if you draw shapes or sprites individually it is a huge performance
>hit. So you have to teach that concept if you want any performance in your
>games at all.
>
> I'm not entirely sure that SDL2 is the best path for PyGame.
>
> -- As for keeping or changing the API --
>
> The "arcade" library examples here:
>
> http://arcade.academy/examples/index.html
>
> Are very similar to the pygame examples here:
>
> http://programarcadegames.com/index.php?chapter=example_code
>
> But the API is simpler, and I think the code is easier for a beginner. I'd
> think carefully if keeping the API is a plus or a minus. I don't know what
> is best, but I took my bet by doing a new API.
>
>
> Paul Vincent Craven
>
> On Tue, Mar 21, 2017 at 10:55 AM, René Dudfield  wrote:
>
>> Leif, thanks for your emails. It could be helpful if you have a proposal,
>> that you put it forward.
>>
>> I think you've definitely made your position, and your priorities clear
>> about what we should do. However, so far I don't see a clear proposal from
>> you with any support. Perhaps if there was one we'd have a better idea
>> about what you are planning to do. And people could decide if your plan is
>> something they want to do.
>>
>> However from what you've written, I don't feel that this proposal will
>> fail to deliver 'modern' features you're after. You seem to have missed the
>> part where we said a few times that new SDL2 features would be added. If
>> there's people interested in adding the additional SDL2 APIs to this work,
>> no one will stop them, and they will be supported. Additionally, it's been
>> pointed out to you that several other python libraries exist which are
>> based on OpenGL with textures. People can use them today. A few of those
>> libraries are featured on the front page of the pygame website.
>>
>> Compatibility is important to me, and I think I've put my best case
>> forward about how I think it will save us effort in development.  Not to
>> mention saving effort for the hundreds of thousands of people who are
>> currently using pygame. I think compatibility is important to other
>> developers be

Re: [pygame] Re: pygame with SDL2 proposal

[Ian Mallett]

​​Hi,

On Mon, Mar 20, 2017 at 11:55 PM, René Dudfield  wrote:

> There are few people on this mailing list which have a lot of knowledge
> about GPU rendering, and Ian is definitely one of them. I think he was
> genuinely trying to be helpful. His claim isn't even controversial - GPU,
> ASIC, and CPU rendering all have different trade offs. As do game libraries
> like pygame.
>
On Mon, Mar 20, 2017 at 5:18 PM, Leif Theden  wrote:

> Ian, you are really trying to make the case that a software renderer
> making simple shapes around the on the screen is better than a GPU?  Why
> then are basically all games these days using a GPU?  Please, don't answer
> it, because I'm not sure if you are trolling or not, and don't want to risk
> derailing the tread with this...honestly quite ludicrous assertion you've
> made.  The proof is in the pudding, so to speak, and the pudding is
> certainly not software rendering anything.
>
Thanks René! And to clarify: (1) Leif, the answers to your objections are
in that wall of text, which is of course why I wrote it. (2) I do not
troll. (3) You're right that if hardware acceleration is off the table,
then this conversation is orthogonal here. But, it's unclear to me if it
*is* off the table.

At the risk of over-simplification, but in the interest of moving the
conversation forward, let's try to put the current issues in context. As I
understand it, the proposals vis-à-vis SDL2 are:

1: Do nothing

2: (Progressively) integrate SDL2 patch into existing pygame with goal of
eventual SDL1/SDL2 compile option (René and Lenard OP, many detailed
variations)

3: Transition (as above or rewrite) to use SDL2 only (various)

. . . any of which implemented with the following options, which are not
necessarily mutually incompatible:

A: Share/relicense pygame_sdl2
B: Expose a different API designed for performance (for graphics especially)
C: Base largely on hardware acceleration for performance

D: Expose new SDL2 features in the pygame API

​. . . and under the following serious constraint, which I think is
accurate:​
On Tue, Mar 21, 2017 at 6:27 AM, Leif Theden  wrote:

> Let's be realistic, there are very few people who have the will or ability
> to deal with the pygame code base
> ​​
>

I'll keep my opinion short: personally, I'm okay with any proposal, 1, 2,
or 3, though I'd pick 3 over 2, despite being a bit dangerous. At the same
time, I think option B implies we want to leave our niche (which I'm
vaguely against) and option C is implausible (again, for our niche). Saving
work is preferable, but otherwise I don't know enough to say anything about
A. I support D.

Ian

Re: [pygame] Re: pygame with SDL2 proposal

[Paul Vincent Craven]

I played around with pygame on top of SDL2 a long while back. In case it
helps, I thought I'd talk about the issues I had.


   - Lack of support for drawing primitives. For me as an instructor,
   drawing primitives are important. But SDL2 did not support drawing a 3
   pixel wide diagonal line. Everything had to be 1 pixel wide unless you did
   that glx add-on.
   - glx support was an either/or thing. If I did want to draw a wide line,
   I could use glx or whatever they called it. But that was a completely
   different surface than what textures and sprites used. So I couldn't
   combine the two.
   - There wasn't a large community built around SDL2

Eventually, I decided to go with OpenGL to do my graphics, and piggy-back
on Pyglet for event management with the Arcade library.

Question: Has SDL2 progressed so that you can draw a sprite with texture
and a thick diagonal line on the same screen?

Breaking away from the PyGame API let me avoid teaching pygame oddities.
Specifically:

   - Handling of transparent backgrounds on images. Pygame requires extra
   code for this
   - Easily scaling graphics
   - Easily rotating graphics and drawing primitives
   - Not having the graphics coordinates reversed
   - Easy 'scrolling' of games by showing only part of a larger canvas to
   draw on
   - Pygame naming was a bit inconsistent

Problems I'm still dealing with:

   - Hassle of cross-platform sound support.
   - GPU rendering is SLOW if you don't batch everything up. Pygame is
   faster at drawing primitives than OpenGL is, unless you learn to offload
   the drawing to the GPU. This is fine if you draw all the sprites at once,
   but if you draw shapes or sprites individually it is a huge performance
   hit. So you have to teach that concept if you want any performance in your
   games at all.

I'm not entirely sure that SDL2 is the best path for PyGame.

-- As for keeping or changing the API --

The "arcade" library examples here:

http://arcade.academy/examples/index.html

Are very similar to the pygame examples here:

http://programarcadegames.com/index.php?chapter=example_code

But the API is simpler, and I think the code is easier for a beginner. I'd
think carefully if keeping the API is a plus or a minus. I don't know what
is best, but I took my bet by doing a new API.


Paul Vincent Craven

On Tue, Mar 21, 2017 at 10:55 AM, René Dudfield  wrote:

> Leif, thanks for your emails. It could be helpful if you have a proposal,
> that you put it forward.
>
> I think you've definitely made your position, and your priorities clear
> about what we should do. However, so far I don't see a clear proposal from
> you with any support. Perhaps if there was one we'd have a better idea
> about what you are planning to do. And people could decide if your plan is
> something they want to do.
>
> However from what you've written, I don't feel that this proposal will
> fail to deliver 'modern' features you're after. You seem to have missed the
> part where we said a few times that new SDL2 features would be added. If
> there's people interested in adding the additional SDL2 APIs to this work,
> no one will stop them, and they will be supported. Additionally, it's been
> pointed out to you that several other python libraries exist which are
> based on OpenGL with textures. People can use them today. A few of those
> libraries are featured on the front page of the pygame website.
>
> Compatibility is important to me, and I think I've put my best case
> forward about how I think it will save us effort in development.  Not to
> mention saving effort for the hundreds of thousands of people who are
> currently using pygame. I think compatibility is important to other
> developers because there are a few other implementations of the pygame API
> which aimed for compatibility. Additionally, I think it prudent we do a
> spike test on linux to see if things are actually going to be good enough,
> and I think we can decide to change approach if it turns out that
> compatibility is harder than expected after wider testing.
>
> Perhaps there is support for a new, from scratch pygame with modern
> features for real developers developing real games which breaks
> compatibility. To find out, a proposal for such would help.
>
>
> For the record, I think some of the things that you've mentioned are good
> ideas backed up by evidence, sound thinking, and fair criticism. Thank you
> for your contribution and passionate discussion.
>
>
>
>
> And to summarize some parts of the conversation so far, including the
> changes and clarifications to the original proposal:
>
>- You can actually build pygame from source now with SDL2. No need to
>wait 3 years.
>- SDL2 features, like textures can be supported with new APIs. New
>games can stick to those features if they prefer, or use an alternative
>library with no pygame compatibility.
>- Compatibility is important to at least some people.
>- I think it prudent we do a s

Re: [pygame] Re: pygame with SDL2 proposal

[Leif Theden]

I would say that many people don't use pygame for more than simple games or
experiments, because simple graphics is largely all that it is capable of
(and remain playable). I also don't think that the situation that Ian
described is what the larger community would want, even if it is useful to
him.

Hiding the complexity of the underlying graphics system should be a goal,
so that students don't need to get lost in the implementation details. But
not providing a way towards modern, high performance graphics is a mistake.

Slow rendering creates a source of frustration and forces people to get
hung up on making it playable, when instead they could be applying more
gameplay features.

Keeping a Surface-like API, (blit a texture?, reserve surfaces for CPU
drawing) backed by textures and a fast framework seems like the way
forward. But no developer here wants to commit to it, or even affirm that
people want reasonably fast graphics.

Not everyone was raised on C64, NES and 16-bit graphics and they have
expectations that computer graphics should be fast. Those systems, I'll
add, were hardware accelerated.


On Tue, Mar 21, 2017 at 8:23 AM Thomas Kluyver  wrote:

> On 21 March 2017 at 12:27, Leif Theden  wrote:
>
> Students should be taught how textures work, where different memories
> reside, and that GPUs operate differently than a CPU. At this point I think
> everyone knows where I stand, so I'll just let it go, since my comments are
> not being taken seriously.
>
>
> Leif, I don't think it's true that your comments aren't being taken
> seriously.
>
> I agree with you that pygame has suffered from a shortage of maintainer
> time. But I take issue on a couple of other points:
>
> 1. I don't think it's realistic to teach all students about memory
> hierarchies and the differences between GPUs and CPUs, while they're also
> trying to learn lots of other concepts about how to build a game, and
> possibly even learning to program. Those are topics people will need to
> know about if they want to build games more seriously, but a lot of people
> using pygame are not doing it to build big complex games.
>
> 2. As Ian explained, the kinds of games many people build with pygame
> cannot easily be 'hardware accelerated', because they don't fit GPU work
> patterns. But there are still a lot of fun and interesting things we can do
> in CPU-based games! Pygame survives in a niche of people building simple
> games which don't need great performance. If we can expand that niche,
> great, but your plan sounds like jumping out of the niche and trying to
> compete with other higher-performance frameworks, which doesn't sound like
> a good idea to me.
>
> Thomas
>

Re: [pygame] Re: pygame with SDL2 proposal

[René Dudfield]

Leif, thanks for your emails. It could be helpful if you have a proposal,
that you put it forward.

I think you've definitely made your position, and your priorities clear
about what we should do. However, so far I don't see a clear proposal from
you with any support. Perhaps if there was one we'd have a better idea
about what you are planning to do. And people could decide if your plan is
something they want to do.

However from what you've written, I don't feel that this proposal will fail
to deliver 'modern' features you're after. You seem to have missed the part
where we said a few times that new SDL2 features would be added. If there's
people interested in adding the additional SDL2 APIs to this work, no one
will stop them, and they will be supported. Additionally, it's been pointed
out to you that several other python libraries exist which are based on
OpenGL with textures. People can use them today. A few of those libraries
are featured on the front page of the pygame website.

Compatibility is important to me, and I think I've put my best case forward
about how I think it will save us effort in development.  Not to mention
saving effort for the hundreds of thousands of people who are currently
using pygame. I think compatibility is important to other developers
because there are a few other implementations of the pygame API which aimed
for compatibility. Additionally, I think it prudent we do a spike test on
linux to see if things are actually going to be good enough, and I think we
can decide to change approach if it turns out that compatibility is harder
than expected after wider testing.

Perhaps there is support for a new, from scratch pygame with modern
features for real developers developing real games which breaks
compatibility. To find out, a proposal for such would help.


For the record, I think some of the things that you've mentioned are good
ideas backed up by evidence, sound thinking, and fair criticism. Thank you
for your contribution and passionate discussion.




And to summarize some parts of the conversation so far, including the
changes and clarifications to the original proposal:

   - You can actually build pygame from source now with SDL2. No need to
   wait 3 years.
   - SDL2 features, like textures can be supported with new APIs. New games
   can stick to those features if they prefer, or use an alternative library
   with no pygame compatibility.
   - Compatibility is important to at least some people.
   - I think it prudent we do a spike test on linux to see if things are
   actually going to be good enough, and I think we can decide to change
   approach if it turns out that compatibility is harder than expected. So far
   the unit tests pass, and there is no known theoretical reason why
   compatibility is not possible. Older versions of pygame will still be
   available by pip, and it's still possible for people to repackage pygame
   1.9.3 on linux as pygame1 if absolutely needed - but I doubt it will be.
   - Some people are worried about compatibility wasting effort. Some would
   like compatibility if it's not going to take too much effort. There is
   concern compatibility would be hard to do.
   - Performance on raspberry pi and other educational boards is important
   to me(and others). And by releasing pygame+SDL2 for linux first, we can get
   there pretty quickly.
   - The no patches accepted slander is easily disproved by looking at the
   patches we accepted by many people. Some people on this list have even
   spent months of boring admin effort so that other people can get paid to
   work on pygame projects.
   - The SDL1 code is already there, and I don't think me or anyone else
   will be writing any SDL1 specific code. Probably almost zero. If the
   concerns about maintenance turn out to be true after we do the changes for
   linux first, we can change our minds.
   - Mobile support is important to people. I don't see this proposal
   blocking anyone working on mobile support, only making it easier. However,
   I personally think we have more basic concerns. For iOS we would still need
   to work out licensing. For iOS pygame_sdl2 is an option for people today.
   - Better tooling for distribution of apps should probably continue to
   happen outside of pygame. Likewise for other complicated things that don't
   need tight coupling.
   - New modules in Cython are a fine idea(we have one part already in
   Cython). Even though we actually get more contributions for C than the
   python or Cython parts so far. [Pyrex forever!] No one has objected to this.
   - Tom has made an offer to share/relicense pygame_sdl2 code, and would
   love to work with anyone on bringing pygame_sdl2 up to parity with pygame.
   May rename it something else. Not sure if he is interested in collaborating
   with the pygame+sdl2 patches I'm proposing, seems busy with full renpy
   schedule. But I'd be happy to use anything he has to offer in there. I'm
   not sure if the pyga

Re: [pygame] Re: pygame with SDL2 proposal

[Thomas Kluyver]

On 21 March 2017 at 12:27, Leif Theden  wrote:

> Students should be taught how textures work, where different memories
> reside, and that GPUs operate differently than a CPU. At this point I think
> everyone knows where I stand, so I'll just let it go, since my comments are
> not being taken seriously.


Leif, I don't think it's true that your comments aren't being taken
seriously.

I agree with you that pygame has suffered from a shortage of maintainer
time. But I take issue on a couple of other points:

1. I don't think it's realistic to teach all students about memory
hierarchies and the differences between GPUs and CPUs, while they're also
trying to learn lots of other concepts about how to build a game, and
possibly even learning to program. Those are topics people will need to
know about if they want to build games more seriously, but a lot of people
using pygame are not doing it to build big complex games.

2. As Ian explained, the kinds of games many people build with pygame
cannot easily be 'hardware accelerated', because they don't fit GPU work
patterns. But there are still a lot of fun and interesting things we can do
in CPU-based games! Pygame survives in a niche of people building simple
games which don't need great performance. If we can expand that niche,
great, but your plan sounds like jumping out of the niche and trying to
compete with other higher-performance frameworks, which doesn't sound like
a good idea to me.

Thomas

Re: [pygame] Re: pygame with SDL2 proposal

[Leif Theden]

I'll add, so that my comments don't seem too caustic, that the maintainers
have gotten more responsive recently. The "don't accept patches" comment
isn't as true as it used to be.
On Tue, Mar 21, 2017 at 7:27 AM Leif Theden  wrote:

> At this rate, we can expect SDL 2 to work in 3 years...all in the name of
> compatibility? It doesn't help that Rene is also maintaining the webpage...
> he's got no time. Let's be realistic, there are very few people who have
> the will or ability to deal with the pygame code base; and with the
> maintainers past record of not accepting patches, this transition will be
> very slow.
>
> This dual library approach sounds like a nightmare to implement. Consider
> that you will effectively be writing code destined to be thrown out when
> SDL1 is no longer needed. You clearly must not value your own time, to be
> spending it on throw away shim code. There are significant differences in
> SDL 2 that you will be writing and maintaining adapter code for, like
> Leonard mentioned. Pygame isn't some mission critical piece of software.
> Let 1.9 be, and put all new patches into getting SDL2 working for 2.0, and
> let there be broken changes. Let someone else maintain 1.9, if they have a
> desire to maintain it.
>
> And putting priorities into the software rendering subsystem is harmful.
> The old tutorials and books are not useful, because no games or
> applications use software rendering. Students will still hit a performance
> wall because they are taught to use surfaces instead of textures and will
> just move onto another platform because "Python is slow".
>
> Python and pygame could rule the SBC educational market, but it is so slow
> on those platforms without hardware acceleration that it become frustrating
> to use.
>
> Students should be taught how textures work, where different memories
> reside, and that GPUs operate differently than a CPU. At this point I think
> everyone knows where I stand, so I'll just let it go, since my comments are
> not being taken seriously.
> On Tue, Mar 21, 2017 at 6:15 AM Thomas Kluyver  wrote:
>
> On 21 March 2017 at 10:48, René Dudfield  wrote:
>
> It sounds like you're still not convinced though. I can make the tree
> first, and we can see what it looks like more easily. If it turns out to be
> not such a good idea afterwards we can always remove sdl1 support.
>
>
> I'm not entirely convinced - maintaining compatibility with SDL 1 and 2
> sounds like the sort of thing that *should* be easy, but could leave us
> with a lot of corner cases where one or the other doesn't work, and result
> in confusing issues when a game is tested on one and then unwittingly
> played on the other.
>
> But I don't know SDL well enough to understand how big the difference is,
> and the transition doesn't interest me enough to work on it myself. I'm
> satisfied that I've made my case, and you're evidently not convinced, so go
> ahead and do it as you've planned.
>
> The one detail I'd ask for before any SDL1/2 release is a Python API to
> get the SDL version number, if there isn't one already, so when people
> report issues there's an easy way for them to find out which SDL they're
> using.
>
> Thomas
>
>

Re: [pygame] Re: pygame with SDL2 proposal

[Leif Theden]

At this rate, we can expect SDL 2 to work in 3 years...all in the name of
compatibility? It doesn't help that Rene is also maintaining the webpage...
he's got no time. Let's be realistic, there are very few people who have
the will or ability to deal with the pygame code base; and with the
maintainers past record of not accepting patches, this transition will be
very slow.

This dual library approach sounds like a nightmare to implement. Consider
that you will effectively be writing code destined to be thrown out when
SDL1 is no longer needed. You clearly must not value your own time, to be
spending it on throw away shim code. There are significant differences in
SDL 2 that you will be writing and maintaining adapter code for, like
Leonard mentioned. Pygame isn't some mission critical piece of software.
Let 1.9 be, and put all new patches into getting SDL2 working for 2.0, and
let there be broken changes. Let someone else maintain 1.9, if they have a
desire to maintain it.

And putting priorities into the software rendering subsystem is harmful.
The old tutorials and books are not useful, because no games or
applications use software rendering. Students will still hit a performance
wall because they are taught to use surfaces instead of textures and will
just move onto another platform because "Python is slow".

Python and pygame could rule the SBC educational market, but it is so slow
on those platforms without hardware acceleration that it become frustrating
to use.

Students should be taught how textures work, where different memories
reside, and that GPUs operate differently than a CPU. At this point I think
everyone knows where I stand, so I'll just let it go, since my comments are
not being taken seriously.
On Tue, Mar 21, 2017 at 6:15 AM Thomas Kluyver  wrote:

> On 21 March 2017 at 10:48, René Dudfield  wrote:
>
> It sounds like you're still not convinced though. I can make the tree
> first, and we can see what it looks like more easily. If it turns out to be
> not such a good idea afterwards we can always remove sdl1 support.
>
>
> I'm not entirely convinced - maintaining compatibility with SDL 1 and 2
> sounds like the sort of thing that *should* be easy, but could leave us
> with a lot of corner cases where one or the other doesn't work, and result
> in confusing issues when a game is tested on one and then unwittingly
> played on the other.
>
> But I don't know SDL well enough to understand how big the difference is,
> and the transition doesn't interest me enough to work on it myself. I'm
> satisfied that I've made my case, and you're evidently not convinced, so go
> ahead and do it as you've planned.
>
> The one detail I'd ask for before any SDL1/2 release is a Python API to
> get the SDL version number, if there isn't one already, so when people
> report issues there's an easy way for them to find out which SDL they're
> using.
>
> Thomas
>

Re: [pygame] Re: pygame with SDL2 proposal

[René Dudfield]

​We have pygame.get_sdl_version for the SDL version number.
https://www.pygame.org/docs/ref/pygame.html#pygame.get_sdl_version

I think perhaps it's worth doing the tree, and a pre release on linux first
so more people can test their apps for compatibility. If there's too many
issues, then we might want to reconsider.

Re: [pygame] Re: pygame with SDL2 proposal

[Thomas Kluyver]

On 21 March 2017 at 10:48, René Dudfield  wrote:

> It sounds like you're still not convinced though. I can make the tree
> first, and we can see what it looks like more easily. If it turns out to be
> not such a good idea afterwards we can always remove sdl1 support.


I'm not entirely convinced - maintaining compatibility with SDL 1 and 2
sounds like the sort of thing that *should* be easy, but could leave us
with a lot of corner cases where one or the other doesn't work, and result
in confusing issues when a game is tested on one and then unwittingly
played on the other.

But I don't know SDL well enough to understand how big the difference is,
and the transition doesn't interest me enough to work on it myself. I'm
satisfied that I've made my case, and you're evidently not convinced, so go
ahead and do it as you've planned.

The one detail I'd ask for before any SDL1/2 release is a Python API to get
the SDL version number, if there isn't one already, so when people report
issues there's an easy way for them to find out which SDL they're using.

Thomas