Hi,

some responses below.


On 8/21/06, Alex Holkner <aholkner@[...].au>  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.