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 

[pygame] Re: Starting the pygame 2 series

[René Dudfield]

*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 pypy wheels on mac+travis
>
>- pypy and manylinux2010 
>because PyPy needs manylinux2010, an old PR from @takluyver
>

[pygame] Re: Starting the pygame 2 series

[René Dudfield]

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 pypy wheels on mac+travis
   
   - pypy and manylinux2010 
   because PyPy needs manylinux2010, an old PR from @takluyver
    was resurrected and changed a bit so we
   can use manylinux2010.

@robertpfeiffer 

   - Add Setup.Android.SDL2.in, and default icons to STRIPPED build
    is an improvement for
   better Android support.

@Starbuck5 

   - Fix docs build failure on Sphinx 3
   , so we can use the current
   version of the Sphinx documentation tool.

Josip Komljenović @MightyJosip 

   - Type hints for Vector swizzles & sprite groups
   
   - draw.line fix with thick lines. More of the line was clipped off on
   screen borders than expected 
   is a fix for an issue @siggisv  found with
   line drawing.

Sigurður Sveinn Halldórsson @siggisv 

   - Document expected behavior of draw.aaline()
   

Ankith @ankith26 

   - Doc improvements for WINDOWEVENT, MOUSEWHEEL, event and misc
   

This time 4 'critical' backwards compatibility issues were fixed since the
last release.
--

   - 6 open 'critical' issues
   

   (backwards compatibility issues reported by people), and 35 closed (last
   release: 7 open, 32 closed).
   - merged PRs
   

   - 2090 Commits since 1.9.6 stable release
   
   - 80 Commits since 2.0.0.dev14 pre release
   

[pygame] Re: Starting the pygame 2 series

[René Dudfield]

pip install pygame==2.0.0.dev14
[image: dreamlines]

-- *Players, only love you when they're playing*

With a very tiny little bit of discussion it was sort of decided that the 28
th of October 2020 will be the pygame  2.0
release date,

because pygame turns 20.


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.

Thanks to Dan Lawrence @MyreMylar  for Adding
a num_buttons parameter to mouse.get_pressed()
. This was a backwards
compatibility issue, because it used to return 3 elements. Now it returns 3
elements again by default and you can request 5 if you want. Another
critical issue fixed by MyreMylar was a problem with key events being
reordered on windows .

But wait... there's more. Another backwards compatibility fix by MyreMylar
is the "Backwards compatibility for get_flags() in SDL2
" PR, which has stopped some
games handling full screen mode properly.

Sigurður Sveinn Halldórsson @siggisv  fixed a
problem with how pygame.draw.aaline didn't look as before.

   - Fix draw.aaline not always solid, and other problems
   

Now the anti aliased lines look (and smell) awesome.
[image: 13]

bugs, worms, shiny-shiny, and such

Ankith @ankith26 

   - Some mouse cursors 
documentation
   improvements 
   - Fix pyinstaller issues with pygame.font.Font
   
   - Document some undocumented pygame.image functions
   
   - Update pygame.version.rev docs
   
   - Adding windowevent constants
   
   - Fixes pygame.display failing unit tests on raspberry pi
   
   - Remove ancient file kept for python v2.4 compatibility
   

Josip Komljenović @MightyJosip 

   - Improved the speed of pygame.draw.line()
   
   - A few more type hint fixes 

Dan Lawrence @MyreMylar 

   - GitHub issue templates: New style
    Part 2
   
   - doc header file regen 
   - Changed display.set_palette() test to test correct function
   

Adam Andrews @adamandrews1 

   - Code cleanup Removed PG_ENABLE_NEWBUF
   

@Starbuck5 

   - Python3 needs *bool* instead of *nonzero*
   
   - timeout option added to event.wait()
    which is useful if you only
   want your app to wake up when something happens and also at least every 1
   second or so.

René Dudfield @illume 

   - Python 3.9 binary wheels 
   (which is a new release of python).
   - Test sdist on CI 
   - Disable timing based tests on mac CI, because issues
   

