Hey! It's work on pygame stuff week.
So, it's been about 9 days since I had "a fun day working on pygame stuff". That morning I woke up, and just started working on pygame things. This is a pattern with me between big freelance contracts. Last year I spent some months on pygame stuff, and also the year before that some months.
It was such a fun day... I just kept going. And here we are 9 days later with a web log of some of the things that happened.
"it's the schrödinger's bugtracker" -- þeshipu
#30 https url scheme default(not in DEBUG). https login links even on http.
#29 News feeds (rss, atom) are in the header of every page again.
#28 Improved table of contents on the wiki. Syntax help on edit page. Clear cache after edit.
#27 Changes are now shown again when people do a new project release. Project test improvements.
#31 /admin turned off by default, APP_ADMIN config variable.
#13 Admin interface improvements
"Are pygame releases going to have code names too? :-)" I guess so, but maybe the code name for all of them should be "Weedy Seadragon", because it's such a magical creature.
Thanks to the OpenPOWER foundation and the University of Campinas who provide Power virtual machines to open source developers. It still feels magical to me when I log into a box on another continent to shell-about.
So, I got some Power PC virtual machines for testing. I fixed a few pygame on Debian bugs, and wrote on their issues telling them they are fixed now. Fingers crossed a newer pygame package will make it into Debian, Ubuntu and Raspberian.
Wow. Many thanks to all the people working on that.
Now it's at a stage where a bunch of things actually work. Not enough to play a game on it... but getting much closer.
Learning this good news... I got PyPy building on Travis CI/pygame/pygame (with some tests still failing). Then started a milestone for "Are we PyPy yet?". Stuart Axon has already filed one issue, and asked PyPy developers for help on how to fix it. Stuart wasn't joking saying PyPy devs are super helpful.
This one particular issue has to do with surface locking and reference counting. In CPython when you do "del array" it does what you think... and deletes the array right then and there. However, PyPy has a different type of memory management, and PyPy will decide when to delete things thank you very much!
Like with files in python, it was suggested we gain a method like '.close()' to explicitly deal with these locks. Instead of relying on reference counting semantics. Also, to use a context manager for with.
PixelArray is using Surface locks. It does this so if your Surface is graphics hardware memory underneath your operating system won't crash on you (I hope).
Next up is to start filing pygame issues for each of the test failures and then slowly fixing them. Some of them should be fairly easy, and others are downright scary (BufferProxy and no ctypes.pythonapi on PyPy makes me afraid... very afraid).
Then we have to figure out how to build binary wheels for the various platforms, and probably many other things... All PyPy related work will be tracked on the Are we PyPy yet? milestone in the pygame issue tracker. Not sure how long this work will take, so this won't be included in the upcoming 1.9.4 release I don't think.
That was sort of a fun one to hack a fix for.
There's a couple of issues with sound and pygame on linux with the 'manylinux' binary wheels we have. It took me some time to track the causes down, and find ways to reproduce the issues.
TLDR; midi music is broken with pygame installed by wheels.
One has to do with arch linux using a different configuration directory to every other linux of the last 20 years for timidity. And also to do with how we are not installing special config files on random parts of the linux file systems when people install the wheel with pip.
So, there are a few different software music synthesizers included with pygame. One is timidity (linked above) and the other is fluidsynth. The soundfont playing synth.
So, I just sort of paused at that point. I guess we need to disable timidity (or patch it for arch linux), and for the case when timidity isn't installed. Also, we need to handle soundfonts... either provide a message to the user if they are missing, or see if there are some FLOSS-happy ones we can distribute just on linux.
ps. During these investigations, I found out that fluidsynth has been saved from sourceforge and has had a whole bunch of releases. Awesome. http://www.fluidsynth.org/
Additionally, a couple of new issues were filed against out bitbucket repo... which I haven't closed down yet(because reasons). They are for a couple of SRC_ALPHA regressions it seems. I'll add them into github soon, and also then to the list of blockers for a 1.9.4 release.
A new place to
It was such a fun day... I just kept going. And here we are 9 days later with a web log of some of the things that happened.
 |
| A fun 9 days working on pygame stuff. |
New pygame.org website changes.
Got a new version of the pygame website out. It took a couple of days, but I fixed a number of issues, and improved a few things. In the process I found a lot more issues on the website than I fixed. So there are now more issues listed than when I started. Feels like progress."it's the schrödinger's bugtracker" -- þeshipu
pygameweb 0.0.1 - Weedy Seadragon
 |
