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