pygame 2 update - the examples all work

 🎮👾👽🎮👾👽🎮👾👽🎮👾👽

examples/chimp.py works

👽🎮👾👽🎮👾👽🎮👾👽🎮👾

That's a nice milestone for pygame 2 development.

(and also, now these examples also work...

    python -m pygame.examples.aliens

    python -m pygame.examples.scroll

)

I'm pretty sure all the examples are now working with SDL2/pygame 2.

New SDL2 functionality.

Also we have some new SDL2 functionality exposed

    (experimentally, the APIs are not done yet).

Multitouch, and AudioDevice, along with an example of recording audio.

@dlon has been fixing a number of bugs(implementing key repeat, fixing unicode issues)

and also prototyped some Window/Renderer classes (using ctypes and python).

The new events are done in a backwards compatible way,

so that games using them with pygame 1/SDL1 will still work.

You just won't get the events.

if event.type == pg.AUDIODEVICEADDED:

    print('a new sound card plugged in... let's offer the user to use it')

On pygame SDL1 AUDIODEVICEADDED is defined as -1, so you just never get these events.

See examples/audiocapture.py

Making an instrument, Free and Open Source

With a friend we made a loop recorder instrument/video thingo with microphone input.

It records the input and then lets you play back sounds as loops.

Then you can record over tracks making music in a performance.

The video synth reacts to beats and pitch changes driving video.

(pitch/beat detection not included in pygame... yet?)

(Demonstrating the app for a pygame presentation at an Open Source diversity event in Berlin)

Working on a project that uses pygame 2 has been good for me to push features forward.

Now you can ask pygame.mixer to use things like 32bit floats (good for audio apps).

As well as tell it to open a specific audio device for output (and input!).

Writing your own mixer/synth is now much easier.

Music making and performance app for pygame 2, looping and mixing sounds recorded in the microphone.

I think I learnt a lot from that event about making projects more accessible to people, and made some contacts with people from other projects and communities.

For contributors, I've written about how to debug pygame and other python extensions with gdb,

and also how to get started with SDL2 in C (strangely this did not exist on the internet). These will be tested and then merged into the pygame contributors guide.

Python, Cython(Pyrex), and C.

Now we have the start of a module using Cython (_sdl2.pyx). Why Cython?

• We discussed on the mailing list already that it would be good for new features.
• It also works with python 2.6+/3.
• Cython can be used on platforms where ctypes can't, and is faster than ctypes.
• Cython is more readable to python people.
• Cython is also ok on pypy (cffi is the faster option on pypy still).
• We already had one Cython/Pyrex module (the portmidi module that the midi.py module uses internally).

If we implement things in python using a fairly straight wrapping of SDL2 in Cython,

then it would be much easier for people in the future to make a CFFI enhancement for pypy.

If we keep the C parts separate from the python parts, then it will be easier to maintain.

What I mean, is that C+SDL code should not have any Python.h code in the file.

See src_c/_sdl2.pyx
 

What language to use when? A summary.

• New features in python. Python implementations are easier to debug, change and read. They run faster on pypy. They are a good educational resource, because the python code is very readable. They can be used to cross-check test implementations in C. The work done by e1000 on the line drawing code has shown the value of this approach. Also the pypy and Cpython projects use a 'python first' approach.
• C code should be kept separate from the Python.h parts. This is 'cleaner' easier to read, and maintain. This opens the possibility to share the C code more easily with other projects.
• Keep SDL2 wrapping close to the SDL2 C API. This makes a CFFI implementation easier if someone wants to do so in the future. And it is clean layering. With Cython we don't have as much of an overhead as with C+Python, because of the compiler.
• new SDL2 functionality can be wrapped with Cython.
• Accelerators of python code can be done in Cython (the sprite.py code is a great example of something that could use Cython to speed up collision detection and dirty rect handling).
• We should generate .c files so that the user does not need to use Cython when installing pygame from source.

I'm excited that Cython will allow us to speed up sprite.py, collision handling and dirty rect handling.

It's one of the "Four new pygame things for slow computers." I wrote about in March 2017.

Note, we already have 2 of 4 done :)

How to document with Cython?

There are some open questions with Cython however. The main one being...

• How do we use the documentation from inside a .pyx file and have it included in sphinx?

If we don't do this, then we need to maintain two sets of documentation.

  (Like we do for midi.py)

The other way is a possibility too... maintaining the documentation in the .rst files,

and somehow inserting the docs at build time.

Hopefully someone else in the Cython/Pyrex community knows how to do this documentation workflow well.

Using projects to guide development.

"Write Games, Not Engines"

Working on the looper/video synth project was good to get some audio code working.

But also, I've been working on fixing issues with 'solarwolf' as a test game,

and it's playable but still with a couple of graphical glitches left.

Since we don't have unit tests which cover absolutely everything,

using apps I know well to test is a pretty good alternative.

The approach of looking for issues, and then going into the debugger to find the

Surface blit/transform combinations that are failing in the solarwolf game is a good one.

The first 'game' using pygame 2. A community game.

Speaking of using projects to drive development.

I'm starting this "pygame community game" thingo we talked about a while ago... now.

To enter it into the Ludumdare/Github GameOff jams which end in about 4.5 days.

I'll start another email thread and website announcement but...

Anyone who wants to be involved can join the discord channel

web based chatroom(discord) in the "#communitygame" channel.