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

Re: [pygame] pygame / ctypes



On Fri, 2006-01-20 at 11:09 +0800, Simon Wittber wrote:
> It now appears that the ctypes module is to be included in the python
> standard library.
> 
> Would there be any benefits to making a ctypes pygame? PyOpenGL is
> going this way, to allow easier hacking by the average python
> programmer.

Yeah, I saw that it might be happening. In some ways using a ctypes
pygame would be awesome, since pygame could become a "pure python"
package. Last I saw ctypes was only being proposed. Was it recently
accepted in some form for 2.5?

I think a goal of a pure python pygame could be a worthwhile goal for
something like pygame 2.0? There are a few things that would make this
more challenging;

* Some of Pygame really is C code that uses SDL. This would either need
to be offloaded to some other library or written in something like
pyrex, but that kind of defeats the "pure python" approach. Libraries
like SDL_gfx have gotten better since their initial versions a few years
ago.

* I would recommend a strong reevaluation of base libraries before
writing the new bindings. Perhaps switching to something like SDL_sound
and OpenAL for audio instead of SDL_Mixer and SDL? There are already
fairly good PyOpenAL packages? It would still be great to keep the
number of actual binary dependencies as low as possible, since they
always get into the way of porting and distribution.

* Perhaps the ctype bindings would target different libraries on
different platforms? Using something windows-native on windows would
make distribution far simpler. Same for windows and osx using
alternative backends but sharing a common api.

* Allow "dynload" style bindings with ctype? I'm not sure if this is
allowed, but it would allow distributing support for many binary
dependencies, but only cleanly only using what is available at runtime.
This may make Pygame more of an "API" target that any independent
package can support, and any game project can rely on.

* I think Pygame could better defined with more streamlined file
support. I would rather see fewer image and sound types available, but
all of them better supported.


Anyways, just ideas at this point. Ctypes coming in Python 2.5 sounds
exciting to me. I'll have to stay tuned for details.