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.
