On Wed, 10 Mar 2010 12:38:46 -0600, "RB[0]" <roeb...@gmail.com> 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 <murthyn...@gmail.com> > 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?