Stick a fork in it, it's baked... nice and toasty. A new version of pygame is out. http://www.pygame.org/ Pygame is a set of Python modules designed for writing games. Pygame adds functionality on top of the excellent SDL library. This allows you to create fully featured games and multimedia programs in the python language. Pygame is highly portable and runs on nearly every platform and operating system. http://www.pygame.org/wiki/about Silliness built in. Does not require OpenGL. Multi core CPUs can be used easily. Uses optimized C, and Assembly code for core functions. Comes with many Operating systems. Truly portable. It's Simple, and easy to use. Many games have been published. You control your main loop. Does not require a GUI to use all functions. Fast response to reported bugs. Small amount of code. Modular. Over 1000 open source games have been released that use pygame, so there are lots of examples to learn from. http://pygame.org/whatsnew.shtml Many bug fixes and improvements, including: * BLEND_RGBA_* blitters and blenders to go with the BLEND_RGB_* blend modes. * documentation updates (mainly for new sprite classes released in 1.8.0) * sound fixes, and streaming some music from file like objects * image saving fixes * greatly expanded tests * Pixelarray, and surfarray updates and fixes. * Enhanced Color class, reimplemented in C for speed. * New Windows and Mac binary installers. Many thanks to Marcus, Lenard, Brian, Nicholas, Charlie Nolan, Nirav Patel, Forrest Voight, Charlie Nolan, Frankie Robertson, John Krukoff, Lorenz Quack, Nick Irvine, Zhang Fan and everyone else who helped out with this release. Next release will include the physics engine, Webcam support, enhanced easy and automatic multithread support amongst other goodies -- they have been in development for over 3 months full time so far.

How is it that it uses multiple prosessors easily? cpython can only utilize one core/prosessor at a time due the global interpreter lock.

How's its support for multiple monitors? Or multiple windows, for that matter?

I love Pygame and have written a lot of fun small games and cool demos with it, but Pyglet's superior handling of application windows is starting to become a compelling reason to make a full-time switch. For now, though, I continue to use them in conjunction - I'm so familiar with Pygame that I can get my game core up and running in minutes.

Hello,


@smr
We release the GIL so that pygame can do processing in multiple threads, without the lock. Pygame has been doing this since around 2002 for some functions. There is a new experimental threads library in pygame that allows you to run code in another thread like tmap(func, args), and tapply(func, *args). The next release will polish this up, and have a sprite class which will use multiple threads automatically. So if you use the sprite classes in your game you will have no extra work to do.


@Oluseyi
Sure, use whatever libraries you like :) For some things other libraries are more useful.

For portable applications one monitor is how it is done. Some platforms only have one screen, and some don't even have windows. People use multiple processes to call multiple windows currently.

eg. the pygame test runner can use over 512 processes to run all of it's tests at the same time(assuming you have that many cores). Also the Kamaelia project that uses pygame uses multiple processes for multiple windows.

SDL 1.3 has had support for multiple monitors since before pyglet began... however SDL 1.3 is still not finished, so pygame uses SDL 1.2. Once SDL 1.3 is finished then pygame will get support for using multiple windows in the same process. SDL 1.3 also has direct3d, with the opengl 2D support... other 1.3 features include many mouse, multi touch, force feedback, accelerometer, pressure sensitivity, and portability to more platforms including DS, iphone/itouch, wii etc.


cu,

Is it safe to execute python code concurrently while the gil is released?

hi,

Only if the code doesn't use the Python API.

so eg, if you are scaling an image, and mixing some sound, then you release the GIL around those parts.

So the time consuming parts (not using the python API) release the GIL, so other python code can run.

If you release the GIL around enough time consuming parts then you get pretty good concurrency.

Many of the time consuming parts in pygame release the GIL, allowing multiple threads to run.

So it still does have limitations, but it's much better than just one thread at a time working.

Otherwise it's best to use separate processes.




cheers,