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

Re: [pygame] Pygame's future beyond 1.8



René Dudfield wrote:

Compatibility, pygame ctypes and pygame will never have complete api
compatibility.

They do not have complete compatibility at the moment, but it is something I am striving for. There is nothing inherently impossible about the task, though it could take some time. At the moment the compatibility is "good enough" to run every game I have thrown at it.


They will also never have the same speed
characteristics.  Meaning more testing, and having to use the lowest
common denominator.  eg. if something is 10x slower with pygame ctypes
then it can not be used.

I agree with Richard: that Pygame-ctypes should become Pygame 2.0 only if and when it becomes performance competitive. It is nowhere near this stage at the moment. But it is something I think will be possible, in time. If anything is 10x slower with Pygame-ctypes I would object to it becoming the main trunk.


Working on other platforms, pygame ctypes works on windows, linux, and
macosx.  sparc, mips, alpha, arm, and other weird used platforms are
not supported.  For me, this means that pygame ctypes does not work on
some of my machines.  ARM being the major platform that I want to
support.

ARM support for ctypes is currently under development. I suspect that as Python 2.5 gains popularity, so will ctypes and its platform support. If there are major platforms still unsupported by Pygame-ctypes when and if the 2.0 push comes, we should delay it until they are (though I personally am not sure that SPARC, MIPS or Alpha qualify).


Speed, obviously C & asm are faster than python.

There are currently no hand-coded assembly paths in Pygame. The major performance bottlenecks of Pygame-ctypes at the moment are in the draw, transform and image modules. These will get alternate pathways written in C, Pyrex (which compiles to C) or something else.


In the more general case, the small amount of Python wrapper that exists on every Pygame-ctypes function will indeed make it perform slower than its Pygame counterpart. I would argue that if this small performance penalty is significant for a particular project, then that project is not really suited to be implemented in Python.

As you mentioned, some parts need C anyway. Taking away one of the
main benefits of ctypes, and that is being able to contribute without
a C compiler.

Indeed, they only need a C compiler if they wish to contribute to a part that is written in C (or Pyrex, etc.). The real benefit here is not in removing the requirement for a C compiler, it's in speeding up the development process---avoiding the recompile-link-debug cycle for most development.


By requiring a C compiler it is easier to include other
C libraries.

Not at all. Witness Pygame-ctypes's extensive use of SDL, SDL_image, SDL_mixer and SDL_ttf. Any library can be written for using ctypes.


Pygame works already, meaning that I see no reason to use something else.

There have been other threads discussing the advantages of moving to a ctypes-based module; see for example the Pygame-ctypes home page.


Regarding your comments [in "new pygameC or pygame."] about a name change, I agree completely with everything you say. If the issues above cannot be resolved and there are two Pygame-like modules in active development, Pygame-ctypes should change its name, preferably to something that doesn't look at all like "pygame", and Pygame should continue in its current namespace.

I am with Richard in planning for Pygame-ctypes becoming the trunk and future development on Pygame stopping at 1.8.x. Your expertise in Pygame would be invaluable in implementing the required optimisations in Pygame-ctypes, and I would not like to see the community forked.

Regards,
Alex.