making apps, making webs.

The last pygame release was August 16th 2005. So there are a lot of bug fixes and a few features in development that need to get out there into a release. With the new SDL being released last week it seems like a good time to get a new pygame out. Here is the release plan from the last release. We will follow it in the same way again for this new release. At the moment we are in the apply patches, fix bugs, get in any last minute features phase. This weekend I made pygame.image.save be able to save as .png and .jpg files. Since pygame already optionally links against libpng and libjpg to load .jpg, and .png it shouldn't be too much hassle for people, and only a tiny bit of extra code. So if pygame is linked against libpng, and libjpg it should be able to write .jpg and .png images. Saving as jpg/png is an often requested feature for people doing screen shots, caches, and level editors amongst other uses. Hopefully these save functions will eventually make it into SDL. That&#

For pygame which uses SDL some parts are written in assembler. These parts detect which cpu they are running on and then use those mmx/sse/3dnow optimized assembly routines if those processor features are available. However much of pygame and SDL is still in C, not ASM. So compiling using processor specific features does give a very nice speed up for the C parts. For some parts a 33% speedup or more can be gained. Just by changing compilation flags. I think this is the best and easiest approach to getting parts of CPython to be sped up. Below are my notes, and thoughts about the topic. Mostly this is based around my experimentation with pygame compilation. This does not take into consideration python compilation itself, or any of its modules. However a similar methodology could be applied to speed up pythons modules too. Note that recompiling python itself to match your processor can give a large speedup too. So, I have started experimenting changing distutils to compile modul

An update of what has been happening recently with pygame. Thanks to a kind person on the mailing list the macOSX version of the clipboard code was tested. It was a long process but eventually. A one week debugging cycle because I don't have a mac. HAHA. I also got around to testing out the windows version of the code on my win XP box. It worked fine there. Some blending functions have gone into CVS. So you can blit with the modes ADD,SUB,MIN,MAX,MULT. This allows more you to do lighting type effects, and is very useful for particle systems. These are the missing things that SDL doesn't have which are often asked for. The code was based on Phil Hasseys code which he wrote for 32bit software surfaces. He's also done some other code for lines etc. So I'll want to incorporate those changes so you can draw lines that blend too. I also need to add those blending modes to the surface.fill() method. That'll be very useful for fade to black/fade to white. Or f

These are my favourite python ideas from the google summer of code. Ones that I think will benefit the most people, and affect the most change for the better. Ok, just ones I reckon would be cool. Implement ctypes support for GCC ARM platforms. The underlying issue is lack of closure API support for ARM in libffi. A patch available at http://handhelds.org/~pb/arm-libffi.dpatch , that should be hopefully a good starting point. ctypes CVS has a libffi_arm_wince directory, which also seems to support closure API. Make a python+pygame plugin for IE, netscape. CodingProjectIdeas/PythonWebPlugin Psyco for MacOSX. PPC, and universal binary versions. (also psyco for ARM would be cool!!) Research how to get python support into all the cheap webhosts. Security audit of python. Using as many automated processes as possible. Python speed up. Reduce memory usage, speedup startup time. The two main speed regressions of the 2.0, 2.1,2.2,2.3,2.4 releases. (438,453,499,771,880) syscalls vs 106