On Sun, Jul 12, 2015 at 12:52 PM Jake b <ninmonk...@gmail.com> wrote:
> I think there's (a lot?) of new non-backward compatible features? [multi > windows, default hardware support, touch events, etc]. Are there other > changes that were previously skipped because it wasn't backward compatible. > > What I mean is maybe pygame2 should start with design changes, rather than > worrying on making a completely backward compatible choices? > I don't think trying to come up with a backwards-incompatible version of pygame is the right way to go. Pygame is the sort of API that's taught in books meant to teach children how to program - I think it makes sense to avoid obsoleting that knowledge. Similarly, people have a lot of time and code invested in pygame. Some of that code exposes the pygame API - for example, in Ren'Py, we expose pygame events to game code. I imagine other pygame-based libraries are similar. It's also not terribly necessary. In pygame_sdl2, we were able to add support for SDL2 functionality without materially changing the pygame API. For example, take the pygame(_sdl2).display module: https://github.com/renpy/pygame_sdl2/blob/master/src/pygame_sdl2/display.pyx We added a new Window class to that module to represent SDL2 windows. display.set_mode creates a Window instance that display.update and the other methods access - but you could call .update on a Window instead. At least in theory, old code works, while new code can take advantage of new features. We did something similar with events - kept the existing events while adding new events such as application state and text input events. (The application has to opt into the latter with new functions in pygame_sdl2.key.) As long as code is written in a way to ignore unknown events and fields on events - which should always be the case, or pygame1 would have been unable to add anything - it should work. We've added support for a lot of other SDL2 functionality in the same way. I'm pretty sure it should be possible to make a version of pygame that runs existing pygame code while exposing new features to new code - allowing people to exploit much of their existing knowledge. Some other thoughts: It's probably impossible to implement something compatible with pygame without compiling at least some C code. One problem is blend modes - many of the pygame blend modes, including the default alphablend mode, aren't in SDL2. I'm a little skeptical of ffi-based approaches on mobile platforms - linking everything together seems more likely to work.
