Thomas: > 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. Considering that the breaking changes are basically just for graphics, other parts of existing projects can be salvaged.
> I also don't see the advantage of having one version of pygame that can be built with two different versions of SDL. Agreed. > Or do you develop and release a game with the pieces available at the time, and then move on to a new project? Generally, I just work with what is available. I don't mind adapting small changes to my projects where there is a great payoff for the effort. On Mon, Mar 20, 2017 at 10:06 AM, Leif Theden <leif.the...@gmail.com> wrote: > 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 modernize > > We 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 <tak...@gmail.com> wrote: > >> On 20 March 2017 at 12:25, René Dudfield <ren...@gmail.com> 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 >> > >
