Re: [pygame] Pygame's future beyond 1.8

[Phil Hassey <philhassey@xxxxxxxxx>]

Hey,
 
 To sum up my opinion - If I were the king of pygame and python world, this is how it would happen:
  
  1.  pygame continues as the lead in pygame, new features etc.
  2.  pygame-ctypes follows step-by-step pygame and makes sure to be 100% compatible on its python interface
  3.  pygame-ctypes is made to work on all platforms supported by pygame ATM
 4.  pygame-ctypes should NOT use any c code (no using c, pyrex, swig, etc.)
  5.  when pypy makes python fast, and it makes pygame-ctypes as fast (or faster) than pygame, we switch to using pypy and pygame-ctypes, and drop pygame and python.
  
 Might be wishful thinking on my part in terms of pypy, but here's to hoping!  At present pypy is 1/4 the speed of python.  
 
 ..
 
 (for a longer edition of my thoughts with some more details see my commentary...)
 
 - 2/12 of my games work with pygame-ctypes.  Most of those bugs, I suspect
 are easily fixable, sans the c-land issues.  So I'd be guessing by the end of this week, 10/12 games will work.
 
 - set_at, get_at, and some stuff is very very slow.  That, I guess, is expected, however for me speed is a *huge* issue with games.  I spend much of my time eeking out all the performance I can get with pygame, and lately have taken to using swig and c to get just a bit more!
 
 - I don't like the idea of there being two commonly used pygame distros out there.  Imagine pyweek, for example, which edition of pygame would be the definitive one for the compo?  (Especially for those of us who are going to be using some custom c code in our entries, most likely.)
 
 - I think it would be okay for pygame-ctypes to become _the_ pygame once
 ** It is as fast as pygame.  Not "almost as fast".  Games are graphically intense items, and frames per second is a real issue.  Speed becomes an even greater issue when
 using python, since that gives me a huge penalty over C to begin with as far as graphics go.  I can't spare any more speed penalty for using pygame. **
 and
 ** it works on all the platforms, including the obscure ones **
 
 - pygame-ctypes should *not* use any C code.  That would really defeat the point.  If we're going to use c code for pygame-ctypes, we might as well just use pygame.  No using pyrex either.  That would be even worse, as it's a python generator of C code.  (And despite my soft spot for it, the same goes for swig.)  I would allow for using something like cinpy (tinycc stuff, does the compiling in memory), but not everyone in the world uses x86, so that's not acceptable either.  I say pygame-ctypes needs to be 100% python to be at all useful.
 
 - I can accept the c-land break for my on some of my games as long as there is a cut-off between using pygame and pygame-ctypes.  At that point I can
 adjust my games to work with the new c-API.

 Phil
 
Alex Holkner <aholkner@xxxxxxxxxxxxxx> wrote:
>  flyaflya wrote:
>
> > Don't remove the C pygame,I think spliting C pygame and  ctypes-pygame 
> > to two separate projects is a good idea,So we will have more 
> > chioce,and ctypes-pygame can have special features itself and needn't 
> > to be compatible with  C pygame.
> > Maybe a reason I choice C pygame is because py2exe can't bundle the 
> > dll files ctypes need to the exe file.
>
> Pygame-ctypes works fine with py2exe.  I used the setup.py:
>
> ---
>
> from distutils.core import setup
> import py2exe
>
> setup(windows=['sample.py'],
>       options={
>         'py2exe': {
>             'excludes': ['Numeric', 'numarray', 'numpy']
>         }
>       })
> ---
>
> The default icon
>  and font are missing, but that is a fixable problem.
>
> Alex.

---

Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates starting at 1¢/min.