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

Re: [pygame] Pygame's future beyond 1.8

Hi,

some responses below.


On 8/21/06, Alex Holkner <aholkner@xxxxxxxxxxxxxx> wrote: 
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.


Sure.  However I have these planned... I already have a basic ADD
32bit blit routine written, and plan to make mmx versions for each of
the new blit routines which were written in C.

I also want to generate some other versions with ICC, and vector C
then include them.  ICC and vector C can do a pretty good job at auto
vectorizing functions... so rough vectorized functions can be put in
place once the infrastructure is in to detect cpu types.  I'm going to
use the sdl detection code for this.

This same code could be used for pygame ctypes if it wanted.

For example the current pygame draw, image, and transform modules
should be able to be used from pygame ctypes.  So maybe there is no
point in rewriting them in C for pygame ctypes since they already
exist in pygame.

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.


For linking against other compiled C libraries this is fine.  However
writing new C libraries, or including in C code from elsewhere will
obviously require a C compiler.

> 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.


Yeah, there are definitely advantages.  http://www.pygame.org/ctypes/

There's also dissadvantages, and none of those advantages apply to me or others.

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.


Yeah, one of the names should change for sure.  I think if Pete wants
to continue with pygame ctypes then maybe that should be the new
pygame.  It really is up to you guys what pygame ctypes is called,
since they are your babies :)

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.


This is the thing I think you are missing... I want to continue with C
pygame, and there will be others who will want to continue using it.
For some of us, it does not make sense to use pygame ctypes.  If we
can come to some way of having both going at the same time, I think
that will be the best outcome at this stage.  Considering that both
projects are going to keep existing.  However if Pete does not want to
have the current pygame continuing as pygame, then I am going to name
it something else and continue on elsewhere.  Maybe that will be a
better idea, than to have the two projects trying to share the same
webpage/etc and trying to keep a compatible api.  I'm not sure.


I'm interested to hear what Pete, Phil, Bob, Joe, Marcus and other
contributors have to say about it, as well as anyone else.