| Witness the beauty of the Weedy Seadragon (photo by |
#30 https url scheme default(not in DEBUG). https login links even on http.
#29 News feeds (rss, atom) are in the header of every page again.
#28 Improved table of contents on the wiki. Syntax help on edit page. Clear cache after edit.
#27 Changes are now shown again when people do a new project release. Project test improvements.
#31 /admin turned off by default, APP_ADMIN config variable.
#13 Admin interface improvements
"Are pygame releases going to have code names too? :-)" I guess so, but maybe the code name for all of them should be "Weedy Seadragon", because it's such a magical creature.
Debian bugs.
I've investigated a number of Debian reported issues, and even managed to fix some of them. It never ceases to amaze me that testing on other systems uncovers real bugs which also happen on other platforms (but in harder to detect ways usually). So, for me, it's always worth working on weird platforms - if only for this reason. https://github.com/pygame/
Thanks to Dominik for bringing them into the pygame issue tracker, and for improving the Debian pygame package generally.
It's important to get these fixes in, as I think they are blocking a Debian release of pygame 1.9.3. ... which also blocks derivatives such as Raspberry Pi rasperian distro (who don't provide any support to pygame, or Debian, and just take from Debian packages mostly). Another important derivative is Ubuntu, which also hasn't updated their pygame package.
Here is the Debian
tracker for the pygame package, which lists things that need to be
done. If anyone can spot something I could help out on there, please
feel free to point it out - as I have some days now to investigate and
fix things. https://tracker.debian.org/
Here is the build status on the various Debian platforms:
So, I got some Power PC virtual machines for testing. I fixed a few pygame on Debian bugs, and wrote on their issues telling them they are fixed now. Fingers crossed a newer pygame package will make it into Debian, Ubuntu and Raspberian.
Outdated installation instructions from around the net.
TLDR; If you see anywhere on the net that has outdated pygame install/compile
instructions, please let them know, and send them a link to
GettingStarted.
One thing I've noticed is that there are quite a few web pages on the interwebs describing 'how to install pygame'. Which were all helpful in the past, but are now out of date. The pygame website itself is one place with outdated instructions too. Now they just cause people to fail to install old versions of pygame, and for them to report the same old bugs again and again.
I'm asking people to:
- Link to the Getting Started guide, which should have tested
installation methods for many platform/python combinations:
https://www.pygame.org/wiki/
GettingStarted - Update instructions that tell people to install from the outdated bitbucket repository (we moved to github).
I've been updating the pygame website itself to follow this advice in parts where it wasn't current.
Also soon, the bitbucket repo setup.py will get a message added to it:
- telling people we have moved to github,
- to see https://www.pygame.org/wiki/
GettingStarted for updated instructions.
In the coming months I'll make that bitbucket repo error, with the same instructions.
Additionally, I'll add a message on compile failure to link to the relevant Compile* page.
Eg, if there's a failure on a Ubuntu machine it will link to the compile page for Ubuntu. https://www.pygame.org/wiki/
For
all the compile pages, they will be updated to add the versions they
were confirmed working (luckily, this info is sort of stored in the wiki
version history). Old versions of Ubuntu require different compilation
advice to the latest Ubuntu versions. Latest
version instructions will be up the top of the page, and old versions
underneath. I'll also gather links from around the internet, because
sometimes better compilation instructions are listed on peoples blog
posts than in the wiki. All the Compile pages are listed here: https://www.pygame.org/wiki/
Python 3.7.0b1
Some python 3.7.0b1 issues were fixed, and I got it working on Travis CI with linux. There is still work to try it out on Windows, and Mac, and to make binary wheels for for all the platforms.Are we PyPy yet?
It seems various people have been working on making the PyPy CPython C API handling improve a lot. As well as fixing issues here and there with pygame when compiled with pypy.Wow. Many thanks to all the people working on that.
Now it's at a stage where a bunch of things actually work. Not enough to play a game on it... but getting much closer.
Learning this good news... I got PyPy building on Travis CI/pygame/pygame (with some tests still failing). Then started a milestone for "Are we PyPy yet?". Stuart Axon has already filed one issue, and asked PyPy developers for help on how to fix it. Stuart wasn't joking saying PyPy devs are super helpful.
This one particular issue has to do with surface locking and reference counting. In CPython when you do "del array" it does what you think... and deletes the array right then and there. However, PyPy has a different type of memory management, and PyPy will decide when to delete things thank you very much!
Like with files in python, it was suggested we gain a method like '.close()' to explicitly deal with these locks. Instead of relying on reference counting semantics. Also, to use a context manager for with.
PixelArray is using Surface locks. It does this so if your Surface is graphics hardware memory underneath your operating system won't crash on you (I hope).
 |
