[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] What's next for Pygame project?

Hi Jake,

On 15-07-12 09:52 AM, Jake b wrote:

Lenard
On Sat, Jul 11, 2015 at 7:20 PM, Lenard Lindstrom <len-l@xxxxxxxxx <mailto:len-l@xxxxxxxxx>> wrote: 

    Much of the delay is due to logistics. With the loss of the
    automated build site a few years back there is no simple way to
    check a commit against all supported operating systems. It also
    limits user testing.

What would we need?
A Pygame buildbot two tasks, building a Pygame installer for a particular operating system, then running the Pygame unit tests on the new build. Building Pygame is probably the easier task. The second task, to properly test Pygame, requires video and audio hardware. I saw someone having problems with the unit tests on a Ubuntu build site, as the SDL drivers had to be set to 'dummy'.
As for operating systems, Windows and OS X buildbots are most critical. It is easy to break Pygame on OS X. 



    I need someone to take over official Windows support from me,
    since I am stuck on Windows XP. I have the MinGW based dependency
    build chain working again for 32bit Windows, but did not get
    everything to build for 64bit Windows. So no official 64bit
    prebuilt libraries yet on the Bitbucket download page.


âI have surgery this week, but â
â if nobody âdoes this by then I will look into setting something up. I have win8 64bit.
Building the Pygame Windows dependenciesâSDL, SDL_mixer, freetype2, libJPEG, and suchâis not well suited to a buildbot. The default builds of SDL_mixer and SDL_image are unusable with Pygame, as the working directory is not in their DLL search path. This is where I could use the help. But I am back to using MinGW/Msys, which takes some special effort to set up. Maybe I can cross compile from Linux. Something to look into. 



    The structure of SDL 2 differs from SDL 1.2. It does not fit well
    Pygame's api. So I expect a significant redesign of modules and
    classes for Pygame 2. For instance, the display module will
    basically go away, replaced with a Window class.
â I think there's (a lotâ?) of new non-backward compatible features? [multi windows, default hardware support, touch events, etc]. Are there other changes that were previously skipped because it wasn't backward compatible.
What I mean is maybe pygame2 should start with design changes, rather than worrying on making a completely backward compatible choices?
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 cases. 



    This is an opportunity to replace C coded extension modules with
    Cython and a Python level foreign function interface. Personally,
    I would like to see Pygame fully support PyPy as well as CPython.
    Also, some of the Pygame code can be separated out as stand-alone,
    Python independent, libraries to encourage support from outside
    the Pygame community.


âDo you knowâ
â what or how much needs to be done?â
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. 



        * Website replacement and love
        * Migrate forum to Reddit (or community forum)


I think we should leverage the existing:

- https://www.reddit.com/r/pygame
- âhttp://stackoverflow.com/questions/tagged/pygame

--
Jake

Lenard Lindstrom