On 3/5/2010 10:40 AM, René Dudfield wrote:
Hello,
pygame already has a subsurface, which is part of a larger surface. It refers to the same pixels as the surface it comes from. However, sometimes we would like to operate on a whole bunch of smaller surfaces stuck together.
I've done several projects using a full-screen scrolling tilemap. That is, sprites walking around on a blanket of 2D tiles drawn from an array as big as 1000x1000 referencing a set of 50x50 tiles. That wasn't practical to do using a Pygame Surface, due to the size, so each frame the system figured out the range of all visible tiles (based on the POV character's location) and drew those. It wasn't very efficient, but it did work, and it's an example of a surface built from many actual Surface objects. (Will link to code if you want.)
Years ago, someone posted a demo of a faster scrolling-tile engine, but I forget how it worked; if it relies on a Pygame surface that limits the practical size of the level.
The pygame.sprite module has never seemed useful to me, because it seems like a simple container object (it doesn't have drawing functions) and because it assumes that the sprite's pixel size is the same as the size of the object it represents. I try to think in terms of a physical unit system so that I'm not bound to a particular sprite/tile pixel size. Similarly, I always seem to have some reason to redraw everything on the screen (maybe wrongly), so I end up treating the whole screen as "dirty" and missing any optimization there.