Re: [pygame] pygame with SDL2 proposal

[Leif Theden <leif.theden@xxxxxxxxx>]

I think that rewriting the extension modules in cython would be a great way to make the project accessible to new developers.  

Writing extensions in C, as it is now, requires that developers have 1. Good C skills, 2. Understanding of the Python C library, 3. Knowledge of the SDL library, 4. Understanding of low-level details about the platforms it supports, and finally, 5. a good sense of how pygame works.

If you can imagine those skills charted as a Venn diagram, it's not difficult to understand why it is hard to maintain pygame as is, because only a handful of people have those skills and actually care. 

Cython is not difficult to learn and looks like Python.  It would be less of a barrier of entry for new developers to contribute. 

Also, let's not forget that C in general is losing mindshare, as new developers tend to learn JS, java, and Python for their classes.

At that point however, Toms python_sdl2 is already doing that so, where does that leave pygame2?

If cython is chosen, better to let pygame 1.9 die gracefully and move on to a better platform and not duplicate effort (by moving to python_sdl2).  

Good night, sweet prince, in that case.

On Sun, Mar 19, 2017 at 5:02 PM Lenard Lindstrom <len-l@xxxxxxxxx> wrote:

Hi René and everyone else,

I like this approach. My patches achieve the first step, using SDL2. The
next step is to introduce new SDL2 features as new modules and classes.

I suppose the SDL2 patches can be incorporated as conditionally compiled
code. They can be added one at a time, but must all be in place to work
properly. Then any new Pygame modules will expose SDL2 features only, so
not be built for SDL1.

As a long term goal SDL1 can be removed and SDL1 legacy modules
reimplemented on top of the SDL2 specific code.

Is there any reason new modules should not be written in Cython? If not
then we could try to use parts of pygame_sdl2 to quickly introduce SDL2
specific features.

Lenard Lindstrom


On 17-03-18 05:02 AM, René Dudfield wrote:
> Hello,
>
> so, I've spent some more time reading source code, and investigating
> SDL2 and the options a lot.
>
> I *think* this plan below could be the best way forward for us.
>
> tldr;
>  * have a single source SDL1, and SDL2 code base with a compile time
> option. (like we have single source py2 and py3).
>  * move bitbucket/pygame repo to github/pygame.
>
>
> Rather than reimplementing everything, and introducing lots of
> compatibility bugs, Instead I think a gradual approach would work
> better. I'm starting to think that perhaps pygame_sdl2 by Tom, is not
> such a great way forward (for the pygame project, I think it was
> necessary and good for Ren'Py).
>
> A big breaking change is kind of silly for how little resources we
> have. Python 3 managed to pull it off... after a decade, and with
> massive resources having poured into it. And it only took off once
> they put compatibility code back in. Here's the thread where some
> discussion has been happening.
> https://bitbucket.org/pygame/pygame/issues/174/pygame-20-the-sdl2-edition
>
>
> What we do have is some patches to get the current code base working
> with SDL2.
> https://bitbucket.org/llindstrom/pygame-1.10-patch
>
> I think it should be possible with some work to improve an SDL2
> compatibility layer, so that pygame code base can work with either (as
> a compile time option). Then newer APIs can be introduced in time, in
> a non break-every-program kind of way. Also, it's been proven that
> 'hardware' blitting does not need to break SDL1 API compatibility to
> use hardware accelerated APIs (Angle, SDL_gpu, [insert 4 or 5 other
> projects], ...).
>
> Having a pygame2, or whatever separate repo would also make
> maintenance harder. Since for the foreseeable future, we will likely
> need to do maintenance releases for this anyway (at least I want to!,
> and I know other users of pygame will).
>
> ---
>
> For pip uploads, they would continue to be for SDL1, until we can
> finish the SDL2 changes, and it works better. There would be no new
> additions until compatibility is mostly there.
>
> The work would progress by slowly adding in compatibility changes
> whilst keeping pygame working. By keeping the SDL2 patch set as is,
> and slowly reducing the patch set until it is size zero. So we always
> have a pygame with sdl2, and a pygame with sdl1 that is producible.
> Eventually the patch set will disappear.
>
> ---
>
> A pygame2 module would just cause confusion amongst users, and that
> really boring 'pygame 1 or pygame 2' type debate would go on, and on
> like the "python 2, verses python 3" one did. For me, just avoiding
> that discussion for the next decade would be worth it.
>
> Then there would need to be two sets of documentation on the website.
> And two sets of tutorials... and... we'd have 2 of everything to *do*,
> and 2 of everything for people to look at.
>
> Finally, "import pygame2" looks kind of weird. I've grown used to
> "import pygame".
>
> ...
>
>
>
> I'm keen to get moving on this. I've been trying to get feedback on
> the 'pygame sdl2 addition' issue for the last month, and the issue has
> been open since 2013. So I'd like to put a time limit on this decision
> for one more week.
>
> I'd really like to hear back from contributors, and users (everyone).
>
>
>
>
> ps. Interestingly SDL_gfx has an SDL2 release now.
> http://www.ferzkopp.net/wordpress/2016/01/02/sdl_gfx-sdl2_gfx/
>