Re: [pygame] how to sign up?

[Thomas Kluyver]

I think it was disabled at some point because of excessive spam, and then
no-one has found a better solution, so it remained disabled.

On Wed, 6 Apr 2022 at 11:31, Rick van der Meiden 
wrote:

> I've had problems signing up for pygame.org too. When I tried to
> register, it said: "registration disabled. If your email account already
> exists, you may need to confirm your account first.". Thinking that maybe I
> did register already, but forgot about it, I tried confirming it, and I
> also tried recovering the password, but in both cases the website tells me
> the user doesn't exist. So I gave up, thinking it must be broken.
>
> On Tue, 5 Apr 2022 at 15:41, Leif Theden  wrote:
>
>> if you are talking about the website pygame.org, signup should be here
>> https://www.pygame.org/register
>> you are also invited to join the community discord witch is the
>> unofficial server for pygame https://discord.gg/cNSnd8Jf
>>
>> On Tue, Apr 5, 2022 at 8:17 AM kueden lego  wrote:
>>
>>> I am new to pygame and tried (like many others) to sign up. It just does
>>> not work. I see that there were post on this in the past, but I could not
>>> identify any help.
>>> Any advice would be welcome.
>>>
>>
>
> --
> e-mail: rickvandermei...@gmail.com
>
>

Re: [pygame] Pygame causes ALSA underrun

[Thomas Kluyver]

The docs for pygame.mixer.init() have this info, which seems relevant:

> The buffer argument controls the number of internal samples used in the
sound mixer. The default value should work for most cases. It can be
lowered to reduce latency, but sound dropout may occur. It can be raised to
larger values to ensure playback never skips, but it will impose latency on
sound playback. The buffer size must be a power of two (if not it is
rounded up to the next nearest power of 2).

http://www.pygame.org/docs/ref/mixer.html#pygame.mixer.init

This is the argument you're setting to 512 (also the default). If I've
understood correctly, it needs to prepare new data every 512 / 22050
seconds, or about 40 times per second.

Thomas

On Thu, 26 Aug 2021 at 08:21, David Scheele 
wrote:

> Hi there, new to the mailing list.
> I'm currently misusing pygame and its mixer to create a raspberry pi
> script that can switch between different music playlists and play sfx on
> command, all without any graphics.
> So far it worked perfectly but now, in reach of the finish line, I came
> across errors like this:
>
> ALSA lib pcm.c:8306:(snd_pcm_recover) underrun occurred
>
> I'm not even sure what this means. But it really hurts the audio playback.
> I play my music over pygame.mixer.Channel(0) and (1). I know that's not the
> usual way to do it but I have my reasons for using it.
>
> I init my mixer with
> pygame.mixer.pre_init(22050, -16, 2, 512)
>
> I would like to put everything I can into getting the audio right as it is
> literally the only thing that matters in this project. Does anyone have any
> pointers what steps I could try?
>
> Thanks!
> David
>

Re: [pygame] broken links

[Thomas Kluyver]

I think René runs the website, along with many other things. He'll
certainly see messages here. The website is also open source if you want to
submit pull requests:

https://github.com/pygame/pygameweb/
https://github.com/pygame/pygame/tree/main/docs

Some parts, like the wiki and the 'recent releases' list are managed
directly on the server, rather than coming from a Github repository.

Thomas

On Tue, 27 Apr 2021 at 20:12, Jeff Mitchell 
wrote:

> There are many broken links on the pygame website, mainly for projects but
> there's also a broken link on the tutorial page. Where can I email the
> website's administrator?
>

Re: [pygame] Update Python 2.7 project to work with Python 3

[Thomas Kluyver]

You can try the 2to3 command line tool included as part of Python:
https://docs.python.org/3/library/2to3.html

This can quickly and reliably do the simple, repetitive work like changing
'print x' to 'print(x)' for Python 3. But you'll probably still need to
spend a while manually debugging the code on Python 3, because not
everything can easily be fixed by an automatic tool.

Thomas

On Tue, 27 Apr 2021 at 07:25, Jeff Mitchell 
wrote:

