> cases. > I expect much of the code that defines extension classes will be > rewritten. Pygame extensions to SDL, such as custom blitters, may be > salvaged. > Much of the work will be writing code to support the new SDL 2.0 features. > > >
There's also the problem of Texture vs Surfaces. For future code to be backwards compatible we can default to Texture. But if the user needs pixel access he will need to create a Texture and Surface. The 3 options are summarized: https://wiki.libsdl.org/MigrationGuide#Video > 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. and On Sun, Jul 12, 2015 at 8:48 PM, Lenard Lindstrom <le...@telus.net> wrote: > Hi Jake, > > For the parts of SDL2 that did not see a major redesign, such as Surfaces, > there are enough small differences that simply replacing SDL 1.2 calls with > equivalent SDL 2.0 functions is not enough. The event types SDL2 posts has > undergone some reorganization. There is no longer a clear mapping > equivalence SDL 2.0 and 1.2 in some Do you think we should start pygame2 to support SDL2 design decisions rather than trying to support both old and new code at once? I figured if there was a time to make potentially breaking design changes to follow modern SDL, now would be the time to do it. If we decide pygame2 must be fully backward compatible, I was worried it would limit future changes. Or that supporting both old with new is adding too much complexity for something that might not be needed? -- Jake
