Pygame 2.0, the SDL2 edition

Issue #174 new
Lenard Lindstrom
created an issue

Port Pygame to SDL2.

Some issues to resolve:

  • Backwards compatibility
  • Implementation language: pure Python, or Python with extension modules
  • Include new features beyond those found in Python 1.9.2
  • Start development immediately, or release Python 1.9.2 first

Comments (12)

  1. Lenard Lindstrom reporter

    For software surfaces to work properly, the bug fixes introduced in SDL 2.0.4—still under development—are needed. Also, MinGW build support was dropped from SDL 2.0.4. This leaves Pygame's Windows prebuilts tool chain unusable. Hopefully the Windows binaries provided by libsdl.org can be used.

  2. Thomas Kluyver

    @Tom Rothamel's pygame_sdl2 is an effort to reimplement the pygame APIs on top of SDL2. Should we collaborate with the developers of that and bless it as the recommended way to use Pygame with SDL2?

    I'm a little bit playing devil's advocate, but only a little bit: we shouldn't spend time and effort porting Pygame's codebase to SDL2 unless we have a clear reason why that would be a useful alternative to pygame_sdl2.

  3. Tom Rothamel

    I would love to work with the pygame project to turn pygame_sdl2 into a more complete reimplementation of the pygame API, perhaps by using pygame code to implement some or all of the missing components. At the same time, while I'd be happy to do my best to maintain it, in practice Ren'Py has been stretching me kind of thin already, so I'm not really giving pygame_sdl2 the attention it deserves. It would be nice to have help to split pygame_sdl2 out of the Ren'Py world, and have it become an official pygame. (I would like it to be released on a more regular schedule, even if it's not perfect.)

    One thing that would be very nice would be to merge the pygame and pygame_sdl2 codebases. There's a lot of implementation code in pygame that would really help things. I'd been avoiding that because I was trying to avoid the LGPL, but it turned out to be too difficult for me, so I would up merging in the pygame blend modes.

    Pygame_SDL2 also dropped support for <32 bits per pixel. This simplified the work drastically since a lot of the code had to have 4 code paths, for 8, 16, 24, and 32 bpp - but especially dropping 8bpp loses some functionality. At the same time, that does break some legacy code.

  4. Thomas Kluyver

    I'm not sure Pygame's the project to look to for regular releases - there was a 7 year gap between 1.9.1 and 1.9.2. ;-)

    I see the current pygame codebase carrying on in maintenance mode with few new features, to support existing code built on top of it.

    So I guess the questions are:

    1. What bits of the pygame API are missing in pygame_sdl2? Are there pieces which we can't implement, or don't want to implement, on SDL2?
    2. What code could be shared between the projects, and how might we do that? I have no idea how different SDL 2 and 1.2 are. I guess that the code in Pygame that has to work with different bit depths can't easily be shared, but presumably lots of the other code is similar.
  5. Tom Rothamel

    Right now, pygame_sdl2 is mixing BufferProxy, camera, cdrom, cursors, freetype, mask, math, midi, PixelArray, pixelcopy, sndarray, and surfarray.

    I think many of the other modules have reasonable implementations, although it's been awhile since I checked the completeness against pygame, especially the newer pygame functionality. I'd leave out support for legacy bit-depths, and cdrom, but other than that, I think most functionality should stay.

    A lot of the SDL2 functionality is set up in a way that you can emulate SDL1/pygame semantics with it. For example, SDL2 supports multiple windows. We've implemented this by adding a pygame.display.Window class, and then having pygame.display.set_mode and friends create and work on an instance of it. See, for example, how set_mode and get_surface are implemented at:

    https://github.com/renpy/pygame_sdl2/blob/master/src/pygame_sdl2/display.pyx#L366

    At the same time, SDL2 adds functionality. SDL1/Pygame has very little support for GPU rendering, while SDL2 has fairly comprehensive support for it. So it would make sense to either expose that functionality, or a high-level API for 2d-on-3d rendering using OpenGL and OpenGL ES. Already, pygame_sdl2 has added support for new events (to support internationalized text, touchscreens, and mobile platforms), and APIs like the controller API.

    As for sharing code, I can see sharing the implementations of the freetype and mask, and perhaps more code. (I've already copied in code for software blitting - which is kind of a shame, since it makes things LGPL, which is a pain on mobile.) More important would be sharing things like the documentation, test suite (which is totally lacking), and experience - some of the missing areas are because I don't understand how things like the ----array modules or test suite work.

  6. Lenard Lindstrom reporter

    I did created a Pygame 1.9.2 patch, Pygame 1.10, that replaces SDL 1.2 with SDL 2.0.4. It does not add any new SDL2 specific features and is not intended to be Pygame 2.0. It can be pulled into the main repository as a separate branch—under a new name—while work precedes to get a Pygame 2 release ready.

    I think pygame_sdl2 would be a good starting point for Pygame 2.0. I do not know about licensing issues, just that the Pygame license is compatible with the Python Software Foundation License. The license must also play well with the LGPL licensed libraries Pygame uses.

    The SDL 2.0.4 and later libraries have not yet replaced SDL 1.0.2 on all active gnu/linux distributions. I found anything earlier than version 2.0.4 as too buggy and incomplete for Pygame; Pygame is an extension to, not just a wrapper of, SDL. Also, a suitable build of SDL 2.0.4, or later, and associated extension libraries are needed for Windows. I can give advice here, but an currently unable to do Windows builds and testing.

  7. René Dudfield

    @Lenard Lindstrom Very nice about the patch!

    For licensing on apple mobile, I think we should consider finding a foundation home for it. PSF, Kivy, Raspberrypi, ... other. Then we can check with everyone if they are ok changing the license.

    If everyone is happy with pygame_sdl2 being a start for pygame2? then...

    @Tom Rothamel are you ok if we start moving pygame_sdl2 to the github.com/pygame org? Perhaps as "pygame2"

  8. Tom Rothamel

    I'd be fine with moving pygame_sdl2 (and eventually, renamed versions of rapt and renios) into the pygame organization, as long as there are a few other developers interested on collaborating on it and turning it into a workable pygame in some sort of reasonable timeframe.

    I'm fundamentally fine with with renaming pygame_sdl2 to pygame2, although there already is a pygame2 project at https://github.com/pygame2/pygame2. That one does appear to be relatively dead, so it's not clear that's a big deal.

    My main concern is that I'm able to release at least semi-official versions of pygame_sdl2/pygame2 on a regular basis - the original point of pygame_sdl2 was that I needed something pygame-like yet modern to support Ren'Py, and I'll still be needing something like that going forwards. I like that this work can be shared with the rest of the pygame community, but at this point I have tens of thousands of users, and it's important to me that I'm able to keep giving them regular releases.

  9. René Dudfield

    I hear you. We should think of a good way to make a transition.

    We can definitely help with the build process for quick releases. We have quite a lot more experience with getting it working on pip, and various other platforms with the recent 1.9.2 and 1.9.3 releases. I also don't see a problem with you continuing to make releases when you want to. If we follow the model where the main branch is always releasable, then anyone should be able to rush out bug fix releases. By pinning your dependency to the pygame2, you could make sure you are happy with the release being compatible.

    One idea would be to delay the rename, or to keep your project named the same at the beginning. We can merge patches across. Once the 'pygame2' is released, and packaged automatically on all the main platforms you could switch over when you are ready.

    Hehe, I didn't even know about that pygame2. No activity for more than two years it seems. I can reach out to the author to see if they are interested in collaborating later on. It might be cool if other pygame related libraries could move into the github pygame as well. eg pygamezero by @Daniel Pope and co. This way we can more easily see what's going on and share resources amongst the separate projects.

  10. Log in to comment