[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 3/7/2010 1:47 PM, B W wrote:
[Me:]
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.
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.
Interesting. My method was the obvious one of saying that if the
player's at tile (100,100), and the screen's 20 tiles wide, then we draw
a range of 20+ tiles from about 90 to 110. The math _should_ be pretty
efficient for what it does, so my guess is that the Group.draw() logic
is something Pygame has pre-optimized with a bit of C code. Maybe I
should've used Psyco or learned enough C to write my own optimization,
if it became that important.
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.
That's what I ended up doing with the recent "squirrel demo": having a
map with many "None" entries and drawing a tile only if it's not None.
That seemed to help the speed, but wasn't suitable for the original
landscape thing I did.
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.
Even the professional "Elder Scrolls" games ("Morrowind", "Oblivion" &c)
had trouble with that. They ended up treating building interiors as
separate spaces such that you could never look into or out of a
building, and there were other kludges. In "Oblivion" levitation spells
ceased to exist, so that cities could become separate world-spaces and
other areas could be walled off by conveniently placed mountains.
Another detail was that NPCs could follow you between spaces in
"Oblivion", but only through an obvious fade-in teleportation method.
Interestingly, the game engine in "Oblivion" doesn't totally rely on the
cities being separate spaces; fans have made "Open Cities" mods.
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...
Hmm. I'd be interested in those things too. I've got code for sprite
animation and A* pathfinding as well as the tile engine, so I'd be
interested in talking about these and better ways of doing them.