This is great news, and thank you for sharing this. How do we get this on the news feed on the main pygame.org site so that there isn’t a perception that “nothing’s happening” with PyGame?
~ Michael On Sat : Apr 4, 2015 6:42:36 PM you wrote: > 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.
