[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] super surface... a surface made up of many smaller surfaces



On Sat, Mar 6, 2010 at 7:44 PM, Kris Schnee <kschnee@xxxxxxxxxx> wrote:
> 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.
>

yeah, cool.  I remember a few of them.

> 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.
>

yeah, I think a super surface will be better for some.  Mainly because
it shares the same interface as a Surface.

Off topic... but related:  Spreading updates over frames is another
optimization that is useful for full screen games.  In effect you
change the FPS of some elements.  That way certain elements might only
get updated every third frame (as an example).  This is good for
things like text, or status bars - which although they do change, do
not need to change with the same frequency.