| Leave the pixels alone!!!! What did they ever do to you?!? |
Next up is to start filing pygame issues for each of the test failures and then slowly fixing them. Some of them should be fairly easy, and others are downright scary (BufferProxy and no ctypes.pythonapi on PyPy makes me afraid... very afraid).
Then we have to figure out how to build binary wheels for the various platforms, and probably many other things... All PyPy related work will be tracked on the Are we PyPy yet? milestone in the pygame issue tracker. Not sure how long this work will take, so this won't be included in the upcoming 1.9.4 release I don't think.
The mysteriously weird 'moiré pattern'.
I was clicking-about on stack overflow and came across this weird thing in popular question there. This strange thing happens when drawing thick circles with pygame.draw. |
| Before: moiré pattern sort of looks nice |
 |
| After: just a boring filled bit of red. Nothing interesting. Move along. |
I love Pulseaudio. And sarcasm.
I have much respect for the pulseaudio developers... linux audio is hard work.There's a couple of issues with sound and pygame on linux with the 'manylinux' binary wheels we have. It took me some time to track the causes down, and find ways to reproduce the issues.
TLDR; midi music is broken with pygame installed by wheels.
One has to do with arch linux using a different configuration directory to every other linux of the last 20 years for timidity. And also to do with how we are not installing special config files on random parts of the linux file systems when people install the wheel with pip.
So, there are a few different software music synthesizers included with pygame. One is timidity (linked above) and the other is fluidsynth. The soundfont playing synth.
"Had enough with linux audio issues for today. I've got a sneaking
feeling that pulseaudio and fluidsynth are to blame somehow for high cpu
on linux systems when installing from pip wheels. https://github.com/pygame/pygame/issues/331#issuecomment-365177184"
So, I just sort of paused at that point. I guess we need to disable timidity (or patch it for arch linux), and for the case when timidity isn't installed. Also, we need to handle soundfonts... either provide a message to the user if they are missing, or see if there are some FLOSS-happy ones we can distribute just on linux.
ps. During these investigations, I found out that fluidsynth has been saved from sourceforge and has had a whole bunch of releases. Awesome. http://www.fluidsynth.org/
Updating old links again...
Another pleasant delight whilst searching-around-the-interwebs... I found a patch logged against an old mirror of the bitbucket repo on github. This had a few really good documentation updates, and an addition of a 'pitch_bend' method... which allows you to do pitch bends, as the name suggests. Luckily @endolith (a hardcore Electronics and DSP engineer doing interesting stuff) made a new PR, and so those improvements will finally make it out into the world. Somehow I overlooked it on bitbucket too.Additionally, a couple of new issues were filed against out bitbucket repo... which I haven't closed down yet(because reasons). They are for a couple of SRC_ALPHA regressions it seems. I'll add them into github soon, and also then to the list of blockers for a 1.9.4 release.
1.9.4 release planning.
"About time for another release I guess?"
About 5 days ago I asked the mailing list if we could do a release, and that I intended to do a release. To give people time to mention issues, do testing, and let me know if they are still working on things to release that we should wait for.
Which is nice because people let me know about various issues they'd liked fixed and pointed me to the details (including the SRC_ALPHA issues above). I started looking around for things to merge in, looking at other bug trackers (like the Debian one).
Then, I started a checklist of things to do for a pygame release, and also started filing issues with the correct labels and using a milestone. https://github.com/pygame/
I want to get this work out so I can start merging in SDL2 stuff into the master branch. That's what I'm really looking forward to.
A new place to idle the day away chat.
We have a pygame discord server for anyone who wants to chat about pygame projects.
Feels like progress.
Every time I look at that bug list it gets bigger! Schrödinger has a lot to answer for.
 |
| Stop messing about on your phone and get to work! |
Comments
I would love to see more tutorials that focus on building an actual game, so newbies (like myself) can learn not the specifics (why do I need to move a pixel?) but the videogame, language agnostic specific knowledge (and how to implement it with pygame).
With pygame.sprite, you can use the collision functions to see which of the sprites the mouse collides with. Make the mouse a sprite, with the MouseSprite.rect the mouse event position. Then you can collide with it fairly easily.
However, I'm not sure that's something that can be done in the mouse event. The mouse events are a one way flow of data from the mouse. They don't know about anything else in the world - just mouse things. For that there would need to be some be some link up between the mouse(mice) and things on the screen(s).
"What mouse is hovering over" would be done a layer up, in some sort of game framework, or gui library.
สมัคร สล็อต