Nguyễn Gia Phong @McSinyx 

   - Fix mouse.pyi@set_system_cursor type hints
   
   - py.typed for mypy, fix pygame._sdl2 importing touch module type hints
   
   - Clean up README and source distribution
   

Special thanks to the new contributors

@seenemikk 

   - unit test for surface.get_masks()
   

Sebastian Henz @BastiHz 

   - Fix typo in freetype.rst 

Alice Lia Stapleton @slimelia 

   - unit test: display.get_wm_info()
   

This time 4 'critical' backwards compatibility issues were fixed since the
last release.
--

   - 7 open 'critical' issues
 

[pygame] Re: Starting the pygame 2 series

[René Dudfield]

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

Locked in or Locked out? That's not going to stop a new pygame
 coming out.

The main theme of this release is testing. With many new contributors
having worked on unit tests, we can be much more confident that many more
features will continue to work with our SDL2 based pygame 2 as in pygame 1
which is based on SDL1. But we also have a few new features, and plenty of
bug fixes.

Thanks to everyone for their help with this release.
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.

We start with some joystick improvements from Daniel Pope @lordmauve
. Add SDL2-specific methods to Joystick;
rename event fields . Now
joysticks(game pads, drum sets, dance mats) can be hot-plugged, and the
game will still work properly.

@robertpfeiffer  got posting of keydown
events working on SDL2 . This
is part of the android work that has now been merged into the main branch -
but it is also a backwards compatibility fix.

Thanks to Dan Lawrence @MyreMylar  for fixing
segfaults caused when interacting with display surface after quit
, which is mainly useful for
when writing unit tests or playing with pygame interactively.

Sometimes writing tests for existing functionality finds real issues and
bugs. First @tsadama  Added unit tests for
display.toggle_fullscreen and display.get_active
 which uncovered an issue with
SDL2. Then Dan Lawrence @MyreMylar  Fixed
get_active() function so it works as described in docs on windows under
SDL2. .
Tests

Here we see the amount of unit tests left to write to get full coverage of
every pygame method. During this release period you can see a lot of things
got new tests. During the testing it uncovered a number of real issues, and
some of them were even fixed.
pygame version Methods left to test
2.0.0.dev12 81
2.0.0.dev10 127
2.0.0.dev8 143
2.0.0.dev6 147
1.9.6 156
1.9.5 155
1.9.4 189
1.9.3 194
1.9.2 194
1.9.1 232
1.9.0 232
1.8.1 25
1.8.0 0

The count can be found with the following command run in the pygame code
base:

