Re: [pygame] GSoC: Improved Sprite and scene system

[Peter Gebauer <peter.gebauer@xxxxxxxxxxxxxxxxxxxxx>]

Hi there James!

If this could be timed with the Python 3.0 release that wouldn't be
as much of a problem. In any case, the suggestion about a more
abstract type would help maintain backwards compatibility while
allowing a new sprite engine to grow.

In any case, the sprite-stuff in pygame is pretty useless, it's
too lightweight and not easy enough to build on, in particular if
you're using non-blitting engines. I always end up writing a new
sprite engine.
Lately I've even abandoned the Python collision detection in favour
of various physics libraries, as well. They usually support better
handling of collisions like giving information about where and when
two objects would first have collided, penetration depths and supporting
callbacks. 
The main problem is that none of them execute collision checking
without also executing the physics. There are ways to work around
this, but you still get the overhead of emulating physics.

A nice sprite engine would support layers, texture animation and LERP's
for moving, transforming and effect changes. As a bonus it would
be nice to have abstract types (or flags for speed) for built-in
OpenGL effects like lighting, bumpmapping and such.
This coupled with an abstract, yet fast collision implementation
in a separate project/module would be awesome.

That's just the stuff I'm looking for anyway. :)

/Peter


On 2009-03-20 (Fri) 07:37, James Paige wrote:
> On Thu, Mar 19, 2009 at 10:39:23PM -0300, Erisvaldo Junior wrote:
> > Hi Peter,
> > 
> > Thanks for your feedback. I'll add the collision improvements in my 
> > proposal.
> > 
> > Do you people agree that Sprites should be removed from Pygame?
> 
> Absolutely not!
> That would totally break a large number of older pygame games if one 
> tried to run them with a newer spriteless version of pygame.
> 
> ---
> James Paige