[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] pygame with SDL2 proposal



On Mon, Mar 20, 2017 at 2:27 PM, Thomas Kluyver <takowl@xxxxxxxxx> wrote:
On 20 March 2017 at 12:25, René Dudfield <renesd@xxxxxxxxx> 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 understand it's a risk. But from what I've seen, I don't think it's a big one.

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


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
  • compatibility for those of us who care about what we've made
  • SDL1 using people can keep with that for the time being
End users will still `pip install pygame` and not care about how we decide to develop the changes.


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.

I guess that is a lot more effort than what I'm suggesting, and provides less benefit.

The proposal:
  • takes work that is mostly done already, and cleans it up
  • keeps everyones apps working
  • whilst the work happens, pygame 1.9.x and 1.9.10 are releasable.
  • provides a base for future improvements
  • gets extra platform support (SDL2 gives us easier mobile, etc)
  • keeps everything working whilst the changes are made
  • reduces future documentation, and packaging work of maintaining two code bases
  • is less work, and less risky than continuing on from pygame_sdl2 and filling in the missing bits.
  • has a transition plan for end users, which is do nothing differently.