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

[René Dudfield <renesd@xxxxxxxxx>]

On Sun, Mar 7, 2010 at 6:47 PM, B W <stabbingfinger@xxxxxxxxx> wrote:
>
>
> On Sat, Mar 6, 2010 at 11:44 AM, Kris Schnee <kschnee@xxxxxxxxxx> wrote:
>>
>> On 3/5/2010 10:40 AM, René Dudfield wrote:
>>>
>>> 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.)
>>
> I did something very similar with Gummworld. The supersurface was not a
> single Pygame surface, rather a virtual surface made of a 2D array of
> sprites each with its own image. The Pygame drawing surface was the visible
> display; only I found that Group.draw()-ing all the terrain sprites and
> allowing Pygame to automatically crop them was in larger cases more
> efficient than cropping the drawing scope in Python. Still, it did indeed
> waste memory having all those sprites, each with their own image, outside
> the display area. The level design was rectangular, and if the map is
> irregular then large portions of the supersurface could possibly have many
> unused sprites; which led to a crude sparse map implementation, where an
> array cell with a None value would be ignored. It's a simple paradigm in
> which the special cases tend to center around conserving memory and CPU.
>


cool, that sounds good.

> That initial attempt got me thinking about a room paradigm. A level is
> analogous to a building or a floor with rooms connected by exits. Rooms
> don't necessarily have walls, and exits are not necessarily visible. They
> are just internal geographic and navigational elements, respectively. An
> exit links two rooms. Exits can be visible objects such as a door or portal
> or an invisible line on the ground. Using an exit changes the interactive
> context from room A to room B. If you choose so, your room could scroll.
> With some drawing savvy neighboring rooms could scroll seamlessly. The
> player might not even notice that an exit was used and there was a room
> change.
>
> Though the room paradigm seems elegant to me and potentially
> memory-efficient, it presents its own significant challenges: resource
> management (real-time loading and garbage cleanup); game hiccups from
> resource management; spacial relationship of rooms and exit "hot spots";
> interacting with objects through an exit; room linkage errors.
>


This sounds like 'portals' used in some 3d engines... and called rooms
in engines like the old duke nukem engine.


> So on the one hand we have a level structure that is easy on the programmer
> and harder on the machine; on the other a structure that's easy on the
> machine and harder on the programmer. I know others have solved such issues,
> and there are game engines that provide a display/resource/world/etc.
> management framework so you can focus on game intelligence, content, and
> world design. But they are systems and languages unto themselves, and if I
> don't like an aspect I can't always change it. That is why I was happy to
> find Pygame.
>
> But not for the first time I am thinking it would be awesome to have some
> higher level toolkits, somewhere comfortably between Pygame and a full-blown
> game engine. It seems many of us have put a lot of time and effort into such
> toolkits, with varying degrees of success. I am wondering if the
> supersurface would fit better as an "official-like" Pygame add-on. It might
> even trigger a series of integratable toolkits that offer standard ways of
> solving higher level problems like I've seen suggested: scenes, tiling,
> transitions, map scrolling, path-finding. =) *cough* Me and my grand
> schemes...
>

That would be grand... I think :)  Super surfaces might need to be
done at the C level so that various routines can work with either a
super surface or a surface efficiently.  Can probably prototype a
pretty good version in python first... then move it to C if needed.

An official addon project could be good too.  There's a number of
various add on libraries around, perhaps having an official one will
work better.  I'm not sure.

> But if your thoughts go in another direction, René, I would love to hear
> more.
>
> Gumm
>