grep todo test/*.py | wc -l

'goodfirstissue
'
is a label applied to issues which would be good for someone who wants to
try contributing to a Free, Open Source, or community project (like
pygame). A lot of these issues were written up containing unit tests that
needed to be finished off.

Unfortunately we will probably run out of things to test in some months. We
hope to prepare new types of 'good first issues', and educational material
in other areas next. So that there is something else for people who are
interested in contributing as a way to learn. Hopefully we can structure it
as a learning pathway, with even some advanced topics.

Thanks to Andy Nguyen @anguye13 , who worked
on a number of tests in the display, image, and surface areas.

   - Unit test for image.save_extended()
   
   - display.set_gamma_ramp() unit test
   
   - Added unit test: surface.get_shifts()
   
   - Added unit test: surface.get_pitch()
   

Adam Andrews @adamandrews1  worked on the
transform, threads parts of the code base. They have also begun work on
cleaning up the buffer code, which is in C and kind of complicated. But
that work is still waiting, and will likely make it into the next release.

   - threads.benchmark_workers and threads.WorkerQueue.do
   
   - pygame.transform.smoothscale
   
   - Reintroduce sizing checks for transform.smoothscale test
   

Travis Chang @Reminisque 

   - Added unit test for mouse.get_cursor()
   
   - Add unit test for surface.get_losses
   
   - Add mouse.set_cursor unit test
   

Dan Lawrence @MyreMylar 

   - Some colorkey test fixes 
   - Testing mixer.music.play() start parameter & adding mp3 warni

[pygame] Re: Starting the pygame 2 series

[René Dudfield]

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

We only released 2.0.0.dev8 24 days ago. However, the last few weeks have
been quite productive!
It's as if we were all trapped inside for some reason.

First up, the 'critical' window resizing
 bugfix thanks to
@robertpfeiffer  but also to @nthykier
. This is another step towards a backwards
compatible pygame 2 release. Another 'critical' bug (backwards
compatibility bugs that block a pygame 2 release from happening) that got a
fix is the pygame.display.update() call on windows. A patch has been merged
into SDL  so this should be
fixed in pygame soon.
Community help

A special thanks to all the people who help out others. From making videos,
to answering questions, to writing guides. MyreMylar, MichaelCPalmer,
jtiai, claudeb, DaFluffyPotato, Rabbid76, The Big Kahuna, sloth, Kingsley,
... and lots of other people.
Type hints, and lint tools

The last pygame pre-release(2.0.0.dev8) shipped with Type hints, and now Type
hints have been refined  (not
like oil, but more like an expensive fermented vegan cheese). Thanks to
Josip Komljenović aka @MightyJosip 

   - Some type hint and examples fixes
   
   - Font type hints - use bool instead of int
   
   - Add an *all* variable to constants.c
    @MyreMylar
    This is useful for fixing static analysis
   tools like pylint and LGTM. The __all__ variable in a module is for
   telling python which variables are to be exported.

Documentation and tutorials

   _
 =(_____   __ __)=
   |   |
   |   |
   | python -m pygame.docs |
   |   |
   | The type hints were a |
   | major part of the doc |
   | work in this release. |
   | Some examples got an  |
   | update too.   |
   |_____   ___|
 =(_)=


   - pygame.examples.glcube has been updated
    to use 'modern' OpenGL API
   thanks to @MyreMylar  but also to
   @robertpfeiffer , @illume
    and @imallett .
   - Fix grammar in rect docs 
   Scott Noyes @snoyes 

an amazing assortment of ammendments

And now have an ARM64 build for testing pygame
 on Travis CI (who provide it
to us for free thanks!). Additionally a few bugs on the release process
were fixed. Hopefully this will help us keep things working nicely on ARM
platforms like the raspberry PI.

   - Add Aarch64 linux library directory to config_unix.py
    @MyreMylar
   

Thanks to @galexandreg  Surface.blit can
now take *very* large rects 
for the area argument. Which is very useful in open world games that could
have huge sizes of surfaces. With SDL1 supporting only smaller rects and
surfaces, it used to be limited to a 16bit number.

SCALED  is a feature for
scaling up low resolution game screens to large size screens - like 4k
monitors or high resolution phone screens. This received some code cleanups
and documentation. Thanks to @robertpfeiffer
, and to @nthykier
 and @MyreMylar 
for help reviewing/testing.

pygame using SDL1  is building
 and passing tests again
 thanks to @MyreMylar
 and @illume . We
stopped testing with SDL1 some time ago, whilst still sort of supporting it
theoretically... but then bitrot set in and a few things stopped working
again. Why do we want to keep doing this? It's useful for backwards
compatibility testing

[pygame] Re: Starting the pygame 2 series

[René Dudfield]

Oops. I forgot to paste the release notes here the other day.



🌺🌻🌹🥀🌷🌼🌸💐💮🌺🌻🌹🥀🌷🌼🌸💐💮🌺🌻
🌼🌸 pip install pygame==2.0.0.dev8
🌺🌻🌹🥀🌷🌼🌸💐💮🌺🌻🌹🥀🌷🌼🌸💐💮🌺🌻

One year ago today on the 5th of May 2019 we released the first development
release of the pygame 2 series. So today is our anniversary of sorts. 🎉
Type hints for better editor support.

Type hints are now installed thanks to @MightyJosip
 #1685
 This lets static type checkers
do TAB completion and check your function inputs and outputs. Giving an
altogether nicer experience when programming with pygame.
Color arguments are fuzzy wuzzy human friendlier

Thanks to new pygame team member @nthykier  in
#1676 
there is now support for writing colors in an easier way.

surf.fill('black') # surf.fill(pygame.Color('black'))
surf.fill('#FFEECCF0') # surf.fill(pygame.Color('#FFEECCF0'))

Drawing improvements, and rounded corners.

Drawing improvements including more correct AND faster circle drawing,
rounded rects. Thanks to @charlesej 
@MightyJosip  and @robertpfeiffer
. #1503


# Draw a rectangle with rounded corners
pygame.draw.rect(screen, GREEN, [115, 210, 70, 40], 10, border_radius=15)
pygame.draw.rect(screen, RED, [135, 260, 50, 30], 0, border_radius=10,
border_top_left_radius=0,
 border_bottom_right_radius=15)
# Draw only one circle quadrant
pygame.draw.circle(screen, BLUE, [250, 250], 40, 0, draw_top_right=True)
pygame.draw.circle(screen, RED, [250, 250], 40, 30, draw_top_left=True)
pygame.draw.circle(screen, GREEN, [250, 250], 40, 20, draw_bottom_left=True)
pygame.draw.circle(screen, BLACK, [250, 250], 40, 10, draw_bottom_right=True)


   - Drawing an empty string now returns a zero sized surface and rect,
   before it was 1 pixel wide and the height of the font. #1488
    Thanks to the @MightyJosip
   
   - Additionally, zero sized rects do not collide with anything anymore -
   thanks to @thiagojobson  and @charlesej
    #1226
   
   - Fix drawing ellipses with width values > 1
   @charlesej
   
   - draw.c code refactoring and cleanup
   @MightyJosip
   
   - Declare UTF-8 encoding in draw_py
   @stefanor
   


pygame recipe added to Python-For-Android

Thanks to @AndreMiras , @robertpfeiffer
 and others there is a pygame recipe in
python-for-android kivy/python-for-android#2164
 which is a python
for android distribution.


Documentation and tutorials

Lots of little fixes, and even a whole new tutorial were made in this
release. When someone takes the time to fix a little problem in the
documentation that can help many people in the future from getting lost
themselves.

   - A new tutorial in Korean (and english) #1512
    from first time contributor
   @rumia0601 
   - Thanks to first time contributor @glennmackintosh
    for fixing the docs for KMOD_MODE
   #1657 
   - pygame.cursors.compile doc fix
    thanks to @MyreMylar
   
   - Thanks to @w-hat  for the doc cleanups #1687
   .
   @Starbuck5  Fixed a typo in gfxdraw doc
   
   - Use an explicit encoding in the documentation headers writer
    @stefanor
   and Dominik George.
   - Fix documentation for Vector3's rotate methods
    @charlesej
   
   - Fix a number of spelling mistakes
   @stefanor
   
   - Fix incorrect comments in draw module example
    @Starbuck5
   
   - Thanks @vilhelmprytz  for a little
   doc fix  :)
   - pygame.music.play() looping docs consistent with pygame and SDL
   behaviour  @MyreMylar
   

[pygame] Re: Starting the pygame 2 series

[René Dudfield]

Now for something a little different...


One focus: pygame 2 issues.
Feature freeze for two months.
One issue at a time.
https://github.com/pygame/pygame/issues/1511

[pygame] Re: Starting the pygame 2 series

[René Dudfield]

🌺🌻🌹🥀🌷🌼🌸💐💮🌺🌻🌹🥀🌷🌼🌸💐💮🌺🌻
🌼🌸 pip install pygame==2.0.0.dev6
🌺🌻🌹🥀🌷🌼🌸💐💮🌺🌻🌹🥀🌷🌼🌸💐💮🌺🌻

Python 3.8 support. For pygame 2 anyway. Decided not to do it for pygame
1.9.6, and to instead try and fix a few more of those 'critical' blocker
issues (current critical issue count

is lucky 13).

Virtual Mouse mode with relative mouse movements was fixed to how it was in
pygame 1.9.x - thanks to new committer @mcpalmer1980
. Who also added a new
pygame.music.fadein() function, plus examples!

Support for old SDL1 SDL_VIDEO_WINDOW_POS and SDL_VIDEO_CENTERED
environment variables which were removed in SDL2.
The Great Examples Cleanup of October 2019 is complete.

All of the examples were tidied up. Extra documentation was added, and
things clarified. Thanks to new committer @Starbuck5
 for their work on examples/eventlist.py.
There's now 43 example files!! Cleanups like removing usage of from
pygame.locals import *, which is kind of cool... but also not considered
good practice in the wider python community. Also the examples are now
formatted with the python code for-matter. Additionally two interesting AND
EDUCATIONAL new examples: music_drop_fade.py, and font_viewer.py were
contributed by @mcpalmer1980 

python3 -m pygame.examples.font_viewer
python3 -m pygame.examples.music_drop_fade

Cleanliness brings us joy

As part of the continuing codeprose cleanups of the pygame codeprose-base,
we are now warning free on the clang C compiler on MacOS. Additionally
warnings are now errors on the clang compiler when the robots check our
code for us. We are also very close to zero warnings on different gcc
versions, and Microsoft Visual C compiler too. We reached a new milestone
with the 'LGTM' static analyzer. It now gives pygame an "A+" for both the
python code, and the C code - meaning pygame is within the top 5% of
projects with those languages. LGTM now checks new pull requests
automatically, and helps us find some issues on pull requests. The Coverity
static analyzer rates pygame source code as having less defects than high
quality code bases like the Linux kernel, OpenSSL, and libcurl. Strangely
(to me) pygame is regularly trending on github as a C project. A lot of the
cleanups were done by @charlesej , so thanks
a lot for that! Oh, and a warning... please don't look at our setup.py
file It's still scary AF. We have over 45,000 lines of python in
pygame, and 350,000 lines of C... and a lot of that needs some attention.

Some developer improvements include verbose mode to our test runner (python3
-m pygame.tests -v), and the mechanism to share functions and data in our C
API has been documented. See the Hacking developer guide
.
Want to collide between a rect and a line?

Well, @charlesej  has you covered with the
new Rect.clipline(). This can also tell you where a line clips with a Rect.
It was great to see the discussion on this as different people talked about
API trade offs, and together came up with a very nice API. Thanks to
@mcpalmer1980  for the discussion on the
design, and also to @thiagojobson  (who is
now part of the pygame team on github! 🎈 🎉 ).

First time committer @hnrkcode  fixed how
comments are displayed on the website. Also thanks to @0101011
 for a doc fix. Speaking of new committers,
@galexandreg  helped out fixing the
pygame.mixer.Sound.get_num_channels() function to return a correct result
in some cases (the sound stuff got a number of fixes this release!)

@robertpfeiffer  did some more work on
the SCALED feature, after a patch from @lordmauve
 enabling use of it with OpenGL apps.

Thanks to TravisCI who have allowed us to try out their alpha ARM64
support. We don't have pygame building on it yet, but hopefully soon it can
join our other ROBOT builders like the power pc one.

In distro packaging news, FreeBSD now has pygame 1.9.6. Which is great,
because it stuck around at 1.8.x for many years now. Thanks to Wen, and
Nathan in maintaining it there. See the giant list of 119 pygame packages
 in different distros.
No one seems to have packaged a pre-release of pygame 2 yet.

Cheers to the folks in the discord chat helping people out, chatting and
sharing project updates on things. Especially to claudeb, and blubberquark.

All the regressions that were reported in issues for the 2.0.0.dev4 release
have been fixed. Including one circle drawing regression fix by @MightyJosip
, who also fixed a long lasting 'thick
line' pygame.draw issue. Bo

[pygame] Re: Starting the pygame 2 series

[René Dudfield]

 🎮👾👽🎮👾👽🎮👾👽🎮👾👽🎮👾

G'day! It's 2.0.0.dev4 time!
🎮👾👽🎮👾👽🎮👾👽🎮👾👽🎮👾


python3 -m pip install pygame==2.0.0.dev4 --pre --user
>
What goodies do we have in store?

Firstly, some SDL2 compatibility issues were fixed. Like the window
initially defaults to black, and the unicode field of keydown events is
filled. Thanks to @dlon .

Speaking of SDL2, we are now shipping SDL 2.0.10
 which includes
stuff like batching renderer and lots of bug fixes, including to the Metal
renderer on Mac, lots of other stuff. Thanks to all the libSDL people.

Many, many fixes thanks to @charlesej  and
some static analysis tools.

Some new contributors deserve thanks 🎉 🎈 including:
@thiagojobson  @flaambe
 @mampersat 
@s0lst1ce 

@robertpfeiffer  and @dlon
 fixed some issues with the fancy SCALED feature,
and @robertpfeiffer  got the
toggle_fullscreen function working more reliably too!

And speaking of helping out, @robertpfeiffer
 also helped out @nhpackard
 with an optimization to transform.scale.
When scaling to twice the width and height, a special optimized routine by
@nhpackard  is used.

Lots of fixes and tests happened to the draw, and mask modules mostly
thanks to @charlesej  (but also to
@thiagojobson )

Lots of infrastructure changes happened to our build system to make things
easier for
developers. Firstly we started using LGTM which runs some lint tools on our
code for us.
Secondly we started using lots of other testing tools. Thanks to Travis CI
we have a
Power PC CPU robot building things. @takluyver
 made a PR for the new manylinux2010 which
we sadly haven't started using yet. As usual a tiny bit more of the release
process has been automated.

An article for developers on contemporary C tools
 is still
unfinished(but probably useful for developers of pygame). Here's some
issues of those tools applied to pygame:
https://github.com/pygame/pygame/labels/tooling

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

Indic Scripts including Hindi, Telugu, Tamil are closer to being rendered
now thanks to the
work of new contributor @peanutbutterandcrackers
 tracking down things and
writing
some automated tests for it. This work is ready to be developed further and
is moving forward! Thanks!

Thanks for all the people trying out the pygame 2.0.0.dev3 builds and
(submitting issues) or patches including: @larryhastings
 @humanbeast7
 @Pololot64 
@mcpalmer1980 
@husano896  @galexandreg
 @mgedmin 
@cgohlke  @cipri-tom
 @noisnemid 
@DudmasterUltra 
@agdt3  @crowjdh 
@JOHNIDnDNIW  @lordmauve
 @dheerajakula


Speaking of bugs, as people have been using the 2.0.0.dev3 release, they've
been finding various bugs. All SDL2/pygame 2 related compatibility issues
reported by people are marked as critical.
https://github.com/pygame/pygame/labels/critical

These "critical " issues
will be a 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

   - merged PRs
   
   - 713 Commits since 1.9.6 stable release
   
   - 299 Commits since 2.0.0.dev3 pre release
   

--

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

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

[pygame] Re: Starting the pygame 2 series

[René Dudfield]

*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?

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

[pygame] Re: Starting the pygame 2 series

[René Dudfield]

Meow.

2.0.0.dev3 is out...


There are binaries for Mac, Windows, and Linux with SDL2.

python3 -m pip install pygame==2.0.0.dev3 --pre --user

So... what's new? Here's a few things.

The documentation has been made more readable on big screens and small
ones. It is also updating from github again. @charlesej
 in particular has made a lot of
documentation fixes. See https://www.pygame.org/docs/

It's easier to make custom types that will work with multiple GUI libraries.

FIRST = pygame.event.custom_type()


(No more USEREVENT+1 nonsense) Also with pygame 2.0.0.dev3 you can have
8192 custom events instead of 32.

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


@dlon  added support for some Modern OpenGL
features. For more detail see: #1127


Now you can do one-shot timers like this: pygame.time.set_timer(EVENT,
1000, 1)

Thanks to @bennuttall  and the piwheels
project, pygame has binary wheels for the raspberian linux. See
https://www.piwheels.org/project/pygame/

The sound mixer has moved into the modern age and now defaults to a small
low latency buffer size of 512 bytes, and uses CD quality audio by default.

Check these lists out for more detailed info on what's changed:

   - merged PRs
   
   - 414 Commits since 1.9.6 stable release
   
   - 74 Commits since 2.0.0.dev2 pre release
   




On Thursday, June 20, 2019, René Dudfield  wrote:

> Hey yas,
>
> There are binaries for Mac, Windows, and Linux with SDL2 on pypi.
>
> You can try it out with a command something like this:
> python3 -m pip install pygame==2.0.0.dev2 --pre --user
>
> Also, SDL2 is the default now when you compile from source. You can use python
> setup.py install -sdl1 to compile against SDL 1.2.
>
>
> Feels like some sort of milestone close(r) to the finish line?
>
>
> Apart from lots and *LOTS* of work on the Color, Mask, and pygame.draw
> stuff, there are a few more experimental things. Like the sprite module
> compiled with Cython into C code. Additionally there is the new SCALED
> mode, for automagically scaling your low resolution game into a viewable
> sized window (a 320x200 window is tiny on a 4k screen... so this makes it
> bigger and scales everything for you).
>
> Check these lists out for more detailed info on what's changed:
>
>- merged PRs
>
>- 341 Commits since 1.9.6
>
>
>
> cheerio,
>

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()

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

[pygame] Re: Starting the pygame 2 series

[René Dudfield]

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

[pygame] Re: Starting the pygame 2 series

[René Dudfield]

Hello,

after merging the API cleanup stuff, I'd like to start cleaning up the top
level of the repo.
The goal is to reduce the number of files in there, so that it's easier for
newbies to figure out where things are.

The main open questions for me:
- I'm not sure 'buildconfig' is the best name... for basically build
related stuff.
- MANIFEST.in (is there a way to do this with newer python?)
- mingw support... do we still have it? Is it desirable now that MS makes
versions of their compilers free?

The rest see below...

cheers,



.gdbinit [delete it?]
.hgignore [delete it]
appveyor -> buildconfig/ci/
configtest [delete it? is mingw/msys working?] OR buildconfig

.travis* -> buildconfig/ci/ buildconfig/ci/travis/ [things useful for any
CI moved out of .travis, .travis.yml has to stay in root?]
docs
examples
lib -> [rename to pygame?]
manylinux-build -> buildconfig
obj -> buildconfig
src [C files, might be nice to have that in the name somehow?]
symbian [delete it]
test [most other things use 'tests' these days]
trackmod [deleted?]
.hgignore [deleted]
appveyor.yml [can we move it to ci/, and use settings on the web somehow?]
bdist_mpkg_support.py [delete it]
bundle_docs.py -> buildconfig/ [we are not using this at the moment?]
check_test.py [delete it]
CODE_OF_CONDUCT.md -> [delete it, section in readme covers it]
config*.py -> buildconfig/
configure [delete it, no one actually uses it I think]
distutils_mods.py -> buildconfig/
dll.py -> [delete it? mingw not working anymore?]
install.html [delete it, covered in readme and /GettingStarted on web]
install.txt [delete it, covered in readme and /GettingStarted on web]
LGPL [delete, link in readme]
LICENSE [delete, link in readme]
Makefile
MANIFEST.in [is this still needed with modern distutils?]
mingw32compiler.py [delete? minw doesn't work on windows now?] ->
buildconfig
minw32distutils.py [delete? minw doesn't work on windows now?] ->
buildconfig
mingwcfg.py [delete? minw doesn't work on windows now?] -> buildconfig
msysio.py -> ci/ [still needed?]
readme.html [delete it]
readme.rst
run_tests.py [delete it]
setmods -> [delete it? or move it into setup.py]
Setup.in -> buildconfig
setup.py
Setup_Darwin.in -> buildconfig
Setup_Unix.in -> buildconfig
Setup_Win_Common.in -> buildconfig
setup_win_common.py -> buildconfig
version.py.in [delete it]
WHATSNEW [move it to documentation, a releases section]



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,
>