> Is there an easy way to update an old project (
> https://sourceforge.net/projects/twodracing/) to work with the latest
> Python/Pygame? I'd like to get this 2D driving simulator to run.
>

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

[Thomas Kluyver]

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 <https://github.com/dlon>) | René Dudfield (@illume
> <https://github.com/illume>) | Charles (@charlesej
> <https://github.com/charlesej>) | Dan Lawrence (@MyreMylar
> <https://github.com/MyreMylar>) | Ankith (@ankith26
> <https://github.com/ankith26>, Niels Thykier (@nthykier
> <https://github.com/nthykier>) | Lenard Lindstrom (@llindstrom
> <https://github.com/llindstrom>) | Sigurður Sveinn Halldórsson (@siggisv
> <https://github.com/siggisv>) | @robertpfeiffer
> <https://github.com/robertpfeiffer> | Josip Komljenović (@MightyJosip
> <https://github.com/MightyJosip>) | Travis Chang (@Reminisque
> <https://github.com/Reminisque>) | xFly_Dragon @husano896
> <https://github.com/husano896>, Adam Andrews (@adamandrews1
> <https://github.com/adamandrews1>) | (@galexandreg
> <https://github.com/galexandreg>) | Thiago Jobson (@thiagojobson
> <https://github.com/thiagojobson>) | (@mcpalmer1980
> <https://github.com/mcpalmer1980>) | @charlesoblack
> <https://github.com/charlesoblack>, Daniel Pope @lordmauve
> <https://github.com/lordmauve>, Thomas Kluyver (@takluyver
> <https://github.com/takluyver>) | (@e1000 <https://github.com/e1000>) |
> Andy Nguyen (@anguye13 <https://github.com/anguye13>) | (@Starbuck5
> <https://github.com/Starbuck5>) | Ian Mallett @imallett
> <https://github.com/imallett>
>
> Equally important thank you go out to all the other contributors, some of
> which contributed to a community project for the first time.
>
> Pedro de la Peña @pedrodelapena <https://github.com/pedrodelapena> |
> @lkito <https://github.com/lkito> | @khuang0312
> <https://github.com/khuang0312> | @tsadama <https://github.com/tsadama> |
> (@Bottersnike <https://github.com/Bottersnike>) | (@alphaCTzo7G
> <https://github.com/alphaCTzo7G>) | Amos Bastian (@amosbastian
> <https://github.com/amosbastian>) | Andrey Lopukhov (@andreyx86
> <https://github.com/andreyx86>) | Augusto Noronha (@augusto2112
> <https://github.com/augusto2112>) | Bernardo Sulzbach (@bernardosulzbach
> <https://github.com/bernardosulzbach>) | (@Bottersnike
> <https://github.com/Bottersnike>) | Cai Q.T. (@CAIQT
> <https://github.com/CAIQT>) | (@Cerealdragon) | (@ChrisWeissNike
> <https://github.com/ChrisWeissNike>) | (@cmtrapp02
> <https://github.com/cmtrapp02>) | Daniel Molina (@daniel-molina
> <https://github.com/daniel-molina>) | David Caughell (@DavidCaughell) | (
> @dr0id <https://github.com/dr0id>) | burmer (@dtschirmer
> <https://github.com/dtschirmer>) | (@IchMageBaume
> <https://github.com/IchMageBaume>) | (@LambdaGoblin
> <https://github.com/LambdaGoblin>) | François Magimel (@Linkid
> <https://github.com/Linkid>) | (@LiquidFenrir
> <https://github.com/LiquidFenrir>) | Mark Hurley (@markph0204
> <https://github.com/markph0204>) | Marius Gedminas (@mgedmin
> <https://github.com/mgedmin>) | (@metulburr <https://github.com/metulburr>)
> | Michael Farrell (@micolous <https://github.com/micolous>) | Dominik
> George (@Natureshadow <https://github.com/Natureshadow>) | Nik (@nikolas)
> | Nunu-Willump (@Nunu-Willump) | (@pleboulanger) | Rebecca Chen (@rchen152)
> | (@robertpfeiffer <https://github.com/robertpfeiffer>) | Sett (@sw00) |
> @seenemikk | Nguyễn Gia Phong (@McSinyx)| Sebastian Henz | @BastiHz | Alice
> Lia Stapleton (@slimelia)
>
> raphacosta27 (@raphacosta27) | Bill (@AdditionalPylons) | Gabriel Moreira
> (@gabsmoreira) | zoldalma999 (@zoldalma999) | amipy (@amipy) | DGMcKenney
> (@DGMcKenney) | Grigoris Tsopouridis ((@gtsopus)) | Ilia Gogotchuri
> (@Gogotchuri) | Jim Quach (@jiquach) | Aaron Li (@AaronLi) | Clark Seanor
> (@cruxicheiros) | K Duggan (@kduggan15) | Michał Górny (@mgorny) | Clark
> Seanor (@cruxicheiros) | jtoloff (@jtoloff) | 41aaronb (@41aaronb) |
> Prasanna Venkatesh (@hanzohasashi33) | zoldalma999 (@zoldalma999) | Nihal
> Mittal (@codescientist703) | leopoldwe (@leopoldwe) | Scott Noyes (@snoyes)
>
> Vicente González Ruiz (@vicente-gonzalez-ruiz)| Douglas (@douglas-cpp) |
> wuzh07 (@wuzh07) | Gerardo Antonio Hagad (@ginohagad) | Evan Kanter
> (@evank28) | Inada Naoki (@methane) | Jani Tiainen (@jtiaicomparison) |
> Christian Clauss (@cclauss) | Gosha Zacharov (@Gosha) | Steven Chua
> (@Graphcalibur) | K Dugg

Re: [pygame] Python/pygame version compatibility

[Thomas Kluyver]

Hi Irv,

If I recall correctly, the issue was that there aren't pre-built wheels for
pygame with Python 3.8 - looking at the PyPI files (
https://pypi.org/project/pygame/#files ), it's only built for Windows at
the moment. So it's not incompatible, but it's more complicated to install
it on Linux & Mac than if you use Python 3.7.

>From what you say, a setup that you know works is probably preferable to
using the latest Python version.

Best wishes,
Thomas

On Tue, 24 Mar 2020 at 04:59, Irv Kalb  wrote:

> I teach Python classes (now live online!)
>
> I'm getting to the point in my course where I use Pygame, and I want to
> encourage my students to download and use it for projects.
>
> I have not upgraded my personal setup for a while.  I am using Python
> 3.7.3 with Pygame 1.9.6 on a Mac, and everything is working very well.
>
> But I've read here that Python 3.8 doesn't, or at least didn't, work with
> the current version of Pygame.  Is this still true?  Would it be best to
> have my students use the same set up as me with Python 3.7.x  ?   If not,
> what are the proper versions to use?
>
> These are beginner students (mostly art students) - it is a stretch to
> even get them to use pip.
>
> Thanks,
>
> Irv

Re: [pygame] pygame install error with python 3.8.0

[Thomas Kluyver]

The stable release of pygame (1.9.6) isn't built for Python 3.8, so pip
tries to build it from source, which fails. There are three options to work
around that:

1. Use Python 3.7 for now
2. Install a pre-release version of pygame 2, with "pip install --pre
pygame"
3. Get the necessary tools and libraries to build it from source - see
https://www.pygame.org/wiki/GettingStarted#Installing%20From%20Source .
This is probably quite a bit of work on Windows.

Thomas

On Fri, 8 Nov 2019 at 22:52, Suresh George  wrote:

> Hi,
>
> Greetings.
>
> I tried to install pygame, using pip install pygame, on my windows 10 running 
> python 3.8.0. But it fails with the following error messages
>
> Can you please help how to fix this issue and steps to follow for a 
> successful pygame installation on my PC.
>
>ERROR: Command errored out with exit status 1:
>  command: 
> 'c:\users\smuru02\appdata\local\programs\python\python38-32\python.exe' -c 
> 'import sys, setuptools, tokenize; sys.argv[0] = 
> '"'"'C:\\Users\\smuru02\\AppData\\Local\\Temp\\pip-install-0yqtpy1n\\pygame\\setup.py'"'"';
>  
> __file__='"'"'C:\\Users\\smuru02\\AppData\\Local\\Temp\\pip-install-0yqtpy1n\\pygame\\setup.py'"'"';f=getattr(tokenize,
>  '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', 
> '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' 
> egg_info --egg-base 
> 'C:\Users\smuru02\AppData\Local\Temp\pip-install-0yqtpy1n\pygame\pip-egg-info'
>  cwd: C:\Users\smuru02\AppData\Local\Temp\pip-install-0yqtpy1n\pygame\
> Complete output (17 lines):
>
>
> WARNING, No "Setup" File Exists, Running "buildconfig/config.py"
> Using WINDOWS configuration...
>
>
> Download prebuilts to "prebuilt_downloads" and copy to "./prebuilt-x86"? 
> [Y/n]Traceback (most recent call last):
>   File "", line 1, in 
>   File 
> "C:\Users\smuru02\AppData\Local\Temp\pip-install-0yqtpy1n\pygame\setup.py", 
> line 194, in 
> buildconfig.config.main(AUTO_CONFIG)
>   File 
> "C:\Users\smuru02\AppData\Local\Temp\pip-install-0yqtpy1n\pygame\buildconfig\config.py",
>  line 210, in main
> deps = CFG.main(**kwds)
>   File 
> "C:\Users\smuru02\AppData\Local\Temp\pip-install-0yqtpy1n\pygame\buildconfig\config_win.py",
>  line 576, in main
> and download_win_prebuilt.ask(**download_kwargs):
>   File 
> "C:\Users\smuru02\AppData\Local\Temp\pip-install-0yqtpy1n\pygame\buildconfig\download_win_prebuilt.py",
>  line 302, in ask
> reply = raw_input(
> EOFError: EOF when reading a line
> 
> ERROR: Command errored out with exit status 1: python setup.py egg_info Check 
> the logs for full command output.
>
>
>

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] Starting the pygame 2 series

[Thomas Kluyver]

On Mon, 5 Nov 2018 at 10:39, René Dudfield  wrote:

> 1.10 is a pretty nice color, however 1.10 sort of looks like 1.1
>

I know what you mean, but this is a very common pattern for software. I'm
using Gnome 3.28 on the Linux kernel version 4.17, and I could list many
more examples. It's well established that version numbers are not decimals.


> 1.9.5 looks pretty sharp in relation to 2, because it sort of looks like
> 1.95.
> Apart from the confusing part of .10 numbering, changing all the issue
> labels and such would be annoying.
>

At least on Github, this is easy - just rename the existing
labels/milestones. Maybe there are other systems in use where this would be
more of a pain, though.

Re: [pygame] Starting the pygame 2 series

[Thomas Kluyver]

On Mon, 5 Nov 2018 at 10:04, René Dudfield  wrote:

> Here's the milestone for pygame 1.9.5 (the refactor release).
> https://github.com/pygame/pygame/milestone/7
>
>> The 1.9.5 release is the 'refactor' release, with the SDL2 branch merged
>> and many cleanups. Being able to compile SDL2 support in is possible from
>> source, but there are known issues with it. Binaries (on pypi and
>> otherwise) should be distributed with SDL 1.2.
>>
>
Would it make sense to call this 1.10 instead of 1.9.5? To me, 1.9.x
suggests that there are just minor changes over the previous 1.9.x release,
and it sounds like this has pretty big changes.

Thomas

Re: [pygame] Community game project

[Thomas Kluyver]

It seems that this is an idea a lot of us like, in one form or another:
Marc-Alexandre's proposal is for something quite focused, my idea was much
more open-ended, and I think Nicholas was describing a model somewhere
inbetween. While we could eventually have multiple community games, let's
work on one thing at once, otherwise we'll probably end up doing none of
them.

Would anyone be interested in leading a project like this? Someone will
need to have an overview of what the project is, and motivate people to
contribute to it. I definitely can't commit the necessary time to do this.

Best wishes,
Thomas


On Thu, 23 Aug 2018 at 13:27, Marc-Alexandre Espiaut <
marc-alexandre.espi...@posteo.eu> wrote:

> Hello everyone,
>
> I’ve been forwarded the previous “About Pygame development” e-mails, so
> I’ve decided to join the mailing list to share my two cents about the
> “community game project” idea.
>
> I’m *all in favour* for it, and wish to participate. I think it could be
> a significant boost *if and only if* done well *and* “marketed” properly
> — there’s no use for a video game if no-one knows about it.
>
> It could also be a nice project to work on, but I think a few rules has to
> be drawn first in order to be successful:
>
> 1) The project should be time-limited. It’s too easy to loose motivation
> over time, so a short time span is preferable.
>
> 2) Tasks should be clearly defined. I’m a big advocate for methods like
> Agile or Scrum, therefore I think people who want to participate should
> know exactly what job they have to do — and what job they *don’t* have to
> do — and where they are going.
>
> 3) *Don’t think too big!* Game development is hard, and we should aim at
> reasonable goals.
>
> 4) *Don’t be ashamed to copy!* A lot of FLOSS video game fails because
> they try to be original, and they often ends-up being garbage. I won’t get
> into details to give you a precise example. 😉 Not everyone can be a good
> game designer. *There is no shame in cloning an already existing simple
> game* like *Tetris* or *Solitaire* as making a simple and enjoyable
> version of them is a big project already!
>
> Best regards,
>
> Marc-Alexandre
>

Re: [pygame] Re: About Pygame development

[Thomas Kluyver]

Thanks René,

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

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

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

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

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

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

Thomas

Re: [pygame] learning by contributing to FLOSS (and pygame in specific)

[Thomas Kluyver]

I know people have been running sprints on open source projects in London
with the intention of making them a regular thing. If you're not already in
touch with them, I could dig out the emails I remember and connect you.

On 18 July 2018 at 09:51, René Dudfield  wrote:

> Hello,
>
> I'm looking for a small group of 10-30 people who are interested in
> contributing to the pygame project as part of a class or user group meeting.
>
> Rather than a normal user group meeting or class, it could be: "contribute
> to an open source project".
>
> Be in touch!? Let's do it! :)
>
>
> *Why?* (teaching by helping people contribute to FLOSS projects.)
> Because you don't learn karate from a book.
> Builds social connections and skills.
> Portfolio, and evidence of talent.
> Sort of fun and different compared to a talks night at a user group.
>
> *Why pygame?* (rather than some other project)
> Because I want to do this with my pet project.
> It's sort of fun compared to some topics (better than watching paint dry
> at least).
> Because it's sort of well known project (millions of users).
> ... with almost zero full time or even part time developers (that's why
> it's called pygame zero).
> Because I will help before and during the class(es)/session(s), and have
> resources and issues prepared.
>   *[hey! you could totally do this with your own pet projects too!]*
>
>
> *How will a gathering work?*
>
> *The goal*: At the end of the gathering, people will have learned how a
> FLOSS project is done, submitted a PR, and have a big thank you posted on
> the website.
>
> A session could run like this:
>
>1. A short lightning talk can be done on what's happening by someone
>on how to write a unit test, and what is a github issue (slides can be made
>available).
>2. A number of topics will be presented to choose from. These will be
>'low hanging fruit' issues. Like, "write a test for a draw rectangle
>functions".
>3. People will split off into small groups of 2-4 people. Each
>choosing an issue. Probably beginners and experts will be mixed together.
>4. Project developers will be available via web chat (Discord) (or in
>person perhaps if it's where the developers live...).
>5. results will be pasted into issues, and perhaps even pull requests
>made.
>6. At the end one person from each group will show off what they've
>done and experienced to the group. (several short talks)
>
> [Hrmm... you may be thinking that this sort of sounds exactly like a Dojo
> (shout out to London Python Dojo) or mini conference sprint format(shout
> out to pypy!). Yop.)
>
> If anyone wants to do this with me please be in touch to get this going! I
> will announce when it's happening so people can drop by online too if they
> want.
>
>
>
> cheers,
>

Re: [pygame] pygame 1.9.4 released

[Thomas Kluyver]

Congratulations on the release, and thanks for putting in the work to get
it out! :-)

On 19 July 2018 at 11:40, René Dudfield  wrote:

> [image: pygame 1.9.4] <https://www.pygame.org/wiki/about>
> pygame 1.9.4 has been released into the wild!
> TLDR; Some highlights.
>
>- python 3.7 support.
>- beta pypy <https://www.pypy.org/> support. See Are we pypy yet?
>
> <https://github.com/pygame/pygame/issues?q=is%3Aopen+is%3Aissue+milestone%3Apypy>
>.
>- pygame.draw fixes
>- pygame.math is not experimental anymore. Speedups and bugfixes.
>- Debian, Mac homebrew, mac virtualenv, manylinux and other platform
>fixes.
>- documentation fixes, jedi support for type ahead in editors like
>VSCode and VIM.
>- Surface.blits for blitting many surfaces at once more quickly.
>
> Thanks A very special thanks to the people who have volunteered commits
> to pygame since the last release. In alphabetical order...
> Adam Di Carlo (@adicarlo <https://github.com/adicarlo>) | Christian
> Bender (@christianbender <https://github.com/christianbender>) | Don
> Kirkby (@donkirkby <https://github.com/donkirkby>) | endolith (@endolith
> <https://github.com/endolith>) | hjpotter92 (@hjpotter92
> <https://github.com/hjpotter92>) | Ian Mallett (@imallett
> <https://github.com/imallett>) | Lenard Lindstrom (@llindstrom
> <https://github.com/llindstrom>) | Mathias Weber (@mweb
> <https://github.com/mweb>) | Matti Picus (@mattip
> <https://github.com/mattip>) | Nicholas Tollervey (@ntoll
> <https://github.com/ntoll>) | (@orangudan <https://github.com/orangudan>)
> | Raymon Skjørten Hansen (@raymonshansen
> <https://github.com/raymonshansen>) | René Dudfield (@illume
> <https://github.com/illume>) | Stefan Bethge (@kjyv
> <https://github.com/kjyv>) | Stuart Axon (@stuaxo
> <https://github.com/stuaxo>) | Thomas Kluyver (@takluyver
> <https://github.com/takluyver>) | Tobias Persson (@Anisa
> <https://github.com/Anisa>)
>
> I'm probably missing some people, and also missing some people who
> contributed in other ways.
> For example, in discussions, issue reports, helping out on the wiki, the
> website, and for helping others in the community, and providing good vibes.
> So whilst the commits are easy to use to make a list of people to thank,
> it's not inclusive of everyone who deserves thanks.
> More details. #451 <https://github.com/pygame/pygame/pull/451> #460
> <https://github.com/pygame/pygame/pull/460> #467
> <https://github.com/pygame/pygame/pull/467> #468
> <https://github.com/pygame/pygame/pull/468> #469
> <https://github.com/pygame/pygame/pull/469> #470
> <https://github.com/pygame/pygame/pull/470>
> #444 <https://github.com/pygame/pygame/pull/444> link to help pages when
> compile fails.
> #443 <https://github.com/pygame/pygame/pull/443> In set_error get_error
> tests ignore first error. Could be anything.
> #442 <https://github.com/pygame/pygame/pull/442> Freetype requires
> pkg-config instead of freetype-config now.
> #439 <https://github.com/pygame/pygame/pull/439> Surface.blits
> #435 <https://github.com/pygame/pygame/pull/435> Adding pypy builds for
> Mac on travis.
> #432 <https://github.com/pygame/pygame/pull/432> Appveyor pypy and pypy3
> windows 32bit.
> #431 <https://github.com/pygame/pygame/pull/431> Implement object alloc
> caching for rect.c to improve on pypy.
> #427 <https://github.com/pygame/pygame/pull/427> PixelArray.close(), with
> PixelArray(surf) as px, context manager.
> #426 <https://github.com/pygame/pygame/pull/426> Skip tests that rely on
> arrinter and pythonapi on pypy.
> #420 <https://github.com/pygame/pygame/pull/420> pypy didn't like
> tp_dictoffset hack in events. Make our own setter, getter.
> #418 <https://github.com/pygame/pygame/pull/418> draw.aaline should work
> with ARGB surfaces (like on mac).
> #416 <https://github.com/pygame/pygame/pull/416> Vector cleanup
> #415 <https://github.com/pygame/pygame/pull/415> So virtualenv gets a
> focused window on Mac too.
> #414 <https://github.com/pygame/pygame/pull/414> Mac Travis homebrew fix
> #413 <https://github.com/pygame/pygame/pull/413> Jedi confused by pygame
> imports. Make it happy.
> #408 <https://github.com/pygame/pygame/pull/408>
> pygame.transform.threshold tests, keyword arguments, docs.
> #403 <https://github.com/pygame/pygame/pull/403> pygame.math.Vector2/3
> not experimental
> #398 <https://github.com/pygame/pygame/pull/398> Clean up
> _camera_vidcapture.py unused code, and document 

Re: [pygame] unsubscribe pygame-users

[Thomas Kluyver]

Don't forget, the control email for the mailing list is majord...@seul.org
. Sending unsubscribe messages to the normal list address emails everyone
on the mailing list, and won't unsubscribe you.

More info at https://www.pygame.org/wiki/info

On 16 July 2018 at 07:48, DiliupG  wrote:

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

Re: [pygame] Looking for example game to package on Flathub

[Thomas Kluyver]

The game was accepted in Flathub, so you can now see it on the site here:
https://flathub.org/apps/details/com.inventwithpython.flippy

And the packaging information from the PR is now in its own repository:
https://github.com/flathub/com.inventwithpython.flippy

On 14 July 2018 at 08:41, René Dudfield  wrote:

> Cheers. I was reading through the PR change log thinking it would be quite
> easy to copy/paste :)
>
> Then I came across  in the appdata.xml, and wondered what to
> put there.
>
> Indeed, lots of reading! Seems much easier to copy/paste little examples.
>
>
>
>
> On Thu, Jul 12, 2018 at 1:20 PM, Thomas Kluyver  wrote:
>
>> Thanks René,
>>
>> There are docs on how to package applications with Flatpak:
>> http://docs.flatpak.org/en/latest/index.html
>>
>> And a wiki which describes the specific recommendations for distributing
>> applications on Flathub:
>> https://github.com/flathub/flathub/wiki/App-Submission
>>
>> However, the desktop file and appdata.xml are separate standards which
>> have their own documentation:
>> https://specifications.freedesktop.org/desktop-entry-spec/
>> desktop-entry-spec-latest.html
>> https://www.freedesktop.org/software/appstream/docs/index.html
>>
>> Needless to say, that's quite a bit of reading! This is a big part of why
>> I'm preparing this simple example. I hope people will use it as a template:
>> copy and paste the packaging info and modify it to fit their own games.
>>
>> I'm also working on an overview guide to the technologies you need for
>> desktop Linux applications, which should refer to a lot of these
>> technologies without going into the same detail as the specifications. And
>> I have some ideas about tooling to generate a flatpak manifest from pip
>> packages.
>>
>> Thomas
>>
>
>

Re: [pygame] Looking for example game to package on Flathub

[Thomas Kluyver]

Thanks René,

There are docs on how to package applications with Flatpak:
http://docs.flatpak.org/en/latest/index.html

And a wiki which describes the specific recommendations for distributing
applications on Flathub:
https://github.com/flathub/flathub/wiki/App-Submission

However, the desktop file and appdata.xml are separate standards which have
their own documentation:
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html
https://www.freedesktop.org/software/appstream/docs/index.html

Needless to say, that's quite a bit of reading! This is a big part of why
I'm preparing this simple example. I hope people will use it as a template:
copy and paste the packaging info and modify it to fit their own games.

I'm also working on an overview guide to the technologies you need for
desktop Linux applications, which should refer to a lot of these
technologies without going into the same detail as the specifications. And
I have some ideas about tooling to generate a flatpak manifest from pip
packages.

Thomas

Re: [pygame] Looking for example game to package on Flathub

[Thomas Kluyver]

Thanks Luke & Al,

I forgot to mention that I've prepared pygame at present for Python 3; it
wouldn't be hard to adapt that for Python 2, but I focused on Al's
collection of games, which already work with Python 3. I prepared a package
of 'Flippy', Al's clone of the classic board game Reversi. Here's the pull
request:

https://github.com/flathub/flathub/pull/478

You can see a few files involved:

- launch.py : Wrapper to launch the game
- com.inventwithpython.flippy.desktop : information for desktop
menus/launchers
- Icons in three different sizes
- com.inventwithpython.flippy.appdata.xml : information for software
catalogues
- com.inventwithpython.flippy.json : tells Flatpak how to assemble the
other files into an installable package

Best wishes,
Thomas


On 4 July 2018 at 21:51, Al Sweigart  wrote:

> I'll offer all the programs in the book Making Games with Python & Pygame:
> http://inventwithpython.com/pygame/
>
> The files can be downloaded from http://inventwithpython.
> com/makinggames.zip Email me if you have any questions.
>
> On Wed, Jul 4, 2018 at 11:37 AM, Luke Paireepinart  > wrote:
>
>> You're more than welcome to package up our game, solarflair, which was
>> part of pyweek 23, I believe. It's just python and pygame. I can take over
>> maintenance of the package as well, long term.
>>
>> On Wed, Jul 4, 2018, 12:16 PM Thomas Kluyver  wrote:
>>
>>> Hi all,
>>>
>>> My sporadic work on Flatpak packaging has taken another step forwards:
>>> namely, pygame 1.9.3 is now available as a 'shared module' for packagers to
>>> use on Flathub:
>>>
>>> https://github.com/flathub/shared-modules/
>>>
>>> I'd now like to try using this to package a real game, rather than the
>>> Aliens demo I usually test with. If you're interested, I'm offering to do
>>> (most of) the work to add your game to Flathub, making it a one-click
>>> install for users on the latest versions of Fedora/Ubuntu.
>>>
>>> https://flathub.org/apps/category/Game
>>>
>>> Specifically, I'm looking for a game that:
>>>
>>> - Runs on Linux
>>> - Is open source
>>> - Is a real, playable game, not a tech demo. It doesn't have to be long
>>> or professional, but you should be able to have fun playing it, even if
>>> only for 10 minutes.
>>> - Uses pygame [1]
>>> - Any other dependencies are pure Python and easy to install
>>> - You, the author, are interested in the process, and willing to take
>>> over the (probably minimal) maintenance once it's packaged.
>>>
>>> Some of the pyweek entries I've seen would be a good fit for this, for
>>> instance.
>>>
>>> If you're interested, please get in touch! :-)
>>>
>>> Thanks,
>>> Thomas
>>>
>>> [1] I'm happy to give pointers on packaging things that don't use
>>> pygame, but as I've spent time figuring out how to use pygame with Flatpak,
>>> I want to focus on an example that does.
>>>
>>
>

[pygame] Looking for example game to package on Flathub

[Thomas Kluyver]

Hi all,

My sporadic work on Flatpak packaging has taken another step forwards:
namely, pygame 1.9.3 is now available as a 'shared module' for packagers to
use on Flathub:

https://github.com/flathub/shared-modules/

I'd now like to try using this to package a real game, rather than the
Aliens demo I usually test with. If you're interested, I'm offering to do
(most of) the work to add your game to Flathub, making it a one-click
install for users on the latest versions of Fedora/Ubuntu.

https://flathub.org/apps/category/Game

Specifically, I'm looking for a game that:

- Runs on Linux
- Is open source
- Is a real, playable game, not a tech demo. It doesn't have to be long or
professional, but you should be able to have fun playing it, even if only
for 10 minutes.
- Uses pygame [1]
- Any other dependencies are pure Python and easy to install
- You, the author, are interested in the process, and willing to take over
the (probably minimal) maintenance once it's packaged.

Some of the pyweek entries I've seen would be a good fit for this, for
instance.

If you're interested, please get in touch! :-)

Thanks,
Thomas

[1] I'm happy to give pointers on packaging things that don't use pygame,
but as I've spent time figuring out how to use pygame with Flatpak, I want
to focus on an example that does.

Re: [pygame] Can't install pygame on Windows. Please help!

[Thomas Kluyver]

There aren't precompiled packages for Python 3.7 yet, so it tries to
install from source. The easiest option is to keep using Python 3.6 for now.

If you do want to try to install from source for Python 3.7, see:
https://www.pygame.org/wiki/CompileWindows

On 1 July 2018 at 21:08, Ian Mallett  wrote:

> On Sun, Jul 1, 2018 at 11:18 AM, John Salerno  wrote:
>
>> Hi all. I just tried installing pygame on my Windows system using the
>> following on the command line:
>>
>> python -m pip install --user pygame
>>
>> but it seems to have failed.
>>
>
> ​I can reproduce this. I suspect it's a bug; Python 3.7.0 came out just
> four days ago. Perhaps try Python 3.6 for now?​
>

Re: [pygame] Cheap COW clones for surfaces

[Thomas Kluyver]

Even for responsible adults, it's valuable to build abstractions that give
you the results you expect when you do the obvious thing. The 'responsible
adults' principle means we can say "you can modify this private attribute
if you know what you're doing". It doesn't mean that you can expect
everyone to read the docs to find out how to use it right.

On 18 June 2018 at 12:17, Daniel Pope  wrote:

> Pygame Zero programmers are not necessarily responsible or adults. Overall
> that idea would break several of our documented principles:
>
> http://pygame-zero.readthedocs.io/en/stable/principles.html
>
>
> On Mon, 18 Jun 2018, 11:09 Radomir Dopieralski, 
> wrote:
>
>> You can't prevent it, but you can explain in the documentation that it
>> is discouraged and what happens when they do it. Python programmers are
>> responsible adults after all, no?
>>
>> Otherwise you start writing Java in Python...
>>
>> On Mon, 18 Jun 2018 10:24:25 +0100
>> Daniel Pope  wrote:
>>
>> > The drawing thread should handle all blits to the screen as well as
>> > flip. But in a framework we cannot prevent users creating surfaces
>> > and mutating them in the logic thread.
>> >
>> > On Mon, 18 Jun 2018, 09:55 Radomir Dopieralski, 
>> > wrote:
>> >
>> > > Them again, if you assume that the drawing thread is doing all the
>> > > blits, then the situation is reversed — it's the only thread that
>> > > needs write access to the surfaces, and everything is good again.
>> > > In your scenario, we still get the correct result, because all the
>> > > blits are executed by the drawing thread in the same order in which
>> > > they were scheduled — including the blits that modify your
>> > > temporary surface with the digits. As long as all the modifications
>> > > happen either on one side or the other, we are good.
>> > >
>> > > On Mon, 18 Jun 2018 01:09:16 +0200
>> > > Radomir Dopieralski  wrote:
>> > >
>> > > > Oh, I think I misunderstood what the drawing thread was supposed
>> > > > to do. I thought it would only handle the "flip" and/or "update"
>> > > > calls, that is, sending the pixel data of the screen surface to
>> > > > the graphic cards, which is the slowest part of any pygame
>> > > > program. But from what you write, I understand it's supposed to
>> > > > handle all blits as well?
>> > > >
>> > > > On Sun, 17 Jun 2018 17:33:54 -0500
>> > > > Luke Paireepinart  wrote:
>> > > >
>> > > > > Radomir, there is another side effect - if the surfaces are not
>> > > > > copied, then whatever content was in surf a at the moment that
>> > > > > it was supposed to be drawn now no longer exists. For example,
>> > > > > say the logic thread is font rendering the numbers 1 thru 9,
>> > > > > and then blitting these to positions that are not overlapping
>> > > > > each other, but it is reusing a surface for the font render
>> > > > > call. In the synchronous example, 1, 2, 3, etc would be drawn.
>> > > > > Make that asynchronous and you could end up with 9,9,9,9,9
>> > > > >
>> > > > > If you are multithreading a game, the "main" thread should be
>> > > > > mutating the game state, not the surfaces directly. The render
>> > > > > thread should be the view of the model state at the snapshot in
>> > > > > time at which the render is called. The logic thread should
>> > > > > have a control that is determining the time between updates and
>> > > > > applying the appropriate amount of ticks to the game state /
>> > > > > emulating physics / etc. Then whenever the previous draw has
>> > > > > completed, the render thread would snapshot the state and
>> > > > > represent it appropriately (either redrawing or comparing to
>> > > > > its previous state). If there needs to be multiple draw calls
>> > > > > to represent the state properly since the last state, then they
>> > > > > can all be done before the display buffer is flipped.
>> > > > >
>> > > > > In the 1-9 example, each font would be represented by a game
>> > > > > object that had a positional element, and you could add them to
>> > > > > the map asynchronous of the draws since the render thread would
>> > > > > display them on the next iteration of the render loop where
>> > > > > they existed.
>> > > > >
>> > > > >
>> > > > > On Sun, Jun 17, 2018, 3:49 PM Radomir Dopieralski
>> > > > >  wrote:
>> > > > >
>> > > > > > Of course strictly speaking there is a difference in behavior,
>> > > > > > however, from the practical point of view, the difference
>> > > > > > boils down to the fact that something gets drawn half a frame
>> > > > > > earlier rather than half a frame later (because the command
>> > > > > > to draw it was given in between the frames). Unless you have
>> > > > > > less than 6 frames a second, the difference wouldn't be easy
>> > > > > > to notice, especially since it would be rather rare too,
>> > > > > > since you would need to get very specific timings to even
>> > > > > > have it happen. I wonder if it's worth the effort.
>> > > > > >
>> > > > > > On Sun, 17 Jun 2018 21:40:

Re: [pygame] Documenting the pygame C API and making the API consistent

[Thomas Kluyver]

I'm not really familiar with C APIs, but I thought that the 0/-1
inconsistency was necessary because 0 may be a valid return value in some
contexts, and there is no -1 if you're using a unsigned integer type.
Looking quickly at the Python docs, the pattern seems to be that functions
returning a pointer return NULL on error, and the rest use -1 to indicate
an error - though I don't know if that's always followed.

I would think that API changes don't belong in a 1.9.x release, but that's
not my decision. :-)

On 15 June 2018 at 23:45, Lenard Lindstrom  wrote:

> Hi everyone,
>
> A part of the preparation for pygame 2 I have documented the functions and
> types exported by various pygame extension modules. For instance, the
> pygame.surface module exports C functions for creating and accessing
> pygame.Surface instances. These are used in other modules, such as
> pygame.display and pygame.image, where surfaces are created. In total,
> twelve extension modules make C functions available for use in other
> extension modules.
>
> While documenting the C API I renamed C types, functions, and variables to
> be consistent with Python's PEP 7. Names starting with 'Py' and 'Pg' were
> changed to use the 'pg' prefix. This avoids conflicts with possible future
> Python C functions as well as make the pygame naming convention consistent.
> I have also found other inconsistencies in the pygame C API. Functions that
> return a Python object are consistent in returning NULL to indicate an
> error. However, for functions that return an error code, some may use -1 to
> indicate an error, while others use 0. Should I make an effort to make
> pygame error handling consistent within the C API? Would it make sense to
> do this before pygame 1.9.4 is released, or wait until pygame 2? Python is
> not much help since it has mixed error codes within its C API.
>
> Lenard Lindstrom
>
>
>

Re: [pygame] pygame awesome libraries?

[Thomas Kluyver]

On 13 May 2018 at 22:50, René Dudfield  wrote:

> (The benefit of python hosted over read the docs, is they don't inflict
> advertising on your users like read the docs does.)
>

RTD provides a valuable service for free - it builds docs automatically as
well, whereas pythonhosted only hosts docs you build. That's really
convenient for a lot of projects. They show some ads, but it's very
different from most online advertising - it's much more like traditional
non-digital advertising, without the tracking and security issues. There's
more about this here:

http://docs.readthedocs.io/en/latest/ethical-advertising.html

Of course, you may still not like adverts of any kind. I find it reasonable
that RTD shows some unobtrusive advertising, and I hope their experiment
with non-tracking advertising can be successful enough to convince other
ad-supported services that it's viable.

Thomas

Re: [pygame] pygame awesome libraries?

[Thomas Kluyver]

Hi DR0ID, I'll respond to a few of your questions where I feel I might have
useful info.

On 7 May 2018 at 21:06, DR0ID  wrote:

> [2] Any tips on (free) CI builds?
>

Linux: Travis CI & Circle CI
Mac: Travis CI
Windows: Appveyor

All these services are free for open source projects, and they can all be
configured via files in the repository you want to test, so you can see the
config other projects use. Travis only works for projects on Github, though.


> [3] Any tips on packaging for pip?
>

The standard guide is here:
https://packaging.python.org/tutorials/distributing-packages/


> [4] Any tips for the documentation?
>

A lot of Python projects use Sphinx and host docs on readthedocs.org (which
can watch your repository and rebuild docs automatically). Sphinx is a
relatively big system with a bit of a learning curve, but if you use it
well, you get nice features like cross-linking references to classes and
functions. A lighter-weight alternative that some projects prefer is to
write some markdown files. Mkdocs is a tool built for that workflow, but
you can also just point people to the markdown files on Github/Bitbucket.


> [5] Would you break up libs into smaller, maybe partial parts that are pip
> installable so they can be installed independently? If so, should each have
> its own repo or not (keeping it in the same repo in sub directories)?
>

It's a trade off - some people won't like installing a 'heavy' library if
they only want to use one part, but splitting it up means more maintenance
work to deal with the separate pieces. Don't split too small!


> [8] One thing that has bothered me along time and I have not found any
> good answer yet is following: pip installable packages are good for
> developers while coding and developing. But then, when I want to 'ship' or
> 'distribute' some program I'm not so sure that is the way to go. Because I
> think there should be a distinction between a library (that you install in
> site-packages) and a 'executable' which I might want to install somewhere
> else (otherwise I would not know hot to run it, maybe using '-m'?)
>
> Yep, applications are definitely different from libraries, although if
you're aiming at developers, you can often get away with using
library-style packaging for applications, and launching them with '-m'.

Application distribution is a weakness for Python. Pyinstaller is the tool
that's usually recommended, but it doesn't see as much love as the library
packaging tools. I'll also plug my own tool, Pynsist, which builds
installers for Windows rather than 'freezing' your application into an
executable.

Thomas

Re: [pygame] unsubscribe pygame-users

[Thomas Kluyver]

You had the right text ("unsubscribe pygame-users"), but you need to send
it to: majord...@seul.org

On 22 April 2018 at 18:35, Jorge Maldonado Ventura  wrote:

> Cloudflare blocks Tor users so I can't access the link, can you paste
> the instructions here?
>
>
> El 21.04.2018 a las 14:43, Thomas Kluyver escribió:
> > Sending this to the list doesn't work - there's a a separate address
> > for control messages. See:
> >
> > https://www.pygame.org/wiki/info
>
>

Re: [pygame] unsubscribe pygame-users

[Thomas Kluyver]

Sending this to the list doesn't work - there's a a separate address for
control messages. See:

https://www.pygame.org/wiki/info

Re: [pygame] Error pygame with timidity.cfg

[Thomas Kluyver]

I think it's a problem with the way we've packaged pygame. If I'm right,
you'll need to install it another way - either:

1. Get the source code of pygame (https://github.com/pygame/pygame ), make
sure you have all the dependencies installed, and compile it yourself.
2. Or use a platform package manager (like apt or dnf) to install it.

On 21 April 2018 at 13:10,  wrote:

> I apologize if I expressed myself badly. however I repeat that timidity
> works well. The problem comes to me with pykaraoke that uses the pygame
> module. Just pygame has a syntax error when it goes to read this file:
> timidity.cfg, line 30. But, as explained here ->, the syntax is the one I
> used, that is only "soundfont filename". In fact I read the .midi quietly
> with timidity. I do not know what's wrong with pygame ..

Re: [pygame] Error pygame with timidity.cfg

[Thomas Kluyver]

Let's remember that pygame is used by new programmers who don't necessarily
know how or where to best ask questions. Providing guidance is great, but
let's keep the tone friendly. Don't forget that written messages tend to
sound grumpier/snarkier than you meant them to, so
it's easy for everyone to quickly get angry.

Teodoro, you're getting terse responses because you turned up to get help
with a problem, without any evidence that you had investigated it or tried
to understand the cause. If you've checked that timidity works outside
pygame, mention that up front. Did you put the error message into Google as
well? People will be happier to help if you show that you're trying to
figure it out yourself. And your second message comes across as a bit
demanding - no-one here has to help you.

Back to the problem itself: what platform are you on, and how did you
install pygame? There are some problems using timidity with the Linux
wheels, because the bundled copy of the timidity library uses a config file
found on your system, and this might be for a different version of timidity:
https://github.com/pygame/pygame/issues/343

If it's that kind of problem, then the workaround is to either install from
source, or get a (possibly older) version of pygame from your system
package manager (apt/dnf/...). There are more installation instructions
here:
https://www.pygame.org/wiki/GettingStarted#Installing%20From%20Source

On 21 April 2018 at 08:38, Martin Kühne  wrote:

> Neither timidity nor any of its configuration is parsed or otherwise
> referenced by the pygame source. Please justify what your need is
> here.
>
> cheers!
> mar77i
>

Re: [pygame] pygame awesome libraries?

[Thomas Kluyver]

If I'm allowed to shamelessly plug my own package...

Pynsist is a tool for building Windows installers for Python applications.
Here's an example for pygame (using the 'aliens' example game):
https://github.com/takluyver/pynsist/tree/master/examples/pygame

On 5 April 2018 at 12:11, René Dudfield  wrote:

> What are some awesome libraries for pygame?
>
>- available via pip
>- documented (with examples, and API docs)
>- generally awesome for some reason (even if not perfect, maybe it has
>potential)
>
> I'll start with a few...
>
>- pyscroll . Scrolling maps. Fast
>scrolling images easy.
>- pyTMX . Reads Tiled Map Editors
>TMX maps. Can use a Map editor easily.
>- pyinstaller . Make installers for
>different platforms. Very easy to use to make installers.
>- pymunk . 2d physics library. Lots
>of examples, very well maintained.
>
>
>
> What's awesome or almost awesome?
>
>
>
> ps. I also asked over on the reddit.
> https://www.reddit.com/r/pygame/comments/89ygm7/pygame_awesome_libraries/
>

Re: [pygame] unsubscribe pygame-users

[Thomas Kluyver]

To unsubscribe, you need to send that to majord...@seul.org , which is the
control interface for the mailing list.

More info here: http://www.pygame.org/wiki/info

Re: [pygame] Opening Python project in PyCharm - Mac

[Thomas Kluyver]

In Linux, I can right click on a folder, go to 'open with' and select
Pycharm.

Doing the same and selecting the Jetbrains Toolbox app doesn't work for me
- I get a notification popup 'Failed to find application for URL...'.

On 6 February 2018 at 22:44, Greg Ewing  wrote:

> Alex Nordlund wrote:
>
>> No, that's the toolbox, the toolbox app is free.
>> It's also confusingly named :-)
>>
>
> But does it do anything on its own? According to the web
> page about it, it's just something for managing their
> other tools, which are not free.
>
> If I'm wrong about that, and it actually has functionality
> of its own, then it's not just confusingly named, but
> very badly advertised.
>
> --
> Greg
>

Re: [pygame] trouble w/ SRCALPHA in 1.9.2-cp27

[Thomas Kluyver]

I'm not saying it's permanently dead. Existing maintainers may find more
time to work on it again. New people might turn up and help to push it
forwards. It's happened before - I successfully agitated for the 1.9.2 and
1.9.3 releases to happen, several years after 1.9.1.

Yesterday, I got the tests working on Travis CI again, so people can submit
pull requests and expect the tests to pass. Here are some things people
could do:

1. There are several pull requests awaiting review from someone who knows C
and/or the Python C API: https://github.com/pygame/pygame/pulls

2. There are about 100 open issues: https://github.com/pygame/pygame/issues
. Obviously if you can fix one, that's great, but if you can suggest how it
might be fixed, or what the underlying problem might be, that could make it
possible for someone else to fix it.

3. Triage! Check if you can reproduce a bug and supply more details. Issue
#340 on Github is a good example: it could be affecting almost all Mac
users, or only a few in specific situations. Does it depend on how you
installed pygame? Your version of Mac OS? Is it already fixed in the latest
pygame release, or in master? It needs someone with a Mac to investigate it.

4. If you're more into web programming or databases, the pygame.org website
could use some work, at https://github.com/pygame/pygameweb . For starters,
I've opened several issues about setting up a local site to test changes
on: I found this process tricky, and its a barrier to people contributing
to the site itself.

Thomas

On 30 November 2017 at 00:03, MrGumm  wrote:

> Nooo... Say it ain't so!
>
> On 11/29/2017 2:16 AM, Thomas Kluyver wrote:
>
> There's not a lot of work happening on pygame right now, so don't expect a
> new release any time soon. If you can find the fix for your issues,
> hopefully someone can look at a pull request.
>
> Thomas
>
> On 28 November 2017 at 23:56, MrGumm  wrote:
>
>> Greetings,
>>
>> Developers:
>>
>> I've submitted issues #340 and #341.
>> https://bitbucket.org/pygame/pygame/issues/340/surfaceconver
>> t-does-not-remove-the
>> https://bitbucket.org/pygame/pygame/issues/341/surfaceset_al
>> pha-sets-the-srcalpha-flag
>>
>> Actually it seems to impact everything from font rendering w/ a
>> background color, to rotozoom, to these tracked issues. Therefore, maybe
>> it'll be a one-tweak-fixes-all.
>>
>> This problem has major impact on my current project (a gfx-intensive
>> shooter on Raspian), so I'd like to get a feel, if I may, for when the next
>> release may appear with the fix(es) in it?
>>
>> Fellow coders:
>>
>> In the meantime, I would consider a workaround. But I cannot find one. If
>> anyone is smarter than me, help would be appreciated. I need to detect
>> whether a surface has per-pixel alpha in order to apply the proper
>> transforms. In the past this was detectable by checking the flags for the
>> presence of SRCALPHA. It's the nature of these issues that this is no
>> longer reliable.
>>
>> Thanks in advance.
>>
>
>
>

Re: [pygame] trouble w/ SRCALPHA in 1.9.2-cp27

[Thomas Kluyver]

There's not a lot of work happening on pygame right now, so don't expect a
new release any time soon. If you can find the fix for your issues,
hopefully someone can look at a pull request.

Thomas

On 28 November 2017 at 23:56, MrGumm  wrote:

> Greetings,
>
> Developers:
>
> I've submitted issues #340 and #341.
> https://bitbucket.org/pygame/pygame/issues/340/surfaceconver
> t-does-not-remove-the
> https://bitbucket.org/pygame/pygame/issues/341/surfaceset_al
> pha-sets-the-srcalpha-flag
>
> Actually it seems to impact everything from font rendering w/ a background
> color, to rotozoom, to these tracked issues. Therefore, maybe it'll be a
> one-tweak-fixes-all.
>
> This problem has major impact on my current project (a gfx-intensive
> shooter on Raspian), so I'd like to get a feel, if I may, for when the next
> release may appear with the fix(es) in it?
>
> Fellow coders:
>
> In the meantime, I would consider a workaround. But I cannot find one. If
> anyone is smarter than me, help would be appreciated. I need to detect
> whether a surface has per-pixel alpha in order to apply the proper
> transforms. In the past this was detectable by checking the flags for the
> presence of SRCALPHA. It's the nature of these issues that this is no
> longer reliable.
>
> Thanks in advance.
>

Re: [pygame]

[Thomas Kluyver]

This is the automatic control address for subscribe/unsubscribe requests:

majord...@seul.org

Here's the mailing list info: http://www.pygame.org/wiki/info

On 20 November 2017 at 17:32, Devon Scott-Tunkin <
devon.scotttun...@gmail.com> wrote:

> unsubscribe pygame-users
>

Re: [pygame] Pygame with changed location of SDL

[Thomas Kluyver]

I think it should respect standard mechanisms like the LD_LIBRARY_PATH
environment variable.

There are also ways to edit the binary to modify where it looks for
libraries: we do this in order to bundle libraries like SDL into the Linux
wheel packages. But I don't think this kind of trick should be necessary
for what you describe.

On 19 November 2017 at 16:11,  wrote:

> Hello Dear Community,
>
> I am trying to bring pygame to a system which sadly has a ro system
> partition. To be precise its Libreelec which is a just enough OS for the
> Homecinema Software Kodi. So due to it's limitations you can't install
> anything into /usr/ or similir folders. But you can Install addons, which
> also are able to contain binaries and libraries. So id like to know if
> there is a way to change, where pygame is looking for the SDL libraries.
>
> Thank you very much
>
>

Re: [pygame] Line Collision

[Thomas Kluyver]

Shapely (http://toblerity.org/shapely/manual.html ) is a Python library
with functions for things like 'do these two shapes intersect?' I don't
know if building the Shapely objects is quick enough to be done during a
game, but it's worth a try.

On 18 November 2017 at 18:55, bw  wrote:

> It seems so simple a problem to our eyes. But it's computationally a
> non-trivial problem. You can find algorithms on the web mostly in other
> languages and convert them to Python, like I did here.
>
> https://bitbucket.org/gummbum/gummworld2/src/200e9350acca33d
> 40b0c41c9e74c0eaeb6079061/gamelib/gummworld2/geometry.
> py?at=default&fileviewer=file-view-default#geometry.py-151
>
> I would love to see this stuff in a native lib. I might do it myself
> but...Windows.
>
>
>
> On 11/18/2017 8:26 AM, gabrielslo...@gmail.com wrote:
>
>> Hey, supose i have a Rect and a Line, i just want to see if the line
>> intercepts the rect, is that possible somehow in a kind of optimized way ?
>> Im having trouble implementing this.
>>
>> Thanks in advance !
>>
>
>

Re: [pygame] Installing Python 3 and pygame

[Thomas Kluyver]

On 17 May 2017 at 20:57, Irv Kalb  wrote:

>  But I would strongly suggest to whoever in is charge of that part of the
> pygame site, that they change the instructions to simply be:
>
> pip install pygame
>
> or
>
> pip3 install pygame
>
> It would have saved me a lot of time.
>

I'm not in charge, but I've edited the 'Getting Started' wiki page to use
more standard commands. Sorry that you had to spend time figuring it out!

Thomas

Re: [pygame] pygame.org not displaying release descriptions

[Thomas Kluyver]

On 26 April 2017 at 00:54, bw  wrote:

> Is this in the works, by any chance?


I have no idea, but the website code is here, if you can work out how to
fix it:
https://github.com/pygame/pygameweb

Thomas

Re: [pygame] Steam interface

[Thomas Kluyver]

I think that ties in with the discussions in the other thread about
supporting SDL 2 and hardware-accelerated rendering, but I don't understand
all the relevant pieces well enough to know if that work will help with
this.

On 20 April 2017 at 21:38, Bartosz Debski  wrote:

> I have integrated with Steam but using different wrapper. This looks quite
> impressive. Unfortunately pygame is a raster engine and Steam overlay will
> not work on raster engines according to documentation. I would love to have
> overlay but i think you would have to render your game to surface in openGL
> to achieve this. Please someone correct me if there is simple way for that.
>
> On Wed, Apr 12, 2017 at 11:36 AM, Thomas Kluyver  wrote:
>
>> I just came across this, a Steam client library for Python, with
>> functions to use Steam's services for things like finding other players and
>> recording achievements:
>> https://gramps.github.io/SteamworksForPython/
>>
>> Has anyone tried building a game in Python with this kind of Steam
>> integration?
>>
>> Thomas
>>
>
>

Re: [pygame] https://pygame.org/

[Thomas Kluyver]

On 19 April 2017 at 07:28, DiliupG  wrote:

> This is a good point for us to pivot in the direction of sdl2 permanently
> for the sake of the future. Is it really difficult to do that?
> Rene, Thomas what about it?


There's ongoing work on supporting SDL 2 being discussed in another thread
(though I'm not involved in it, to be clear). Hopefully it won't be too
difficult, but it's not totally straightforward either.

Thomas

Re: [pygame] https://pygame.org/

[Thomas Kluyver]

On 16 April 2017 at 18:19, DiliupG  wrote:

> A game written in Python/Pygame released commercially under STEAM.
>
> http://store.steampowered.com/app/442210/
>

Neat, thanks!

Does anyone know the author? It might be good to ask him to do a blog post
on what he needed to do to get a pygame game on Steam.

Thomas

[pygame] Steam interface

[Thomas Kluyver]

I just came across this, a Steam client library for Python, with functions
to use Steam's services for things like finding other players and recording
achievements:
https://gramps.github.io/SteamworksForPython/

Has anyone tried building a game in Python with this kind of Steam
integration?

Thomas

Re: [pygame] The long-ish pygame github migration status email.

[Thomas Kluyver]

Thanks René!

I take it that we should now continue all development on Github, make pull
requests there and so on?


On 26 March 2017 at 18:38, René Dudfield  wrote:

>
> *pygame. bitbucket. org*
>
> Seems they disabled this some time ago.
>

They moved all project websites to bitbucket.io subdomains. They didn't
leave the redirect in place for as long as I'd like.

Thomas

Re: [pygame] Another instalment in the Flatpak saga

[Thomas Kluyver]

On 26 March 2017 at 08:16, René Dudfield  wrote:

> I sort of feel bad for Ubuntu, where so many of the things they make are
> not taken up by the winder community. On the other hand, perhaps we'd never
> have heard of flatpak otherwise.
>

Yeah, I feel that way too. The community seems to be pretty hostile to a
number of projects from Canonical. In this case, though, I don't think they
really tried to push Snap as a solution for desktop apps - there was a
half-hearted push to get it into other distros, but it never felt like they
were really committed to it. I think they're more interested in server and
mobile use cases, because there's more potential revenue there.


> It seems 16.04 is supported with a ppa on Ubuntu, and it's at least
> packaged for many other ones. Couldn't find anything about being in by
> default with mint, manjaro, fedora, suse, raspberian? I guess it's too soon.
>

It's in a default install of Fedora 25 (the current stable version). I
think it's backed by people in the Gnome/Fedora/Red Hat set, so that's no
surprise. It's in Debian's repos, but I don't know if/when it will be
included in a default install of things like Mint or Raspbian.


> I wonder if you tried the 'change current working directory' hack, and it
> didn't work?
>

I didn't try it yet. I think it certainly should work, it just feels wrong.

Thomas

[pygame] Another instalment in the Flatpak saga

[Thomas Kluyver]

My adventures mixing pygame and Flatpak have got a bit further. I now have
a crude tool which can build a working Flatpak package from a config file
describing your game. See the instructions here:
https://github.com/takluyver/pygame-flatpak-test#readme

I want to emphasise that this is very unpolished at the moment. If you're
interested in distributing games to Linux users, please try it out, but
expect bugs! I hope it will be a stepping-stone to a more general tool to
package Python applications using Flatpak, but I'm still thinking about how
that will work, and I want to get some more experience of the Flatpak
system.

I've updated the two example games I was working with to build with this
tool. Here's the diff for Solarwolf, which didn't need any changes in the
code:
https://github.com/pygame/solarwolf/compare/master...takluyver:flatpak

And here's the diff for Luke's Pyweek game, Solarflair, which needed a few
tweaks:
https://github.com/lukevp/pyweek23/compare/master...takluyver:flatpak

In other news, I hear that Ubuntu 17.04 will include Flatpak in a default
install, which seems like a good sign that I'm not wasting my time. ;-)

Thanks,
Thomas

Re: [pygame] Re: pygame with SDL2 proposal

[Thomas Kluyver]

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

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


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

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

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

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

Thomas

Re: [pygame] Re: pygame with SDL2 proposal

[Thomas Kluyver]

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

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


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

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

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

Thomas

Re: [pygame] pygame with SDL2 proposal

[Thomas Kluyver]

In 21 March 2017 at 08:21, René Dudfield  wrote:

> If people can't use SDL1 for the moment with pygame, then we will be in a
> situation where two branches are needed. Rather than that, it seems simpler
> for me with a single code base for SDL1 and SDL2.


I guess this is the core of it. To me, the single code base sounds harder
than keeping two separate branches, especially as I expect the SDL 1 branch
wouldn't see many changes. But you're the one doing it, so if you prefer
the single code base option, that's reason enough to do it that way. ;-)

Re: [pygame] pygame with SDL2 proposal

[Thomas Kluyver]

Thanks Ian for the clear post! I think this is the sort of thing I was
trying to get at, but I don't know as much about it.

On 20 March 2017 at 17:42, Ian Mallett  wrote:

> Hi,
>
> As sort of a side-note, since performance has come up . . .
>
> Per-pixel drawing operations, if they must be individually managed by the
> CPU, will always be much faster to do on the CPU. This means things like
> Surface.set_at(...) and likely draw.circle(...) as well as potentially
> things like draw.rect(...) and draw.line(...). And it means everything, if
> there are a lot of calls. The GPU is obviously faster at graphics
> operations in-general, but it's still a thorough loss if you have to send
> the commands over the PCIe in the first place: if not in processing time,
> then in latency. As a matter of fact, this is true for most things people
> try to use GPUs for, and mitigating it is why e.g. Vulkan has to be so
> complex.
>
> What does this have to do with anything?
>
> Well, it's a philosophical question of what we want pygame to be:
>
> 1: Hardware-accelerated pygame-API-compatible library. (Basically won't
> work for reasons above.)
> 2: Hardware-accelerated pygame-API-incompatible library. (Fine, but AFAIK
> this already exists .
> There are probably other projects too.)
> 3: Software pygame-API-compatible library. (We have this now, and any
> movement to SDL2 should be considered in light of what features it changes
> (i.e. many misc. improvements, but worse (?) blitting).)
> 4: Software pygame-API-incompatible library. (Works best, IMO, with any
> plan to support SDL2.)
>
> Python is a slow language, and if you're using it, you're implicitly
> saying usability is more important right now. This includes graphics, and
> pygame is currently occupying that niche: highly usable, low-level,
> slow(ish; still pretty fast) graphics. If we want hardware acceleration
> (options 1, 2) then we're moving outside that niche. Ditto, to a lesser
> extent, breaking compatibility to add more-modern features (option 4). So
> basically, what it comes down to is whether we like our niche, whether
> moving to/incorporating SDL2 is focusing on a real problem, if so whether
> moving to SDL2 affects our feature set in ways we do like, and if so
> whether this affects our niche in ways we don't like.
>
> Ian
>

Re: [pygame] pygame with SDL2 proposal

[Thomas Kluyver]

On 20 March 2017 at 15:13, René Dudfield  wrote:

> The big advantage is that it is a much smaller change than something new.
>
>- smaller changes reducing risk
>- the smaller amount of resources needed to get to SDL2
>
> I think we're talking at cross purposes, because what I'm arguing against
(supporting SDL 1 and 2 at the same time) requires *more* resources, not
less. You have to expend the effort to make SDL 2 work either way, but with
your proposal, you must also expend extra effort to ensure that SDL 1 still
works, and still more effort to build the mechanisms to switch between them
at build time.

>
>- SDL1 using people can keep with that for the time being
>
>
My proposal is that people who need to stick with SDL 1 will install pygame
<2. We can either declare it finished and let people rely on the last
working release, or make occasional 1.9.x releases to fix critical bugs.
Either way, that seems less effort that trying to carry SDL 1 support
forwards with us as we support SDL 2. Pygame 1.9.3 works well enough for
lots of games, and I'm fine with saying that we're leaving SDL 1 support
there.

Re: [pygame] pygame with SDL2 proposal

[Thomas Kluyver]

On 20 March 2017 at 12:25, René Dudfield  wrote:

> The stronger evidence of tests passing, and no concrete theoretical
> reasons presented on why it can't be compatible suggests to me that it can
> be done.


I don't know a lot about SDL, but the transition sounds like a big change.
And my experience is that any big change inevitably makes things break.
People will rely on undocumented, untested features, and things that aren't
features at all but just happen to work. There are some old stories about
the lengths Microsoft went to for backwards compatibility in Windows, which
included checking when a certain popular game was started, and then
emulating an old bug which that game happened to rely on. I don't think
we're going to be doing that sort of thing.

I also don't see the advantage of having one version of pygame that can be
built with two different versions of SDL. When people install it, they're
getting one or the other version of SDL, not both. If they install it with
SDL 1, they don't benefit from the SDL 2 support. If they install it with
SDL 2, there's just as much risk of incompatibility as if they had to
install a different version or different package for pygame with SDL 2. And
recompiling to switch between the two is harder than simply running 'pip
install pygame<2'.

This (supporting both SDLs in the same pygame release) is a separate
question from making pygame API compatible when it moves to SDL 2 by
default. That's an easier case to make - though I think there's also a case
for letting pygame 1.x go quietly into the sunset supporting games already
built for it, and making pygame2 for new games with some API breakage.

At the heart of this, there's a question about how pygame users see game
development: do you work on one game in an ongoing manner, adding support
for new libraries and platforms as they come up? Or do you develop and
release a game with the pieces available at the time, and then move on to a
new project? Commercial games appear to follow the latter description more,
and contests like pyweek lend themselves to develop-and-stop, which
suggests that preserving API compatibility is not all that important. But
maybe lots of other games follow the latter model.

> Holding onto legacy books, apps, tutorials is only hindering the progress
of a modern Python game library.

Leif, while I agree with your points about complexity and compatibility, I
think that the body of experience with pygame - in the form of tutorials,
books, etc. - is actually a strength, and perhaps even the reason that
people are still wanting to use it when there are so many newer tools. So I
think it would be good to keep the API similar enough that those materials
are still applicable.

Thomas

Re: [pygame] pygame with SDL2 proposal

[Thomas Kluyver]

Having a codebase compatible with both versions of SDL sounds sensible, but
having spent a day considering it, I suspect it would be a mistake.

Compatibility is never going to be perfect, so in practice I expect that a
lot of games will require "pygame 1.10 compiled with SDL 2" or "...with SDL
1.2", according to what the developer tested it with. The packaging systems
I'm familiar with are not able to express a dependency like this. So it
would be useful if the name (e.g. pygame2) or version (e.g. pygame version
2.0) of the package encoded that it was based on SDL 2.

To frame this another way: for most people there will be a sudden
transition when the pre-compiled packages they use switch to building with
SDL 2. If pygame makes releases that are compatible with both SDL versions,
the packages from PyPI, conda, apt, homebrew and so on may make that
transition at different version numbers, generating confusion. If pygame
2.0 simply switches to SDL 2, the switch is coordinated, so the version
number is a reliable indicator of what you're getting.

So if we do turn the pygame codebase into an SDL 2 wrapper, rather than
adopting/recommending one of the existing wrappers, I would strongly
suggest that we a) make a clean switch, not attempting to support both, and
b) use a new major version number, or even a new package name, to clearly
distinguish it.

Thomas

Re: [pygame] pygame with SDL2 proposal

[Thomas Kluyver]

Going back to basics for a moment: what is the advantage for game
developers of SDL 2 over 1.2? Is it more performant? Does it offer easier
to understand abstractions? Can you make games do things that would be
impossible with 1.2? And are there any downsides to the new version? I
think we need an idea of the differences to have a useful discussion on
supporting SDL 2.

Thomas

On 19 Mar 2017 6:04 p.m., "Leif Theden"  wrote:

> Idk. You could argue that pygame had a "tight coupling" to pushing pixels
> with a CPU. Or the display for that matter (ever try to use the sound
> module before initializing the display?) In any case, I don't see this
> comparison to Kivy going anywhere.
>
> On Sun, Mar 19, 2017 at 11:49 AM Daniel Pope  wrote:
>
>> > It's not a tight coupling, it supports several backends and runs on
>> many platforms, from PC to Rpi
>>
>> That's not the part that I am claiming is a tight coupling. The tight
>> coupling is between the OpenGL/input bindings for mobile - which could be
>> great, but is incomplete and undocumented - and the UI framework, which I
>> don't like.
>>
>> > I don't think it would take much to have a games API if the community
>> put effort in to it.
>>
>> Exactly - if it has to be an API of Kivy, rather than a separate project
>> built upon it, then that's a tight coupling.
>>
>> On Sun, 19 Mar 2017, 15:47 Leif Theden,  wrote:
>>
>> I don't follow your idea about mistakes in Kivy. It's not a tight
>> coupling, it supports several backends and runs on many platforms, from PC
>> to Rpi. I love kivy and have been using it for a long time. It's not
>> extremely stable (API changes), but it is light years ahead of pygame in
>> terms of usability and functionality.
>>
>> It may be a bit more cumbersome in Kivy for use with games or extreme
>> beginners, but I don't think it would take much to have a games API if the
>> community put effort in to it.
>>
>> I'm all for a simple pygame too, and I don't think the comparison to Kivy
>> is appropriate. Kivy is a framework for touch applications primarily.
>> On Sun, Mar 19, 2017 at 9:28 AM Daniel Pope  wrote:
>>
>> Something that I think is important is that we should aim to avoid
>> putting experimental stuff into Pygame.
>>
>> I think it's a mistake Kivy made: tightly coupling excellent work in
>> OpenGL ES bindings and deployment on mobile, with a crude UI framework and
>> runtime.
>>
>> I guess all I'm saying is that we should keep Pygame simple, and let
>> other projects build the ecosystem on top of it.
>>
>> On Sun, 19 Mar 2017, 13:27 Leif Theden,  wrote:
>>
>> My comment from the Reddit:
>>
>> It has always been my feeling that pygame2 break compatibility with
>> pygame1 and embrace modern computer features, namely the GPU. Shoehorning
>> the clunky surface & blit API over sdl2 is a major regression. As is, no
>> modern game library uses a system like this.
>>
>> If it is moved to sdl2, then I would like to see it completely move to a
>> modern rendering backend, without legacy features. Allow new programmers to
>> try out shaders, experiment with opencl, maybe include a full featured SDL2
>> backend that you can drop into.
>>
>> Also:
>>
>> * first class gamepad support
>> * easier to understand sound API
>> * remove redundant modules like key, mouse, and joystick
>> * more focus on using the event queue
>> * more scaffolding, like a drop in event engine, easier setup for the
>> screen, and game loop with less boilerplate cruft
>>
>> At this point pygame1 is useful for quick prototyping and embedded
>> systems because it can use a framebuffer. Beyond that? I'm not so sure that
>> pygame can be relevant if it trys to support the old software API.
>>
>> Even SDL2 dropped the software API, for the most part.
>>
>> pygame_sdl2, guess what, it is trying to be source compatible, and
>> despite being written in cython and compiled into native code, it is slower
>> than pygame because of the legacy software renderer sdl2 doesn't optimize
>> like the original did. To get pygame1 level performance with the legacy
>> API, you will need to patch sdl2 and maintain a fork that contains
>> optimized blitting code.
>>
>> If you want to avoid a long transition and constant bickering about
>> breaking changes, then you need to introduce a great feature to get people
>> to switch. Implement a solid hardware-accelerated Sprite & Groups API and a
>> "click to distribute" script in the std. lib and you will have people
>> moving very quickly.
>>
>> Also, drop python 2 support. Just my thoughts.
>> On Sun, Mar 19, 2017 at 8:04 AM René Dudfield  wrote:
>>
>> There's some more conversation over on the reddit.
>> https://www.reddit.com/r/pygame/comments/604cxw/pygame_
>> with_sdl2_proposal_pygame_dev_ren%C3%A9/
>>
>>
>> On Sun, Mar 19, 2017 at 8:57 AM, René Dudfield  wrote:
>>
>> Haha. "import pygumm" definitely does sound better. Seriously.
>>
>> For *me* pypy is a non goal, and CFFI has some drawbacks. I know pypy
>> also has plenty of upsides in cer

Re: [pygame] pygamezero moving to github discussion thread

[Thomas Kluyver]

On 16 March 2017 at 10:01, René Dudfield  wrote:

> Yeah, with the python community moved to github, it's really past time to
> move.


Do you also want to move the pygame repo itself onto Github rather than
using it as a mirror? Or is pygame in maintenance-only mode, and it's less
important to attract new contributors?

I agree that it's easiest to attract contributors if your project is on
Github, but at the same time, I'm a bit sad that we seem to be heading for
a total Github monoculture.

Thomas

Re: [pygame] Re: Playing with Flatpak packaging

[Thomas Kluyver]

On 14 March 2017 at 10:31, René Dudfield  wrote:

> Also depending on the current working dir is fairly common. I used to use
> some code which would try and change the current working dir as the first
> thing. But realised this broke under all the different OSes that do all
> sorts of weird things.
>

I wondered about this. The launcher script could probably chdir() to its
own location before starting the user's code. It feels like the wrong
approach in general - I believe the working directory should be primarily
left as a convenience for end users, not for developers, and I'd rather try
to build tools/templates that encourage the right way to do it - but it's
arguably not such a sin in game development, where the end users probably
don't need to interact with the filesystem.


> zero effort - pygame icon fallback
> small effort - one large image resized as needed
> more effort - every size of icon, and file type can be specified exactly.
>

That makes sense. Pynsist includes a generic star icon as a fallback in a
similar vein. I'll also think about converting icons between different
formats.

Re: [pygame] Re: Playing with Flatpak packaging

[Thomas Kluyver]

I was able to make a flatpak package quite easily for Solarwolf, using my
Python 3.6 base app. You can see the files I added to do so here:
https://github.com/pygame/solarwolf/compare/master...takluyver:flatpak

I also made a Python 2.7 version of the base app (which was easy) and had a
go at making a Flatpak package of Luke's pyweek entry. This works (though I
can only get to the menu screen), but it required some changes to how asset
files are found, and I chose to use a different layout of files (in
/app/share/solarflair). Here are the changes and additions I made:
https://github.com/lukevp/pyweek23/compare/master...takluyver:flatpak

If you want to try to build either of them yourself, you will first need to
build the necessary base apps from my repo here:
https://github.com/takluyver/pygame-flatpak-test

The process for making these packages is still quite involved; I'd like to
make some tooling to simplify it. But I think we need some conventions on
structuring apps to make that possible - I don't think I can make an
easily-understood tool that would handle the two very different layouts
above. Allow me to start by describing how I'd ideally like apps to be
structured:

1. Use entry points: an entry point is a reference to a function, like
'solarwolf.cli:main'. The launcher script imports that function and calls
it ( from solarwolf.cli import main; main() ). Providing a main function
like this allows tools to generate a script that does some setup before
launching your code - e.g. adding directories to sys.path, or configuring
handling for uncaught errors.
2. Include asset files inside the Python package: this means there's just
one directory for the developer to specify which contains all the necessary
files to run the game.
3. Don't rely on the working directory when loading data files: If you load
assets from a path like 'assets/mysprite.png', it's easy for that to break
when the game is installed. If you follow #2, you can easily construct an
absolute path using the special '__file__' variable (see
http://pynsist.readthedocs.io/en/latest/faq.html#using-data-files ), but if
you don't do it like this, please at least use a variable like DATA_DIR=,
and make all asset paths from that, so it can easily be changed in one
place.

My existing tool Pynsist (for building Windows installers) enforces #1, and
encourages #2 and #3. What do you think of these ideas? How could we make
it easy for game developers to follow them? Are there other sources of
variation you'd like to standardise?

It's not urgent, but I'd also like to find better ways to work with icons
for apps. You provide icons in a range of sizes (e.g. 16x16, 32x32, 48x48,
64x64...), but you typically remove some details in the smaller sizes, so
it's not just a matter of creating one image and scaling it down. Icons
also use different formats on different platforms (png, ico, icns), and I
don't think it's terribly easy to convert between them. Are there any tools
or techniques people use for dealing with icons?

Thanks,
Thomas


On 7 March 2017 at 18:10, Thomas Kluyver  wrote:

> It should be easy enough to make a base app using Python 2.7 - I just
> focus on Python 3 first, because that's what I'm most interested in.
>
> As John pointed out, Flatpak is a Linux technology. I have also
> experimented with making it easy to build Windows installers for Python
> applications - my project for that is called Pynsist, and you can see an
> example using Pygame here:
> https://github.com/takluyver/pynsist/tree/master/examples/pygame
>
> (Pynsist does not use the Windows sandboxing mechanisms John described)
>
> Eventually, I'd like to have a common format for describing Python
> applications, and a set of tools that can use that to build packages,
> installers, self-contained executables and so forth for different
> platforms. Pynsist would be one such tool, and my investigations into
> Flatpak will hopefully lead to another tool.
>
> Luke: thanks, I'll look at what it would take to Flatpak-ify your game.
>
> Thomas
>
> On 7 March 2017 at 07:06, DiliupG  wrote:
>
>> a python 27 version for windows would be GREATLY appreciated unless you
>> consider python 27 users redundant and windows, not a real os.
>> :(
>>
>>
>> On 7 March 2017 at 02:28, Luke Paireepinart 
>> wrote:
>>
>>> Would be great to try this on my pyweek entry if you're looking for
>>> games to test, just let me know how it turns out. It's called solar flair,
>>> but was developed with python 2.7 on Windows. I'm not sure on the
>>> compatibility with 3.x. - https://github.com/lukevp/pyweek23
>>>
>>>
>>> On Mar 6, 2017 12:11 PM, "Thomas Kluyver"  wrote:
>>>
>&g

Re: [pygame] https://pygame.org/

[Thomas Kluyver]

Thanks René! I take it this is now running from the code at
https://github.com/pygame/pygameweb/ ?

I went through confirming my email address and resetting my password, but
now I get 'account is disabled' when I try to log in. Is this part of the
anti-spam measures? If this is what most new users will experience, can we
make it clearer what's happening and what they need to do?

Thomas

On 10 March 2017 at 08:51, René Dudfield  wrote:

> https://pygame.org/
>

Re: [pygame] Re: Playing with Flatpak packaging

[Thomas Kluyver]

It should be easy enough to make a base app using Python 2.7 - I just focus
on Python 3 first, because that's what I'm most interested in.

As John pointed out, Flatpak is a Linux technology. I have also
experimented with making it easy to build Windows installers for Python
applications - my project for that is called Pynsist, and you can see an
example using Pygame here:
https://github.com/takluyver/pynsist/tree/master/examples/pygame

(Pynsist does not use the Windows sandboxing mechanisms John described)

Eventually, I'd like to have a common format for describing Python
applications, and a set of tools that can use that to build packages,
installers, self-contained executables and so forth for different
platforms. Pynsist would be one such tool, and my investigations into
Flatpak will hopefully lead to another tool.

Luke: thanks, I'll look at what it would take to Flatpak-ify your game.

Thomas

On 7 March 2017 at 07:06, DiliupG  wrote:

> a python 27 version for windows would be GREATLY appreciated unless you
> consider python 27 users redundant and windows, not a real os.
> :(
>
>
> On 7 March 2017 at 02:28, Luke Paireepinart 
> wrote:
>
>> Would be great to try this on my pyweek entry if you're looking for games
>> to test, just let me know how it turns out. It's called solar flair, but
>> was developed with python 2.7 on Windows. I'm not sure on the compatibility
>> with 3.x. - https://github.com/lukevp/pyweek23
>>
>>
>> On Mar 6, 2017 12:11 PM, "Thomas Kluyver"  wrote:
>>
>> I developed this a bit further, though there's still more I hope to do
>> with it.
>>
>> It turns out that building a custom runtime is discouraged; the better
>> way to support game developers is to build a 'base app', which people can
>> then add their own game files to. I have prepared two different base apps:
>> one includes Python 3.6, and makes a download of about 30 MiB. The other
>> uses Python 3.4 from the shared runtime, so is a download of about 7 MiB.
>> My idea is that the game developer can choose between the latest language
>> features and a quicker installation.
>>
>> My next step is to make a more complete example of using this to package
>> a game (so far, I've tested with the 'aliens' example that ships with
>> pygame). I might try with the solarwolf example on Pygame's Github org - or
>> if anyone wants to suggest another suitable open-source game based on
>> pygame, I could try with that.
>>
>> Thomas
>>
>> On 26 February 2017 at 19:47, Thomas Kluyver  wrote:
>>
>>> I spent a while today playing with Flatpak, a new system for packaging
>>> sandboxed applications on Linux. The result is an example that can build
>>> and install Pygame's Aliens example game:
>>>
>>> https://github.com/takluyver/pygame-flatpak-test
>>>
>>> If you're running Fedora 24+, Ubuntu 16.10 (might need a PPA?) Debian
>>> testing/unstable or Arch, you can install Flatpak and try it out.
>>>
>>> This is quite rough at the moment, but I think it has good potential for
>>> distributing games to Linux users in the future. It looks like [1] Flatpak
>>> is on its way to becoming the default cross-distro app distribution
>>> mechanism for desktop Linux.
>>>
>>> The big improvement I'd like to make is building a dedicated Flatpak
>>> 'runtime' for pygame, including a newer version of Python - the base
>>> runtime I'm using at present has Python 3.4.
>>>
>>> Thanks,
>>> Thomas
>>>
>>> [1] https://kamikazow.wordpress.com/2017/02/09/adoption-of-flatp
>>> ak-vs-snap/
>>>
>>
>>
>>
>
>
> --
> Kalasuri Diliup Gabadamudalige
>
> https://dahamgatalu.wordpress.com/
> http://soft.diliupg.com/
> http://www.diliupg.com
>
> 
> **
> This e-mail is confidential. It may also be legally privileged. If you are
> not the intended recipient or have received it in error, please delete it
> and all copies from your system and notify the sender immediately by return
> e-mail. Any unauthorized reading, reproducing, printing or further
> dissemination of this e-mail or its contents is strictly prohibited and may
> be unlawful. Internet communications cannot be guaranteed to be timely,
> secure, error or virus-free. The sender does not accept liability for any
> errors or omissions.
> 
> **
>
>

[pygame] Re: Playing with Flatpak packaging

[Thomas Kluyver]

I developed this a bit further, though there's still more I hope to do with
it.

It turns out that building a custom runtime is discouraged; the better way
to support game developers is to build a 'base app', which people can then
add their own game files to. I have prepared two different base apps: one
includes Python 3.6, and makes a download of about 30 MiB. The other uses
Python 3.4 from the shared runtime, so is a download of about 7 MiB. My
idea is that the game developer can choose between the latest language
features and a quicker installation.

My next step is to make a more complete example of using this to package a
game (so far, I've tested with the 'aliens' example that ships with
pygame). I might try with the solarwolf example on Pygame's Github org - or
if anyone wants to suggest another suitable open-source game based on
pygame, I could try with that.

Thomas

On 26 February 2017 at 19:47, Thomas Kluyver  wrote:

> I spent a while today playing with Flatpak, a new system for packaging
> sandboxed applications on Linux. The result is an example that can build
> and install Pygame's Aliens example game:
>
> https://github.com/takluyver/pygame-flatpak-test
>
> If you're running Fedora 24+, Ubuntu 16.10 (might need a PPA?) Debian
> testing/unstable or Arch, you can install Flatpak and try it out.
>
> This is quite rough at the moment, but I think it has good potential for
> distributing games to Linux users in the future. It looks like [1] Flatpak
> is on its way to becoming the default cross-distro app distribution
> mechanism for desktop Linux.
>
> The big improvement I'd like to make is building a dedicated Flatpak
> 'runtime' for pygame, including a newer version of Python - the base
> runtime I'm using at present has Python 3.4.
>
> Thanks,
> Thomas
>
> [1] https://kamikazow.wordpress.com/2017/02/09/adoption-of-
> flatpak-vs-snap/
>

Re: [pygame] PyGame user interface widgets

[Thomas Kluyver]

On 27 February 2017 at 17:06, Yann Thorimbert 
wrote:

> Here is a tutorial for installation, but its truely easy and most people
> won't need it : http://thorpy.org/tutorials/install.html
>

It looks like it's pip-installable (pip install thorpy). You might want to
highlight this more on the installation page - it's the standard way to get
Python libraries, and it's much more convenient than working out where to
copy files to manually.

Re: [pygame] Playing with Flatpak packaging

[Thomas Kluyver]

On 26 February 2017 at 20:14, Charles  wrote:

> What does it have over Docker?


Short answer: Docker is aimed at server applications, Flatpak at desktop
applications.

Longer answer: I'm not sure I know enough about the technologies involved
to really do them justice. But the sandboxing in Flatpak is built with
awareness of desktop Linux technologies, like X, Wayland, OpenGL,
PulseAudio and DBus. There's also a 'portals' mechanism which allows the
user to do things like opening files that would normally be outside the
app's sandbox. And Flatpak is getting integrated into GUI installer tools
like gnome-software, so it should be possible to install apps without using
the command line (this doesn't seem to fully work just yet, but the pieces
are coming together).

Of course, some of this is stuff that *could* be done on top of Docker -
Subuser is an interesting effort to do precisely that. But Flatpak seems to
have the backing of the GNOME developers, and KDE are starting to do stuff
with it as well, so it looks to me like the front runner at the moment.

I should also mention Snappy here, which is Canonical's horse in the
sandboxed Linux packaging race. I've played around with that a bit too (I'm
interested in this stuff ;-), but my impression is that Flatpak is more
likely to become a standard, because:
1. The desktop Linux community is suspicious of stuff from Canonical,
rightly or wrongly
2. Snappy also targets server and mobile use cases, and I get the
impression Canonical's more interested in those than in desktops (they've
found it hard to make money on desktops, I believe)
3. The architecture underlying Flatpak is more sophisticated than that of
Snappy (my impression); I think its separation of apps and 'runtimes' will
make it marginally more palatable to people who like using shared
dependencies.

Thomas

[pygame] Playing with Flatpak packaging

[Thomas Kluyver]

I spent a while today playing with Flatpak, a new system for packaging
sandboxed applications on Linux. The result is an example that can build
and install Pygame's Aliens example game:

https://github.com/takluyver/pygame-flatpak-test

If you're running Fedora 24+, Ubuntu 16.10 (might need a PPA?) Debian
testing/unstable or Arch, you can install Flatpak and try it out.

This is quite rough at the moment, but I think it has good potential for
distributing games to Linux users in the future. It looks like [1] Flatpak
is on its way to becoming the default cross-distro app distribution
mechanism for desktop Linux.

The big improvement I'd like to make is building a dedicated Flatpak
'runtime' for pygame, including a newer version of Python - the base
runtime I'm using at present has Python 3.4.

Thanks,
Thomas

[1] https://kamikazow.wordpress.com/2017/02/09/adoption-of-flatpak-vs-snap/

Re: [pygame] Promoting cheeseshop/pypi for game releases?

[Thomas Kluyver]

On 4 February 2017 at 15:29, René Dudfield  wrote:

> @deshipu: mentioned another distribution method which is quite simple.
> http://pygame.org/project-pyg.exe-2830-.html


Neat! I think this approach gets more fiddly as the project gains
dependencies other than pygame, though.

Pynsist aims for a somewhat more polished installer that can set up things
like start menu entries. But the layout of files it produces could pretty
easily be used to make an 'unzip & execute' package as well.

Thomas

Re: [pygame] Promoting cheeseshop/pypi for game releases?

[Thomas Kluyver]

On 4 February 2017 at 13:42, René Dudfield  wrote:

> I was pointed to pbr by lordmauve. http://docs.openstack.org/
> developer/pbr/
>
> I like how pbr uses setup.cfg. Which I think other tools could use, by
> putting their config inside a setup.cfg section.
>

Yep, there are a few tools to use declarative metadata for packaging (d2to1
is/was another). Flit was initially an experiment in whether it's possible
to do Python packaging without using the distutils/setuptools machinery. As
far as I know, all other tools build on top of distutils/setuptools, but I
believe this is the source of many headaches.

There are PEPs in the works (516, 517, 518) which define a new
pyproject.toml file for packaging metadata. Once this is a bit more
advanced, I plan to move flit's config inside that file. I hope that it
will become a more modern, better specified alternative for setup.cfg.


> Perhaps I agree with you about the magic. I guess it's more a thought
> experiment about how simple we can make it at this point. Perhaps it could
> be made usable by explaining to the user how to specify the missing data if
> it's not there (eg. no git... then it tells people it tried to find it in
> git, and for people to add author etc).
>

+1 to running the thought experiment.

I guess how I might use these things is in a tool like 'flit init' - if git
is present, it could use it to inform its default guess for author name &
email, and then it writes these to a config file rather than using them
directly.

I have some thoughts on a tool which could add or modify features of a
project like packaging or docs - as opposed to tools like cookiecutter,
which expects to create an entire project. I wrote about this here:
https://github.com/takluyver/flit/pull/97#issuecomment-270984130

Re: [pygame] Promoting cheeseshop/pypi for game releases?

[Thomas Kluyver]

On 4 February 2017 at 12:43, René Dudfield  wrote:

> I also kind of hate 10-30 config files in repos.
>
> What would a python package look like with no extra files apart from our
> code? http://renesd.blogspot.de/2017/02/what-would-python-packagin
> g-zero-look.html Then continued the idea here: http://renesd.blogspot.de/
> 2017/02/python-packaging-zero-part-one.html
>
> The main idea is that you can derive enough information from the python
> code and the git(or hg) repo.
>

I also dislike having a load of different boilerplate files in a repo for
packaging. This was part of what prompted me to write flit. However, I
don't think that it's practical to use absolutely zero config. From your
proposals, I don't like getting details out of git - it requires that the
code is in a git repo, and it makes things quite brittle.

The minimum working config for flit looks like this:

[metadata]
module = astsearch
author = Thomas Kluyver
author-email = tho...@kluyver.me.uk
home-page = https://github.com/takluyver/astsearch

It takes the description from the docstring (as in your proposal), and the
version number from __version__ in the module. There's a command line tool
'flit init' that prompts you for these values, with defaults that you can
accept by pressing enter. It doesn't need setup.py or MANIFEST.in or
anything: you could literally have just your module and flit.ini.

I recognise that this is still some boilerplate that may seem redundant to
new users, but I think it's ultimately clearer to have these values
explicitly associated with the project than to pull them out of a magic hat.

Thomas

Re: [pygame] Promoting cheeseshop/pypi for game releases?

[Thomas Kluyver]

On 3 February 2017 at 15:33, René Dudfield  wrote:

> I think this API is simple, and it's possible to do a fairly good
> implementation and a very quick easy implementation in time for pyweek.
>
> Perhaps we can have a namespace package pygame.resources, released on pypi
> as pygame_resources. Or maybe include it in a 'skellington' package? If so,
> what should that package be called?
>

I think that API looks reasonable. I'd do it in 'skellington' for now and
let game creators play around with it before it becomes 'official'.

My understanding of namespace packages is that all the pieces that use it
have to agree on what is a namespace package, so we can't make pygame a
namespace package, because we already use it as a regular package. My
experience with the 'backports' namespace package is that it's not worth it
anyway - when it goes wrong, it's horrendously confusing and tricky to fix.
So as and when it becomes a package, I'd just let people import it as
'pygame_resources'.


> Ok, I am happy to avoid pkg_resources. Does it give us anything at all?
>

I think it does give some stuff, e.g. its data loading routines know about
zipped egg packages. However, I also think eggs should be avoided.

Setuptools (which pkg_resources is part of) has a particular way of seeing
packages - for instance, it can handle different versions of the same
package installed in the same environment - but that view conflicts with
the model most Python programmers now favour, based on pip+virtualenv. I
think setuptools makes sense if you buy into its view entirely, but if you
don't, it makes things opaque and complex for little apparent benefit.

> Here's the pyglet approach to resources loading.

That's quite neat. I disagree with the way it privileges the launcher
script, which I often don't have in a consistent relationship with the data
files, but I like that you can use a package directory. I would probably do
something like this:

from pyglet.resources import Loader
resources = Loader('@' + __name__ + '/data')  # resources in mygamepkg/data

Re: [pygame] Promoting cheeseshop/pypi for game releases?

[Thomas Kluyver]

On 2 February 2017 at 06:34, René Dudfield  wrote:

> Whilst naming is important, the name of the package doesn't need to be the
> name of the Game. I've worked on projects where the company name, and app
> name changed at least three times whilst the package name stayed the same.
> So I don't think people need to worry so much. Also, it's not too hard to
> change the package name later on.
>
>
> My vote would be to follow the python sampleproject way of doing things.
>

That gets my vote as well. If you're putting it on PyPI, sooner or later
you have to give the package a good name (at least, not the same name as
every other game's package). We can encourage people to use relative
imports (from . import foo) which makes it less work to rename.



> Data folder, and "get_data".
>
> 2). The other aspect I'm not sure of is having a data folder outside of
> the source folder. Having it inside the source folder means you can more
> easily include it inside a zip file for example. It also makes packaging
> slightly easier. Since you can just use from within a MANIFEST.in a
> recursive include of the whole "mygamepackage" folder.
>
> Having data/ separate is the choice of the sampleproject, and the
> skellington.
>
> I haven't really seen a modern justification for keeping data out of the
> package folder?
>

My vote would be for it to go inside the package, and for the skeleton to
provide a bit of code like this:

DATA_DIR = os.path.join(dirname(abspath(__file__)), 'data')
def find_data(*path):
return os.path.join(DATA_DIR, *path)

This is roughly what I recommend in Pynsist's FAQ.


> I have vague recollections of reasons being: 'because debian does it'. My
> recollection is that Debian traditionally did it to keep code updates
> smaller. Because if you only change 1KB of source code, there's no point
> having a 20MB update every time.
>

Linux packagers like to put data files in /usr/share to comply with the
filesystem hierarchy spec. However, with the snippet of code I gave above,
it's easy for them to patch DATA_DIR = '/usr/share' and move the files out.


> A bonus of keeping data separate is that it forces you to use relative
> addressing of file locations. You don't hardcode "data/myfile.png" in all
> your paths. Do we recommend the python way of finding the data folder? This
> is package_data, and data_files setup attributes. https://github.com/pypa/
> sampleproject/blob/master/setup.py
>

Actually, I think that's more of a risk if it's a separate top-level
directory, because then 'data' is going to be in the CWD when you run it as
a developer.


> They (package_data) are a giant pain. One, because they require mentioning
> every single file, rather than just the whole folder. Two, because they
> require you updating configuration in both MANIFEST.in and setup.py. Also,
> there are different files included depending on which python packaging
> option you use.
>

Agreed that they are a giant pain. They don't quite require mentioning
every single file, as you can glob directories, but you do need to mention
every subdirectory, at least for package_data.

This is one of the things that prompted me to write a packaging tool called
'flit', which doesn't require this. I don't know that it's quite ready to
be pushed on people in a game skeleton, though.


> Another issue is that, using the python way pkg_resources from setuptools
> needs to be used at runtime. pkg_resources gets you access to the resources
> in an abstract way. Which means you need setuptools at runtime (not just at
> install time). There is already work going into keeping that separate here:
> https://github.com/pypa/pkg_resources So I'm not sure this will be a
> problem in the next months.
>

Ugh, I avoid pkg_resources at all costs. If you use package_data (as
opposed to data_files), it's not necessary; see my snippet above.


> I haven't confirmed if pkg_resources works with the various .exe making
> tools. I've always just used file paths. Thomas, does it work with Pynsist?
>

I haven't tried, but I'd guess it may well not work.


> Having game resources inside a .zip (or .egg) makes loading a lot faster
> on many machines. pkg_resources supports files inside of .egg files. So, I
> think we should consider this possibility.
>

I've heard this claim made before, but I haven't seen numbers. Having
resources inside a zip file is awkward if you need to pass a file path or a
file handle to other libraries: you have to extract it and write it to a
temporary file before you can pass it in. If the performance difference is
important, I'd favour writing some helper routines using the zipfile module
rather than doing anything with pkg_resources.

Re: [pygame] Promoting cheeseshop/pypi for game releases?

[Thomas Kluyver]

On 1 February 2017 at 06:31, René Dudfield  wrote:

> But now with free CI options... it seems more possible to make a tool
> which builds peoples apps for them. But again would require maintenance. By
> leaning on the python packaging infrastructure, we access to all the tools
> for packaging libraries.


I agree that leveraging the library packaging ecosystem to make app
packaging easier is a good idea. Part of why I pushed hard for pygame to
have wheels on PyPI (and a release ;-), is because that makes it very easy
to build a Windows installer with Pynsist. I'd be happy to help set up a
skeleton/example repo which uses Pynsist and a CI service like Travis to
build installers.

Eventually, I'd like it to be the case that game creators don't need to
build wheels or put their game on PyPI to distribute it. As you suggest, it
should be enough to upload the files to a website, or run something
locally, to build installers/packages for different platforms. But that
vision is clearly some way off, and I accept that PyPI is a decent interim
solution. Doing 'pip install bullet_dodger' (thanks Jorge for the example)
certainly beats unpacking a tarball and finding out about dependencies by
trial and error.

Thomas

[pygame] Pygame 1.9.3 released

[Thomas Kluyver]

I've just released Pygame 1.9.3 on Pygame. This is a bugfix release which
fixes a couple of key issues which came up with 1.9.2. It also adds wheels
for Python 3.6 on Linux, Mac and Windows.

Best wishes,
Thomas

Re: [pygame] Pygame 1.9.3?

[Thomas Kluyver]

On 11 January 2017 at 11:07, René Dudfield  wrote:

> Ah ok, cool. I thought you mentioned 32bit wheels didn't work because of
> something related to wheels. I'm working on getting the fixes upstreamed
> for 32bit. fluidsynth is the biggest one.


There is one annoying detail that's specific to wheels: because of the way
pip deals with 'fat' binaries on OSX, we need to tell it that our x64-only
wheels are x86+x64 (with the 'intel' tag), otherwise it won't try to
install them even where they do work. So if people with 32-bit-only Python
install it with pip, it will get installed and then fail to load with an
unhelpful error, rather than trying to install from source.

Thomas

Re: [pygame] Pygame 1.9.3?

[Thomas Kluyver]

On 11 January 2017 at 10:31, René Dudfield  wrote:

> As you say packaging can come after the release.
>

Do you want to do the 1.9.3 with Mac wheels or without? The people who
tested them before the release indicated they were working, and you always
hear disproportionately from the people having problems, so I think there's
a good chance that they're useful to people despite all the issues that are
coming up. On the one hand, it may be easier not to try to support Mac
wheels for now; on the other hand I think it's more likely that the
problems get solved if people are trying to use them.


> Some of the breakages for macOS require fixes in SDL, and packaging for
> 32bit requires much other work (seems whl doesn't work, so a .dmg could
> possibly be made again).
>

I don't think there's any reason .whl can't work for 32-bit code on Macs.
It's compiling the necessary dependencies that's the tricky bit, and trying
to make things work for older OSX versions. Those challenges are presumably
going to be the same however the code is packaged.


> I updated the milestones for those issues. I think you should now be able
> to modify milestones in bitbucket. Let's just assign milestones to things
> we do going forwards, and clean up the other ones as they are done.


Oops, I may have just gone through half of them clearing up milestones
before I read that. ;-)

Thomas

Re: [pygame] Pygame 1.9.3?

[Thomas Kluyver]

On 10 January 2017 at 00:21, René Dudfield  wrote:

> The mac problems are pretty severe... I'm looking into them right now.
> Maybe we can roll back some of the changes fairly easily, because it was
> working at least on the macs I tested with before the pre- release.


Could it be that it's the wheels that are the problem, and when you tested
the pre-release you installed from source? If the Mac wheel builds aren't
working, maybe we should do a release without them and leave it up to
downstream packagers (like Homebrew and Macports) to provide precompiled
packages for Macs.

> There's a few items still open in the 1.9.3 milestone. Let's set them to
another milestone if we're not going to do them.

There are a bunch still open in the 1.9.2 milestone. I don't think I have
the ability to create new milestones, nor to change milestones for more
than one issue at once.

Thomas

Re: SOLVED ... Re: [pygame] Python 2.7 with pygame on Mac Sierra (10.12.2)

[Thomas Kluyver]

On 10 January 2017 at 00:25, René Dudfield  wrote:

> I did have 32bit builds 'working' previously. I'm looking into how this
> works now, and why this was removed?


IIRC, some of the libraries we install from Homebrew did not offer a
universal build. I think there may have been some other issues too that
cleared up when we stopped trying to build 32-bit extensions.

> since I know of at least a few classrooms still using old 32bit macs

Do those old macs have OSX 10.9 or newer installed? Those are the only
versions our wheels work with in any case. Even that relies on an
undocumented Travis image which will be retired later this month; after
that the wheel builds will be for >= 10.10.

Re: [pygame] Pygame, images, and Macs

[Thomas Kluyver]

I know very little about Macs, but one thing I hear from experienced
Python+Mac users is that you shouldn't really use the built-in Python for
any of your own code. That should be left for system tools which use it,
and you should install another copy of Python (either from Python.org, or
Anaconda, or Homebrew/Macports) to run your code with.

On 9 January 2017 at 20:46, Bob Irving  wrote:

> Sorry for the confusion. Here's what happens sometimes:
>
> About 3/4 of the image shows, then shows a colored or vertical line. Rest
> of image doesn't display.
>
> We did a lot of searching about this, and it appears that Apple changed
> its Python image handling system in between 10.10 and 10.11.
>
> It makes sense.  But what we're wondering is if someone else has
> encountered this and knows a simple fix. The one thing that is recommended
> is to downgrade Python install, but we don't want to do that.
>
> TIA,
> Bob Irving
>
>
> On Sat, Jan 7, 2017 at 2:00 PM, Charles Cossé  wrote:
>
>> Yeah that's rather vague ... I'm on OSX 10.9.1 (forgot the name) and
>> never had a problem ... what about running from cmd line to see any output?
>>
>> On Sat, Jan 7, 2017 at 11:56 AM, Ian Mallett  wrote:
>>
>>> On Fri, Jan 6, 2017 at 8:16 AM, Bob Irving  wrote:
>>>
 We're using pygame in our CS classes here and have found that the
 built-in python (with Macs, which is what we use) works MOSTLY.

 The big snag seems to be image files. It doesn't seem to matter whether
 they are jpgs, pngs, etc. They sometimes display and sometimes don't.

 Our suspicion is that it is something in how either El Cap or Sierra
 processes image files that conflicts with pygame

 Has anyone found a solution?

>>>
>>> ​I'm not sure I apprehend the problem. In particular, "[t]hey sometimes
>>> display and sometimes don't" could mean any number of different things, and
>>> could be due to an error in your display code, invalid image data, bugs in
>>> PyGame or OSX, &c. Please explain more about how exactly it doesn't work.
>>> Ian​
>>>
>>
>>
>>
>> --
>>
>> Linkedin  | E-Learning
>> 
>>
>>
>>
>
>
> --
> Twitter: @birv2
> www.bob-irving.com
> http://www.scoop.it/t/on-the-digital-frontier
>
> Raspberry Pi Certified Educator
>

Re: [pygame] Pygame 1.9.3?

[Thomas Kluyver]

On 9 January 2017 at 20:45, Mikhail V  wrote:

> I will try to make a Pygame installation on recent Fedora over a weekend
> or so and if I notice something I'll let you know. Last time I did it
> was a year ago and things could change since then.
>

Thanks Mikhail. File an issue on Bitbucket if you can reproduce it, but if
it's an old issue, I'm not going to hold a release up for it.

Re: [pygame] Pygame 1.9.3?

[Thomas Kluyver]

On 8 January 2017 at 23:58, Mikhail V  wrote:

> I just remember I was unable to open grayscale PNGs on Linux (although on
> Windows I can do it without problems). I mean pygame.image.load() method.


Do you have the image that caused the problem, so other people can try to
reproduce it? Can you open an issue about it?

[pygame] Pygame 1.9.3?

[Thomas Kluyver]

Since 1.9.2, there have been a few crucial fixes committed:

- Add a missing file to the sdist, so it can be installed from PyPI without
using a wheel
- Fix a crash on Linux when playing ogg files.
- Add builds for Python 3.6

I'd like to make a 1.9.3 release to get these improvements out promptly.

Are there any other important things which we can fix quickly before making
a release? I know there are some Mac problems, but I can't debug those, so
unless someone steps up to tackle them, I don't want to hold the release up
for them.

René, are you happy to add me on PyPI (username takowl) so I can upload the
new release? If I don't hear from you, I'll ask Paul to do the upload again.

Thanks,
Thomas

Re: [pygame] Pygame 1.9.2 bug? | *** Error in `python3': double free or corruption (!prev): 0x00007f586c001b40 ***

[Thomas Kluyver]

Thanks Jorge, I've filed a bug here:
https://bitbucket.org/pygame/pygame/issues/323/double-free-error-on-linux-python-35

Any help working it out is welcome; I can't currently reproduce the error
on my Fedora system.

On 5 January 2017 at 23:52, Jorge  wrote:

> I ran into problems when I try to play a game using the latest pygame
> version from PyPI. It just happened to me with Hexoshi and I'm not sure
> if it's a pygame bug. The main developer of Hexoshi says it's a pygame
> 1.9.2 bug. Here is the log of the error and the discussion of the issue
> I submitted to Hexoshi issue tracker:
> https://gitlab.com/hexoshi/hexoshi/issues/4
>
> If this is a pygame bug, please someone submit it to Bitbucket pygame
> issue tracker, I don't have an account.
>
>

Re: SOLVED ... Re: [pygame] Python 2.7 with pygame on Mac Sierra (10.12.2)

[Thomas Kluyver]

Thanks Irv for following up on this.

As I understand things, we can only conveniently build pygame as a 64 bit
extension, but to make that installable on common Python installations, we
have to pretend it supports 32 bit operation as well (which it doesn't). We
thought this was unlikely to come up since all recent Macs are 64 bit; I
wasn't aware that there was a separate 32-bit only Python installer.

We should definitely document this. Unfortunately I don't know of anything
else we can do about it.

On 3 Jan 2017 1:48 a.m., "Irv Kalb"  wrote:

> After days of experimentation, I finally have a working environment.
>
> Reading through a bunch of posts where other people had encountered a
> similar problem, I found one post that said to try installing a different
> version of Python:  Mac OS X 64-bit/32-bit installe
> <https://www.python.org/ftp/python/2.7.13/python-2.7.13-macosx10.6.pkg>r
>  (I had been installing the 32-bit  version:  Mac OS X 32-bit i386/PPC
> installer
> <https://www.python.org/ftp/python/2.7.13/python-2.7.13-macosx10.5.pkg>).
>
> After installing that version, I then used this command to install the
> latest version of pygame (1.9.2)  (more recent the most recent one showing
> on the pygame install page):
>
>sudo pip install pygame
>
> The combination of those two installs allows me to run Python with pygame
> on Mac Sierra 10.12.2.
>
> This was extremely painful, and I would hope that this could be documented
> somewhere on the pygame installation page, so that someone with the same
> set up as me would not have to go through the same trial and error process.
>
> Irv
>
> On Dec 30, 2016, at 1:41 PM, Irv Kalb  wrote:
>
> To try to get pygame 1.9.2 installed easily (without any package
> managers), I tried doing the sudo install.
>
> The install soaked correctly:
> Collecting pygame
>   Downloading pygame-1.9.2-cp27-cp27m-macosx_10_9_intel.whl (4.8MB)
> 100% || 4.8MB 125kB/s
> Installing collected packages: pygame
> Successfully installed pygame-1.9.2
> IrvKalbs-MBP:~ irvkalb$
>
> But when I tried a simple import of pygame in the shell, it still fails
> (with the exact same message I saw earlier):
>
> Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 12:40:10)
> [GCC 4.2.1 (Apple Inc. build 5577)] on darwin
> Type "copyright", "credits" or "license()" for more information.
> >>> import pygame
>
> Traceback (most recent call last):
>   File "", line 0, in 
>   File "/Library/Frameworks/Python.framework/Versions/2.7/lib/
> python2.7/site-packages/pygame/__init__.py", line 133, in 
> from pygame.base import *
> ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/
> lib/python2.7/site-packages/pygame/base.so, 2): Symbol not found:
> _SDL_EnableUNICODE
>   Referenced from: /Library/Frameworks/Python.framework/Versions/2.7/lib/
> python2.7/site-packages/pygame/base.so
>   Expected in: flat namespace
>  in /Library/Frameworks/Python.framework/Versions/2.7/lib/
> python2.7/site-packages/pygame/base.so
> >>>
>
>
> I am open to any other suggestions to get pygame running on Sierra with
> Python 2.7.13.
>
> This should be easy ... but it is extremely frustrating that I've spent a
> few days trying to get this environment set up.
>
> Irv
>
>
>
> On Dec 29, 2016, at 2:34 PM, Daniel Foerster  wrote:
>
> I'm thinking you should probably throw a sudo on the front of that (or
> whatever the Mac equivalent is).
>
> On 12/29/2016 04:15 PM, Irv Kalb wrote:
>
>
> On Dec 29, 2016, at 8:42 AM, Thomas Kluyver  wrote:
>
> On 28 December 2016 at 23:41, Irv Kalb  wrote:
>
>> Also, when looking to find the latest version of pygame, on the pygame
>> downloads site, I see version 1.9.1.  But if I go to PyPi at
>>   https://pypi.python.org/pypi/Pygame#downloads
>>
>> It shows version 1.9.2.   But that shows a wheel file (.whl).
>>
>> Can anyone tell me if this is a more recent version that might fix the
>> problems that I am seeing?  And if so, is there a simple way to install a
>> .whl file without going through a terminal prompt?
>>
>
> 1.9.2 is the latest; unfortunately so far no-one has been able to update
> the downloads page.
>
> The normal way to use wheels (.whl files) is to 'pip install pygame' at a
> command line. I don't know of a way to install them without using the
> terminal, and I don't know anything about building Mac GUI installers.
> Sorry!
>
>
> Thanks very much for your response.  I cleared out my 1.9.1 version of
> pygame, and used pip.  Here's what h

Re: [pygame] Python 2.7 with pygame on Mac Sierra (10.12.2)

[Thomas Kluyver]

On 28 December 2016 at 23:41, Irv Kalb  wrote:

> Also, when looking to find the latest version of pygame, on the pygame
> downloads site, I see version 1.9.1.  But if I go to PyPi at
>   https://pypi.python.org/pypi/Pygame#downloads
>
> It shows version 1.9.2.   But that shows a wheel file (.whl).
>
> Can anyone tell me if this is a more recent version that might fix the
> problems that I am seeing?  And if so, is there a simple way to install a
> .whl file without going through a terminal prompt?
>

1.9.2 is the latest; unfortunately so far no-one has been able to update
the downloads page.

The normal way to use wheels (.whl files) is to 'pip install pygame' at a
command line. I don't know of a way to install them without using the
terminal, and I don't know anything about building Mac GUI installers.
Sorry!

Re: [pygame] A quick 1.9.3 release

[Thomas Kluyver]

On 26 December 2016 at 17:26, René Dudfield  wrote:

> @Lenard, @Thomas, please let me know your pypi usernames? I fixed the
> permissions for Paul... so he should be able to also add users on pypi.
>

My username is 'takowl'.


> I'm not sure why that mirror isn't updated... will look into it. I think
> the 'pygame' organisation on github should be used for the mirror (and
> other pygame things).


Do you control the 'pygame' org? If so, can you add extra admins? I'm
'takluyver' on Github.

I created a new org called 'pygame-org' because we didn't have access to
'pygame', but if we can get access it's better to use the obvious name.

Thanks,
Thomas

Re: [pygame] New pygame.org website

[Thomas Kluyver]

On 26 December 2016 at 18:49, René Dudfield  wrote:

> The download page can be updated with the same admin interface that
> someone managed to post news with. There's currently 6 users able to edit
> it... so I guess one of those did it. I added Paul and yourself now as
> well. See this issue on 'the website needs updates':
> https://bitbucket.org/pygame/pygame/issues/204/ Updating news, and
> community management is definitely a role which is useful, and needs to be
> shared amongst a few people. I'll track the 'make document of admin people'
> work in that issue.
>

Thanks! I don't see any admin link, though? Is there a special URL I need
to go to? My username on the site is takluyver, just in case you've given
admin permissions to another account.


> The open issue on the topic of dynamically generating the downloads page:
> https://bitbucket.org/pygame/pygame/issues/152 This needs a jinja2
> template, and a script which iterates over the 'downloads' repo. I'd
> suggest basing the html on the existing html. Whilst there are better
> layout options, that would be pretty easy to do for now, and is familiar
> for existing pygame downloads page users. There are more details to
> consider of course (like making an actual downloads repo and moving
> existing files in... and meta data for the files).
>
> There's been a couple of efforts to move the wiki into version control.
> There's even a wiki in the bitbucket version control, and scripts to
> convert the html into markup formats that bitbucket supports. (there's an
> issue open on this topic). However, in practice, way less people
> updated it without a gui (Yes, even markdown and rst is a turn off for
> quick edits). Pointing them to the bitbucket interface also meant very few
> edits. I think it was 5-10x less edits. Furthermore even requiring a login
> means 5-10x less edits (100x if you include the deluge of spam). When those
> numbers are multiplied together... it meant a tiny amount of wiki edits
> were happening. Then the bitbucket wiki started getting spammed to hell,
> but we didn't have tools to moderate it. Along with the edits dropping
> close to zero, I moved things back to the website wiki. But now there are
> pretty good web gui tools for markdown. Here's the issue on the wiki
> topic... but it needs a lot more thought on the topics of spam and ease of
> use. https://bitbucket.org/pygame/pygame/issues/153/wiki-website-
> generation-from-wiki-repo
>
> Burn out for the website admins, and website defacement because of spam
> means that a workable solution for spam prevention needs to be in place
> first for any wiki replacement.
>
> Keeping the existing game data for me, and a lot of project authors is
> very important. For me the main purpose of the website should be to help
> people making games have a community of makers. Showing your work is often
> one of the only rewards for making these projects in the first place.
> Seeing people upload their game to a website for the first time, I always
> see a grin on their face.
>

OK, it sounds like we'll need to build on the old site more than creating a
new one, then. What is available on the server (e.g. Python version)? Could
you give other people SSH access to it?

Thanks,
Thomas

Re: [pygame] Promoting cheeseshop/pypi for game releases?

[Thomas Kluyver]

My tldr: PyPI and pip are the wrong tools for game distribution, there are
better places to focus effort.

If the instructions to get your game say 'pip install yourgame', you're
limiting your audience to people who have Python installed and are
comfortable with the command line. Even among those people, you may find
yourself having to explain about using pip3 on some systems, or about why
running 'sudo pip ...' is a bad idea.

PyPI and pip exist primarily to distribute Python libraries. We use them
secondarily to distribute command-line tools, because it's a quick and easy
alternative to building packages for different platforms, and the kind of
people who use a tool like 'nosetests' know how to install it with pip.
They're not a good fit for GUI applications where the user shouldn't need
to know that Python is in use.

So, where do I think we should focus effort?


   - Tools to package up Python *applications* into convenient installable
   bundles
  - Shameless plug: Pynsist is a tool I made to build Windows
  installers.
  - I'd particularly like to see work around the new Linux application
  packaging formats, Flatpak and Snappy. Can we make a tool that takes some
  form of description and builds both kinds of package?
  - The BeeWare projec (http://pybee.org/ ) is doing some interesting
  work on packaging for mobile platforms.
  - Stretch goal: can we start with a single application description
  and build packages for various platforms? I'm sceptical, but it would be
  cool, even if the packages lacked some polish.
  - Guides on preparing & submitting games to various app marketplaces:
  - Platform owners: Microsoft, Apple, Google, Canonical...
  - Third party: Steam, Itch...
   - (Maybe) A better catalogue of non-professional games, for creators who
   may not want to put their games up on Steam or whatever. I'm still unsure
   if there's an actual gap to be filled here, though, and what shape it is if
   it exists.


Thomas

On 25 December 2016 at 00:52, René Dudfield  wrote:

> Hello,
>
> tldr; promote using pypi and pip for game releases?
>
>
> With all the great work from lots of people pygame is often easily
> installable via pip - the standard python packaging system. We still have
> some issues, but it works quite well on major platforms.
>
> Now our games can be installed with pip too!
>
> *pip install yourgame*
>
> Since many people enter the python world via games, it makes sense that
> they get used to publishing python packages as well. I've sat in python
> groups, and still 75% of the room has never published a python package
> despite many of them working with python every day.
>
> As a game developer why should I use pip? Firstly, there is a very large
> audience of people who can install python games. You don't need to worry
> about the platform issues of binaries so much. If they have pip on their
> platform, then they can install your game. Other benefits of publishing on
> pypi include syndication, since many people tweet and copy all the releases
> on pypi. Another benefit is all the infrastructure work that goes into
> pypi, CDN networks and such.
>
> I suggest efforts should be applied to:
>
>- updating tutorials, and spreading the idea of publishing python
>games to the cheeseshop (pyweek, pygame.org tutorials, external
>tutorials, books, youtube videos)
>- base code for a pygame game in a standard structure (skellington,
>cookiecutter etc)
>- contacting other python game communities to suggest pypi should be a
>priority
>- making the cheeseshop/pypi itself a better platform for game
>publishing needs
>
> What pypi doesn't do currently? It doesn't do many things that a good game
> release system would do. Video/youtube links, and even screenshots aren't
> available. Discussion has been disabled (they found it way too hard to
> moderate). Even ratings are not on there (which can help for
> discover-ability). Another issue is that closed source things aren't really
> looked apon nicely there(but it is allowed). Finally, packaging in python
> still isn't the easiest thing (it's definitely not as easily as uploading a
> zip file, but it is waay nicer now than ever before).
>
> Any work that goes into making the packaging system for python better for
> games helps out with other python game communities as well. We can perhaps
> even gain allies from the other communities to help improve things for
> games in general.
>
> Here are where the pypi projects live.
>
>- https://github.com/pypa
>- (current pypi) - https://github.com/pypa/pypi-legacy
>- (next gen pypi) - https://github.com/pypa/warehouse
>
>
>

Re: [pygame] New pygame.org website

[Thomas Kluyver]

On 25 December 2016 at 03:30, René Dudfield  wrote:

> I've been non contactable for a few weeks due to personal issues. Which I
> guess was frustrating to Thomas, which has led to this latest effort to
> make a new website.
>

I'm glad to see you back; I was a bit worried that something had happened
to you. I hope things are OK.

Truth be told, the website has been frustrating me for quite a long time,
but your absence really highlighted the need for something that doesn't
depend on a single person maintaining it, and I have seen on the mailing
list that there's a lot of talent and enthusiasm that could be harnessed if
the website was a more collaborative project.

>
>- most parts of the website can be updated (by wiki, bitbucket,
>stackoverflow, etc)
>
> This is a good point, and I should update the 'Getting Started' page on
the wiki. I cannot, however, see a way to update the all-important Download
page.

>
>- we need to document who has access to which admin things (there are
>a few people who have access to everything, but I guess not everyone knows
>each other, and some people go inactive some times)
>
> +1. For instance, you mentioned that users jmm0 and TheSheep also have
admin access to Disqus, but those usernames don't obviously relate to
anyone I remember on the mailing list or on Bitbucket, so I'm not sure who
they are or how to contact them.

>
>- moderation, respect and spam are issues we need to work on.
>
> +1. I hope you don't feel that our efforts to build a replacement site in
your absence were disrespectful :-)

> Looking forward to moving forward on the new website!
>
How would you like to see the transition happen? Now that you're back we
can presumably make some updates to the current site, which reduces the
pressure to replace it. I'd still like to see things like the download page
generated from files in version control, so that people can update them
through pull requests. My inclination is to move the wiki content into
version control as well.

For the game feed and the login system, how important do you think it is to
maintain the data from the old site? We could try to build a Python web
application around the same database, and then switch over to it. That
would be significantly more work than making a new system from scratch, but
it means a smoother transition, and preserves the existing archive. Do you
want to keep using the current server for dynamic parts of a new site, or
move pygame away from it?

Thanks,
Thomas

Re: [pygame] A quick 1.9.3 release

[Thomas Kluyver]

On 25 December 2016 at 21:32, René Dudfield  wrote:

> I think we should rotate who does the release... so more people can get
> the hang of it, and so we can better document it as we go.
>

+1. I see two keys pieces that we need to streamline for this to work:

1. PyPI access. At the moment, only you (René) and Paul Craven can upload
releases, and only you can add new people. Please can you add some more
uploaders, e.g. Peter Shinners, Lenard Lindstrom or myself. And can you
give at least one other person the 'owner' role, which allows them to add
other uploaders in the future?

2. Github mirroring. You had an automatically updating mirror under your
username, but it stop updating some time ago. I've been manually updating
my own mirror to build the OSX wheels. I'd like to have a mirror under the
new pygame-org Github org I created, and have the automatic updates running
somewhere where multiple people can fix it if it goes wrong.


> Any volunteers to be the next release manager? We can guide whoever it is
> through the processes (and document the bits that aren't documented)


I'm happy to do it in principle, but I'm checking email quite sporadically
over the next couple of weeks because of Christmas and New Year's
celebrations. So if somebody else can spend more time working on it, it's
probably best for them to do this release.

Thanks,
Thomas

Re: [pygame] A quick 1.9.3 release

[Thomas Kluyver]

Welcome back, René! +1 to doing a 1.9.3 release soon. Do you see how to get
wheels for the various platforms? I'm happy to help build them again, but
it won't be today.

Have a good Christmas, everyone!

Thomas

On 24 Dec 2016 11:43 p.m., "René Dudfield"  wrote:

> Hello,
>
> we need to do a quick 1.9.3 release because of the source tar ball being
> broken for 1.9.2. I don't think this should wait for other issues like
> python 3.6 updates or such.
>
> Sound like a plan?
>

Re: [pygame] New pygame.org website

[Thomas Kluyver]

I have created an org called pygame-org, and invited everyone who has sent
me their username (if I've missed someone, please let me know).

https://github.com/pygame-org

I'm not going to be looking at it much for a couple of weeks, but feel free
to start working things out.

On 24 December 2016 at 00:20, Radomir Dopieralski 
wrote:

> Note that I don't have a problem with the need to have a Github (or
> Bitbucket) account to contribute to PyGame or its website themselves --
> you have to use the tools that the project choose to contribute to that
> project, and in a pinch you can always send your patches by e-mail. But
> forcing all members of the PyGame community to become Github's
> customers somehow feels different.
>

For all the reasons you list, I don't intend that the game feed be limited
to games hosted on Github. I would like it to work much as it does on the
current site: game developers supply a screenshot and a link, and can host
their game (free or commercial) wherever they like.

With the system as proposed, game developers will at first need a Github
account to list their games on the feed. I don't think that's a problematic
requirement, any more than needing a Bitbucket account to file a bug on
Pygame. But we may be able to avoid even that requirement in the future
with a submission interface that talks to Github on the user's behalf.

Thanks,
Thomas

Re: [pygame] New pygame.org website

[Thomas Kluyver]

On 23 Dec 2016 10:49 p.m., "Luke Paireepinart" 
wrote

 The advantage I see of requiring users to host at github in a separate
repo vs allowing arbitrary hosting is that you do not have to worry about
spam links nearly as much. Just ask user for the repo name and that's it.
The script that processes the requests can then verify that the provided
name is a valid github repo and that it meets the standard guidelines and
pull the readme in automatically as well as the link.


I'm not particularly keen on requiring that the games be hosted on github,
but if they add it to our listing with a github pull request, I don't think
we'll have an issue with spam.

So has anyone started on any of this? is there some community controlled
github that we could start with?  I'd be interested in contributing some
effort to this.


Not yet, but I think I'll create a github org in the morning (Europe time).
Writing from my phone now, about to sleep. Thanks for volunteering!

Anyone who's interested in contributing to this site, send me an email with
your github username so I can add you to the org when I create it. :-)

Re: [pygame] New pygame.org website

[Thomas Kluyver]

On 23 Dec 2016 9:47 p.m., "Radomir Dopieralski"  wrote:

Let's first build the simplest possible thing, and we can refine it and
add bling if we have spare resources for that.


+1. I'm not against making a fancy front-end if people are willing to
maintain it, but I'm a big fan of building something simple at first, and
then adding features later.

As a side note, what are we going to do with the existing game list?
Are we going to import/migrate it to the new website?


I'm not sure. I think we'd transfer at least a few of the recent ones to
seed the new list. We can go further back if someone wants to scrape it. I
see it more as a way to showcase new games and tools rather than an
archive, but other people may disagree.

I hope that the old site will remain accessible after the DNS changes at
something like old.Pygame.org, for as long as that server stays up.

Re: [pygame] pygame.pixelcopy.array_to_surface(Dest, Src) not working

[Thomas Kluyver]

On 23 December 2016 at 00:04, Mikhail V  wrote:

> pygame version: 1.9.2a0, Windows 7, python 2.7.12


Can you try with 1.9.2, which was released recently? If you still see the
error, make sure there's an issue open for it on Bitbucket.

Thanks,
Thomas

Re: [pygame] New pygame.org website

[Thomas Kluyver]

Hi Miriam,

Looking at ibiblio.org, it's talking about an application process to host a
'collection' there ("A decision will be made and you will be notified.").
This sounds rather controlled for a simple static site, and I'm concerned
that it won't be as easy as we want to update the site and for multiple
people to work on it. Clicking around the distros section, it looks like
most distros host downloads there but have a website somewhere else (so
far, Fat Dog is the only one I've found with web pages there). This
suggests to me that it's not ideal for hosting a website.

It's hard to put my finger on what's wrong with it, because clearly you
*can* host static web pages there. But looking around the information pages
and the Q&A site, I get a very strong feeling that hosting there would
involve a lot of time and hassle that I don't want.

Similarly for archive.org, I think it's intended as... well, an archive!
That's valuable, but it's not the problem we're trying to solve.

Github pages is a very convenient way to host a website, and to manage
multiple people making changes to it. I know a lot of open source projects
whose websites are hosted this way. It does require using git to update the
site, and I'm sorry if that's difficult for you, but it's a system that
works well for a lot of people. None of the arguments I've read so far
provide a compelling reason *not* to host a site on Github, and the only
option that I see as a reasonable alternative is Gitlab, which presumably
works in a very similar way to Github.

> Is it possible to have something that is safe, but easy for newbies to
add games to a site?

I think it is, if we accept that it just needs to be 'safe enough'.
Automatically adding 'nofollow' on user provided links reduces its value to
spammers a lot. I believe Google's recaptcha tool does a reasonable job of
stopping bots. And if it's still not enough, we can authenticate users and
require an admin to approve a user's first submission.

Thomas

On 23 December 2016 at 01:45, Miriam English  wrote:

> The two repositories I mentioned, ibiblio.org and archive.org (I'm sure
> there are more) have, as far as I know, no limits on storage.
>
> Have a look, for instance at the amount stored for Puppy Linux at ibiblio:
> http://distro.ibiblio.org/puppylinux/
>
> Each of those subdirectories you see relates to a different kind of Puppy.
>
> The packages directories contain programs specifically tailored for a
> particular distribution of Puppy. The pet_packages-lucid directory alone
> contains more than 10 Gigabytes of programs, and there are more than 30
> Puppy distros with associated package collections.
>
> The puppy-528 directory contains a couple of ISO CD images for Puppy Lucid
> 528. It also contains an explanatory webpage:
> http://distro.ibiblio.org/puppylinux/puppy-5.2.8/release-Lucid-528.htm
>
> Most of the main distro directories contain such a page.
>
> There is lots more on ibiblio, as a quick wander around
> http://distro.ibiblio.org/ will show.
> They also have multiple mirrors around the world, so if one set of servers
> has a problem others are available.
>
> Cheers,
>
> - Miriam
>
>
> Charles Cossé wrote:
>
>> Hi,
>>
>> On Thu, Dec 22, 2016 at 2:02 PM, Miriam English > <mailto:m...@miriam-english.org>> wrote:
>>
>> I don't see the point of using github for the web pages and
>> keeping the content elsewhere. I don't have a lot of experience
>> using github (I find it a pain actually). Github is intended as a
>> versioning system. That has no utility for a pygame repository, as
>> far as I can see -- or at least no advantage over an ordinary
>> repository built purely with that purpose in mind.
>>
>> Wouldn't it be simpler to keep the whole thing in a repository? I
>> mentioned 2 earlier: archive.org <http://archive.org> and
>> ibiblio.org <http://ibiblio.org>, both of which are free and very
>>
>> secure.
>>
>>
>> I can say a little bit that might help until someone with more knowledge
>> has time to reply ... With GitHub pages your website is "just another"
>> repo.  That's the main thing I wanted to point out.  There are no storage
>> limits, and I'm pretty sure that GitHub would be happy to help pygame
>> accomodation-wise if pygame needed anything special (within reason).   I
>> also know that there is a 4 gigabyte file limit on GitHub.  (I know this
>> because I once wanted to host an 8G SD card image and had to get it down to
>> 4G in order to be housed on GitHub).
>&g

Re: [pygame] New pygame.org website

[Thomas Kluyver]

On 22 December 2016 at 16:13, Charles Cossé  wrote:

> I suspect that there are many people, me included, who are familiar with
> parts of the plan you have described, but not all.  For example, knowing
> how to setup GitHub pages, but never having done the daily feed part, or
> not completely clear about static "generation".   So this could become a
> learning experience for a lot of people, if only just as observers.  What
> do you think about taking the extra trouble to make the effort somewhat of
> a class on how to do all these things?


I'm definitely on board with it being a learning experience for people,
though I'd like those people to be more participants than observers! I do
not have the time to build this site myself, so I'm relying on the good
people of this mailing list to make it happen, and trying to limit myself
to coordinating things to make it possible. So if you know anything at all
about HTML or Github pages, and you're willing to learn, you're definitely
welcome.

To expand on what I mean by 'static site generators': a static website is a
set of HTML files, which don't need to run any code on the server. But
editing HTML by hand when you want to change something is a pain. So a
static site generator is a tool which combines HTML templates with content
in a simpler markup language like markdown or restructuredtext, to generate
the HTML pages. A maintainer builds the site and uploads the new pages,
whereas a dynamic web application like Wordpress generates the HTML on the
server. There are loads of different SSGs (it's quite easy to make a simple
one), but Nikola & Pelican are two popular Python ones.

Re: [pygame] New pygame.org website

[Thomas Kluyver]

Thanks everyone for your input. In the interests of making progress, I'd
like to propose:

- The informational site will be hosted on Github pages; I've used this for
a number of websites before, it's reliable, we can point an external domain
to it, and I imagine that most of the likely contributors have Github
accounts already.
- The pages will be generated by a Python static site generator. There
doesn't seem to be a strong feeling between Sphinx/Nikola/Pelican, so it
will likely depend on who is most excited to start building it.
- The game feed will also be generated from content in Github, so *at first*
developers will need to submit a PR to add a game. Once that's working, we
can build a simpler submission interface on Heroku/Appengine/similar which
can push content to Github. Ideally the data will be in a format which
would could move elsewhere later if necessary.

I like the concept of drawing the game feed from an external source, but I
don't think any of the sources proposed match what we want closely enough.

Does anybody object to any of those proposals?

Thanks,
Thomas

On 18 December 2016 at 20:18, Miriam English  wrote:

> http://ibiblio.org is an enormous, free repository that also lets you
> have static webpages. Many of the Linux distros are hosted from there as
> well as much else too. I don't know how you'd set up a comments system
> there. It may be possible.
>
> http://archive.org is another gigantic free repository. They already have
> a comments system built into their pages. I don't know how it works. It
> might be worth checking out.
>
> Both these organisations are free and are aimed at helping make content
> available to the community which might otherwise be lost. You have complete
> control over the look of webpages at ibiblio.org because you simply
> upload static pages.
>
> I don't know how much control over the look archive.org provides because
> everything is dynamically served from xml data, I think. It might be
> possible to add static content, I don't know.
>
> But both are free, permanently available, and have excellent security.
>
> Cheers,
>
> - Miriam
>
>
>
> Peter Shinners wrote:
>
>> Gitlab also has great static site support for free, and you can use
>> custom domains. They also make it easy to run most static generation tools
>> as a CI job. Although part of me thinks just pushing the static content is
>> easiest. It sounds to me like there's a list of acceptable hosting choices
>> that won't cost anything.
>>
>> Keeping the games list as a feed from other service sounds like it has
>> the best chance of working.
>>
>>
>> On 12/17/2016 10:51 PM, Lenard Lindstrom wrote:
>>
>>> Bitbucket also has static web site support. I set one up for the Pygame
>>> docs awhile ago, but have not maintained it:
>>>
>>> http://pygame.bitbucket.org/docs/pygame/
>>>
>>> The repository is here:
>>>
>>> https://bitbucket.org/pygame/pygame.bitbucket.org
>>>
>>> Lenard Lindstrom
>>>
>>> On 16-12-17 09:16 PM, Daniel Foerster wrote:
>>>
>>>> You know, I suppose we could just use GitHub pages.
>>>>
>>>> On Dec 17, 2016 17:32, "Charles Cossé" >>> cco...@gmail.com>> wrote:
>>>>
>>>>
>>>>
>>>> On Sat, Dec 17, 2016 at 4:12 PM, Daniel Foerster
>>>> mailto:pydsig...@gmail.com>> wrote:
>>>>
>>>> Using S3/CloudFront is a lot cheaper than the EC2 setup you're
>>>> imagining (and which a Django stack would require).
>>>>
>>>>
>>>>
>>>> I never said to use Amazon at all.  Just use the current server,
>>>> whatever it is (unless it's Amazon).
>>>>
>>>> On 12/17/2016 05:11 PM, Charles Cossé wrote:
>>>>
>>>>> Yikes!  who's gonna pay the Amazon bill?
>>>>>
>>>>> On Sat, Dec 17, 2016 at 4:09 PM, Paul Vincent Craven
>>>>> mailto:p...@cravenfamily.com>> wrote:
>>>>>
>>>>> If most of the site is static, then I think Django would
>>>>> be overkill. The static portion of the site can easily be
>>>>> deployed via Amazon S3/CloudFront and then we'd not have
>>>>> to maintain a server.
>>>>>
>>>>> Paul Vincent Craven
>>>>>
>>>>> On Sat, Dec 17, 2016 at

Re: [pygame] New pygame.org website

[Thomas Kluyver]

On 18 December 2016 at 19:07, Charles Cossé  wrote:

> Rather than ditch disqus altogether, I would be willing to write to them
> and ask if they wouldn't consider giving pygame a special version without
> ads.  What do you all think about that?  Doesn't have to be me, either, but
> just to complete the idea.


I have a disqus account for my blog, and it looks like the ads can be
disabled in the disqus control panel. They only serve them on sites with
enough traffic in the first place, so I can't test.

Does anyone have access to the Disqus account for Pygame so we can try to
turn these off?

The ads they're serving when I look are such trashy clickbait that I'm
inclined to avoid the service entirely for new sites. If that's how they're
going to make money, I want no part of it.

Re: [pygame] New pygame.org website

[Thomas Kluyver]

Ah, the 'sponsored links' are coming from the Disqus comment service.
That's disappointing, I thought they were better than that. If that's the
price of Disqus comments,  I think we should avoid using them.

On 18 December 2016 at 10:36, Thomas Kluyver  wrote:

> Yuck. I always use an adblocker, so I hadn't seen the 'sponsored links'
> until now. I agree that they're hideous, and we definitely shouldn't have
> them on the new site. I wonder if they were put on there deliberately, or
> if the site has been compromised.
>
> On 18 December 2016 at 09:42, Charles Cossé  wrote:
>
>> Would it be possible to eliminate those unsightly "sponsored links"
>> advertisements going forward?
>> I just logged-in for first time in 2 years and there's Donald Trump and
>> Angelina Jolie on my project page
>> <http://www.pygame.org/project-Tux+Math+Scrabble-118-449.html> ... yikes!
>>
>> On Sun, Dec 18, 2016 at 1:58 AM, Thomas Kluyver  wrote:
>>
>>> It doesn't look like bitbucket sites support custom domains, so if we
>>> want it to become pygame.org, we'd have to host it on github rather
>>> than bitbucket. Gh does support bringing your own domain.
>>>
>>> On 18 Dec 2016 8:49 a.m., "Thomas Kluyver"  wrote:
>>>
>>>> There are a couple of things being discussed that I think have easy
>>>> answers.
>>>>
>>>> Docs will remain in sphinx, whatever we do with the rest of the
>>>> website. They're already using sphinx, and Nikola/Pelican are not decent
>>>> alternatives for that part.
>>>>
>>>> Hosting for the static part will be on github pages or bitbucket. Free
>>>> hosting is one of the key advantages of a static site. I've used both of
>>>> these for web sites before.
>>>>
>>>>
>>>> On 18 Dec 2016 7:02 a.m., "Lenard Lindstrom"  wrote:
>>>>
>>>>> I was looking at Pelican: http://blog.getpelican.com/
>>>>>
>>>>> It looks like Sphinx lite for web sites. Page content can be reST,
>>>>> Markdown, or AsciiDoc. Jinja templates are used for page generation.
>>>>>
>>>>> On 16-12-17 02:26 PM, Thomas Kluyver wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> So far, I think the proposals for the static information part of the
>>>>>> site are Nikola (a static site generator oriented around blogs) and 
>>>>>> Sphinx
>>>>>> (oriented around docs). Both are written in Python. Does anyone want to
>>>>>> make the case for any other system?
>>>>>>
>>>>>>
>>>>>
>>
>>
>> --
>>
>> Linkedin <https://www.linkedin.com/in/charles-cosse> | E-Learning
>> <http://www.asymptopia.org>
>>
>>
>>
>

Re: [pygame] New pygame.org website

[Thomas Kluyver]

Yuck. I always use an adblocker, so I hadn't seen the 'sponsored links'
until now. I agree that they're hideous, and we definitely shouldn't have
them on the new site. I wonder if they were put on there deliberately, or
if the site has been compromised.

On 18 December 2016 at 09:42, Charles Cossé  wrote:

> Would it be possible to eliminate those unsightly "sponsored links"
> advertisements going forward?
> I just logged-in for first time in 2 years and there's Donald Trump and
> Angelina Jolie on my project page
> <http://www.pygame.org/project-Tux+Math+Scrabble-118-449.html> ... yikes!
>
> On Sun, Dec 18, 2016 at 1:58 AM, Thomas Kluyver  wrote:
>
>> It doesn't look like bitbucket sites support custom domains, so if we
>> want it to become pygame.org, we'd have to host it on github rather than
>> bitbucket. Gh does support bringing your own domain.
>>
>> On 18 Dec 2016 8:49 a.m., "Thomas Kluyver"  wrote:
>>
>>> There are a couple of things being discussed that I think have easy
>>> answers.
>>>
>>> Docs will remain in sphinx, whatever we do with the rest of the website.
>>> They're already using sphinx, and Nikola/Pelican are not decent
>>> alternatives for that part.
>>>
>>> Hosting for the static part will be on github pages or bitbucket. Free
>>> hosting is one of the key advantages of a static site. I've used both of
>>> these for web sites before.
>>>
>>>
>>> On 18 Dec 2016 7:02 a.m., "Lenard Lindstrom"  wrote:
>>>
>>>> I was looking at Pelican: http://blog.getpelican.com/
>>>>
>>>> It looks like Sphinx lite for web sites. Page content can be reST,
>>>> Markdown, or AsciiDoc. Jinja templates are used for page generation.
>>>>
>>>> On 16-12-17 02:26 PM, Thomas Kluyver wrote:
>>>>
>>>>>
>>>>>
>>>>> So far, I think the proposals for the static information part of the
>>>>> site are Nikola (a static site generator oriented around blogs) and Sphinx
>>>>> (oriented around docs). Both are written in Python. Does anyone want to
>>>>> make the case for any other system?
>>>>>
>>>>>
>>>>
>
>
> --
>
> Linkedin <https://www.linkedin.com/in/charles-cosse> | E-Learning
> <http://www.asymptopia.org>
>
>
>

Re: [pygame] New pygame.org website

[Thomas Kluyver]

It doesn't look like bitbucket sites support custom domains, so if we want
it to become pygame.org, we'd have to host it on github rather than
bitbucket. Gh does support bringing your own domain.

On 18 Dec 2016 8:49 a.m., "Thomas Kluyver"  wrote:

> There are a couple of things being discussed that I think have easy
> answers.
>
> Docs will remain in sphinx, whatever we do with the rest of the website.
> They're already using sphinx, and Nikola/Pelican are not decent
> alternatives for that part.
>
> Hosting for the static part will be on github pages or bitbucket. Free
> hosting is one of the key advantages of a static site. I've used both of
> these for web sites before.
>
>
> On 18 Dec 2016 7:02 a.m., "Lenard Lindstrom"  wrote:
>
>> I was looking at Pelican: http://blog.getpelican.com/
>>
>> It looks like Sphinx lite for web sites. Page content can be reST,
>> Markdown, or AsciiDoc. Jinja templates are used for page generation.
>>
>> On 16-12-17 02:26 PM, Thomas Kluyver wrote:
>>
>>>
>>>
>>> So far, I think the proposals for the static information part of the
>>> site are Nikola (a static site generator oriented around blogs) and Sphinx
>>> (oriented around docs). Both are written in Python. Does anyone want to
>>> make the case for any other system?
>>>
>>>
>>

Re: [pygame] New pygame.org website

[Thomas Kluyver]

There are a couple of things being discussed that I think have easy answers.

Docs will remain in sphinx, whatever we do with the rest of the website.
They're already using sphinx, and Nikola/Pelican are not decent
alternatives for that part.

Hosting for the static part will be on github pages or bitbucket. Free
hosting is one of the key advantages of a static site. I've used both of
these for web sites before.


On 18 Dec 2016 7:02 a.m., "Lenard Lindstrom"  wrote:

> I was looking at Pelican: http://blog.getpelican.com/
>
> It looks like Sphinx lite for web sites. Page content can be reST,
> Markdown, or AsciiDoc. Jinja templates are used for page generation.
>
> On 16-12-17 02:26 PM, Thomas Kluyver wrote:
>
>>
>>
>> So far, I think the proposals for the static information part of the site
>> are Nikola (a static site generator oriented around blogs) and Sphinx
>> (oriented around docs). Both are written in Python. Does anyone want to
>> make the case for any other system?
>>
>>
>

Re: [pygame] New pygame.org website

[Thomas Kluyver]

On 17 December 2016 at 20:40, Alex Z.  wrote:

> More important: I think it would be cool to do a real brainstorming about
> creative ideas together, as everyone has an own vision and arguments for
> how the site should be and mail is such a slow medium.
> Maybe we can do a Skype call, Google hangout or whatever soon so as many
> people as possible really get involved.
> However we would need a moderator to structure the call and protocol the
> answers. I would suggest Thomas, as he has the most experience with pygames
> history and maintaining its resources.
>

I should make it clear that I have very little experience with maintaining
Pygame. I turned up earlier this year to pester people into making a
release. But I'm happy to co-ordinate getting this work off the ground. :-)

I have my reservations about a video chat: it's hard to include everyone,
especially as we're spread across widely spaced time zones. Although email
is slower, the asynchronous communications give everyone a chance to weigh
in. But if people agree that a video chat would be helpful, I'll try to
arrange that.

So far, I think the proposals for the static information part of the site
are Nikola (a static site generator oriented around blogs) and Sphinx
(oriented around docs). Both are written in Python. Does anyone want to
make the case for any other system?

Summarising ideas on the game feed part:
- Maybe it could also be static, so you make a pull request to submit a game
- Others said please don't do that, because it's too difficult for game
developers
  - [I agree with both groups. I wonder if we could make a web form which
turns the input into a git commit plus pull request...]
- Alternatively, we could populate it with data from other sources; either
mechanisms for software generally (PyPI, Openhub), or specific to games
(Steam, itch.io, gamejolt)
  - [My thoughts: the general sources don't seem a great fit; it's rare to
upload screenshots to these, and even if developers did, we would have to
scrape them from free text. Pulling from game stores would mean games have
to clear a much higher bar of quality and polish than many of the current
entries on the feed. That is up for discussion, but I like the current
amateur-friendly feel of the feed. If you just want polished games to play,
it wouldn't matter that they're in Python]

Thomas

Re: [pygame] Pygame 1.9.2 released!

[Thomas Kluyver]

On 17 December 2016 at 07:54, DiliupG  wrote:

> so does this mean we are stuck forever with 1.9.something and the old sdl
> library? :(


Well, if you want SDL2, you can use pygame_sdl2. ;-)

At the moment, I don't see any advantage to porting the pygame codebase to
SDL2, when pygame_sdl2 already exists. It seems like development energy
would be better spent improving compatibility, adding features to
pygame_sdl2, and helping the two projects to share code. If there's some
advantage to making another SDL2 port, we could look at that, but it sounds
like a lot of work, so a compelling reason would be needed.

In terms of version numbers, I could see the SDL1.2 based pygame making
releases like 1.10, 1.11, and so on. We'd probably avoid making 2.x because
of the potential for confusion.

Thomas