Pygame weekly mini sprint 2007/08/22

This week we found and fixed a long time problem with the SRCALPHA flag. Which is the flag used for per pixel alpha (transparent images).

In fixing that it turned up a few other issues with Surface. There were problems with error checking, and keyword arguments didn't work.

So we got the error checking working, as well as keyword arguments.

The major piece of work that went in was the PixelArray from Marcus. This will be what we use to replace surfarray. A PixelArray is like a basic numeric/numpy array, and like what you'd expect returned from a surf.tobuffer() call. With it we will be able to support Numeric, and Numpy by loading them dynamically.

I still need to write the which will replace the compiled surfarray. There will be a surfarray_numeric, and surfarray_numpy. So it will be backwards compatible, and you'll be able to use the array type you choose. We will include a frombuffer() method for Numeric arrays - which won't require Numeric to be installed to compile. Numpy already has a frombuffer method - so that shouldn't be too hard.

PixelArray will also support basic slicing functionality like numeric - so you can do things like array[x:y, a:b:z] = ... etc. This is what Marcus is working on next. So there will be basic effects you'll be able to do even without Numpy, or Numeric. As well as being able to send data to PIL, opengl, wx etc without using Numeric. So you won't need the extra dependency for these common use cases.

In other things I started to play a little bit with the upcoming SDL 1.3. This is the release with opengl and direct3d hardware acceleration, multiple windows, recording sound - and many other goodies. It's not finished yet, but is already fun to play with. Pygame will probably start to support it only when the final version is released - as some of the new APIs could still change. There is a SDL 1.2 compatible API - you just can't access any of the new features with the old API (obviously :)

pygame 1.8 will take advantages of all the improvements going on in the underlying SDL libraries. All the different users or different languages - C++, ruby, python all feed back into the C SDL. Lots of different engines use it, and heaps of game developers. So it gets *heaps* of users and testing - as well as optimization. Lots of linux distributions test it, as well as people releasing games on different platforms. Pygame 1.8 on the mac will have a whole bunch of altivec optimizations. On windows, and unix there have been a bunch of mmx optimizations too since the last pygame release(1.7.1). The image, sound and font modules have all gotten fixes, speed ups, and bug fixes - improving all of their quality. So not only will pygame get the pygame specific improvements - but it gets the improvements from SDL too. Read the SDL release notes for more details.

Over on the pyweek site someone has made a python wrapper for the 2d physics library chipmonk. Check out the youtube videos of the physics... Domino pyramid Domino smash. It might be a good thing to add to pygame in the next release after pygame 1.8.

The other week the SDL_gfx author mentioned that he was interested in collaborating with the pygame people some more to get more of SDL_gfx into pygame, and to move the pygame improvements back into SDL_gfx. The new improvements to SDL_gfx include bezier curves, more antialised shapes, and a textured polygon drawer.


Richard Jones said…
Wow, sounds exciting :)

Popular posts from this blog

Is PostgreSQL good enough?

Hey! It's work on pygame stuff week.

pygame on pypy usable