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

[Kris Schnee <kschnee@xxxxxxxxxx>]

On Wed, 10 Mar 2010 12:38:46 -0600, "RB[0]" <roebros@xxxxxxxxx> wrote:
> The biggest problem with that is that pygame limits the size of any one
> surface - at least for me.
> I can't remember what it was but somewhere around 16k x 16k pixels?
> 
> On Wed, Mar 10, 2010 at 7:19 AM, Nikhil Murthy <murthynik1@xxxxxxxxx>
> wrote:
> 
>> This is not in the least meant to be a serious solution for super
> surfaces,
>> it is just an idea I had and tried out for the fun of it.

It looks like Murthy's solution involves blitting the smaller surfaces onto
a single larger surface. That's a straightforward way to build a composite
surface, but as RB[0] notes it doesn't do anything to save RAM versus
making a giant surface in the first place. I figured we were talking about
ways to get the effect of a giant surface without actually making a canvas
with that many pixels.

Eg., if you want a game level that's 1000x1000 tiles where each tile is
50x50 pixels, making one big surface means a single 50,000x50,000 surface,
2,500,000,000 pixels, times several bytes per pixel depending on color
mode. Ie. several Gb of memory. Not practical! If instead you store each
type of tile as a single 50x50 surface and just reference them with a
list-of-lists (so you can say "draw the tile referenced at
self.tiles[x][y]"), you instead have a 1000x1000 array (1,000,000 entries
times a few bytes) plus the memory usage of (probably) at most a thousand
50x50 tiles (2.5 Mb * bytes_per_pixel). So, a few megs versus a few _gigs_
of memory.

It's the speed and ease of use of this kind of tile-based engine that we've
been talking about optimizing, right? Or do I misunderstand what people
mean by a supersurface?