Re: [pygame] pygame with SDL2 proposal

[Leif Theden <leif.theden@xxxxxxxxx>]

I agree with Thomas; a compile time switch of SDL 1 or 2 sounds like a nightmare and source of confusion for end users.  Doesn't sound like a simple way forward, and further locks the code base to a few developers who can understand how the whole thing works. 

The developers of pygame are currently overworked and can't even keep up with pull requests or issues on the bitbucket.  Making the code base more complex will not being in more developers, which is needed to keep up with bug fixes. 

SDL 2 itself introduced breaking changes, but you don't see the maintainers of it clinging to legacy code just to ensure source compatibility.   There is a code migration guide in the docs.

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

And to be clear, the biggest change is the the rendering modules. Everything else can keep the pygame API. You could even just emulate the old clunky surface and blit API behind the scenes, but you need hardware accelerated support first, not an afterthought. 

With proper mobile support, you can entice actual game developers to make money or advertise the platform. 

Content creators should embrace changes and not worry about breaking changes.  They get to write new blogs, sell more books, and teach more content.  Better for everyone. 

Let's not forget this mailing list is an echo chamber of people who have watched pygame languish.  The people who have opinions about writing games and apps in Python have moved on to Kivy, or bypassed pygame as soon as they hit a performance wall because blitting is slow, and they don't understand why their computer runs Crysis, but can't manage to draw a 100 sprites at 60 FPS.

This is my final reminder that every line of code written to ensure that some pong tutorial from 2004 runs unmodified on pygame 2, is a line of code lost that could make pygame relevant again.

On Mon, Mar 20, 2017 at 7:25 AM René Dudfield <renesd@xxxxxxxxx> wrote:

I think this is a really good thing to think through.

The issues you bring up hinge on one thing (compatibility concerns). So far the unit tests pass. From my investigations, I haven't been able to find any theoretical reasons why it can't be compatible for 99% of things using pygame.

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. As the patches currently exist, and have for some time, gives me a reason to think those fears about OS packagers doing strange things are unfounded. As they upgrade SDL versions at different times, I think we should still be ok if things are compatible.

By not aiming for compatibility we guarantee there won't be. Having a compatible pygame API lets us do that, and still release to places where SDL2 doesn't exist yet. If considering the API is compatible as I hope, then I don't see a problem with people who require SDL2 features seeing if they are running on an SDL2 pygame.

A pygame 2.0 would be released under the pygame package name, with SDL 2 as default, with a pygame compatible API. Until we get to that point pygame 1.10.0+ will exist, but patches and conditional compilation will be available for SDL2. (as they exist right now, but made easier to select). Old modules like cdrom, and overlay will be marked as depreciated.

By using new pygame APIs for differences between SDL1 and SDL2 we allow the old apps to continue working. So there should be no sudden break the world transition.

If an app really isn't compatible with a newer pygame for some reason (unlikely IMHO), then it's still possible for an older version to be bundled with pip, conda, and many virtual envs. Things like apt, could do like they did with SDL1, and python2 and python3. That is, making pygame1 into a pygame1-sdl1 package, which perhaps gets installed as pygame1. Then the rare cases of old uncompatible apps, which have not been updated themselves are covered. But I honestly don't think that will happen.

On Mon, Mar 20, 2017 at 11:15 AM, Thomas Kluyver <takowl@xxxxxxxxx> wrote:

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