I mentioned this in passing a few months ago, but I think it's time to formally announce Pygame_sdl2.
Pygame_sdl2 starts with the premise that the Pygame API is important. The Pygame API has been used by thousands of games, libraries, and engines, and is being taught to beginning programmers. Preserving the Pygame API is important, as it means that those games, libraries, and engines will keep running, and those programmers' experience will not become obsolete. At the same time, SDL2 support is beneficial for a number of reasons. SDL 1.2 is now obsolete, and has been for a while. New features, and ports to new platforms - especially the important mobile platforms - have been added to SDL2, and SDL2 only. For a while, I tried to add Android support by maintaining, as part of PGS4A, a port of SDL 1.2 to Android, but that proved to be very difficult as mobile platforms keep evolving. In October of last year, Patrick Dawson and myself began work on Pygame_sdl2, a reimplementation of the Pygame API using SDL2 and related libraries. The goal of the project is to allow games written to the Pygame API to run, using SDL2, on desktop and mobile platforms. We've also exposed some SDL2-provided functionality in a way that remains compatible with older code. At least for now, Pygame_sdl2 is available at: https://github.com/renpy/pygame_sdl2 It's been used - as part of my Ren'Py engine - to release multiple games on Windows, Mac OS X, Linux, and Android, and I've been able to get Pygame_sdl2 to run on iOS, but haven't submitted to the App Store yet. This process, which included at least one Steam release, helped to shake out the more obvious problems. Pygame_sdl2 is written in a mix of Python, Cython, and C. Use of the Cython code massively simplified the project - by not having to worry about the details of python bindings, we were able to get the initial version of Pygame_sdl2 running in a short amount of time. Newly-written code is licensed under SDL2's Zlib license, while the code we imported from Pygame is licensed under the LGPL. (The LGPL's terms control distribution.) Pygame_sdl2 implements a large portion of pygame, but not all of it. Currently implemented modules are: * pygame_sdl2.color * pygame_sdl2.display * pygame_sdl2.draw * pygame_sdl2.event * pygame_sdl2.font * pygame_sdl2.gfxdraw * pygame_sdl2.image * pygame_sdl2.joystick * pygame_sdl2.key * pygame_sdl2.locals * pygame_sdl2.mixer (including mixer.music) * pygame_sdl2.mouse * pygame_sdl2.scrap * pygame_sdl2.sprite * pygame_sdl2.surface * pygame_sdl2.sysfont * pygame_sdl2.time * pygame_sdl2.transform * pygame_sdl2.version Experimental new modules include: * pygame_sdl2.render Current omissions include: * Modules not listed above. * APIs that expose pygame data as buffers or arrays. * Support for non-32-bit surface depths. Our thinking is that 8, 16, and (to some extent) 24-bit surfaces are legacy formats, and not worth duplicating code four or more times to support. This only applies to in-memory formats - when an image of lesser color depth is loaded, it is converted to a 32-bit image. * Support for palette functions, which only apply to 8-bit surfaces. There are a few additions to the pygame API, including support for the application lifecycle events on Android and iOS, IME-based text input, and SDL2 renderers. While I plan to, at the very least, maintain this indefinitely to support Ren'Py, my hope is that it could be useful to the larger Pygame community. For now, Pygame_sdl2 could probably benefit from testing, both informal reports of missing APIs and incorrect implementations, and someone helping to integrate the relevant portions of the pygame test suite. The modules that have not been implemented are often that way because we don't have much experience with them - for example, I've never been able to wrap my head around the <thing>array modules. So help implementing those, or porting the Pygame implementations, would be appreciated. For now, pygame_sdl2 has been maintained as part of the Ren'Py github organization, but if there's enough interest in contributing and expanding it, it might make sense to break it out into its own project. Anyway, thank you for reading through this message, and for trying out pygame_sdl2.
