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 <len-l@xxxxxxxxx
<mailto:len-l@xxxxxxxxx>> 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?