For those interested, here is the SDL2 migration guide. Pygame is combination of SDL 1.2 wrapper code (surface, events), some value-added type functions (drawing code, some rect functions), and python code (like sprite module). Because of this, it is protected from some changes to the underlying library, but not all.
https://wiki.libsdl.org/MigrationGuide There will be subtle changes, and also complex ones. My vote still is to make pygame2 close to SDL2, drop compatibility where it doesn't seem worth the effort, and keeping the spirit of pygame.Anything else seems like wasted effort.Also, lets focus on the issues here, and not waste time with things we agree on.We agree:* Pygame1 is outmoded and doesn't fit in with modern game libraries* Pygame1 is not a suitable target for real development because the graphics are slow* Pygame1 has significant problems that need to be addressed* Pygame1 needs a 2.0 version because its been sitting at 1.9 for years and it just looks silly to not modernizeWe don't agree:* Should pygame2 sacrifice some compatibility?* Should the effort be put to hardware-accelerated graphics or software graphics?Once the community reaches an agreement, then discussions of implementation can be addressed.For those just reading the thread and haven't voiced your opinion, please do so now.On Mon, Mar 20, 2017 at 8:27 AM, 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 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