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. > > import pygame > > def supersurface(*surfaces): > """*(surface, rect) -> supersurface, *subsurfaces > > Takes surfaces with their rectangles and forms a surface made up of all > of them and the subsurfaces which represent the originals""" > left=min((rect.left for _, rect in surfaces)) > right=max((rect.right for _, rect in surfaces)) > top=min((rect.top for _, rect in surfaces)) > bottom=max((rect.bottom for _, rect in surfaces)) > surf=pygame.Surface((right-left, bottom-top)) > subs=[surf] > for surface, rect in surfaces: > tl=(rect.left-left, rect.top-top) > surf.blit(surface, tl) > sr=pygame.Rect(tl, rect.size) > subs.append(surf.subsurface(sr)) > return subs > > if __name__ == '__main__': > pygame.init() > screen=pygame.display.set_mode((600,600)) > surf1=pygame.Surface((300,300)) > rect1=surf1.get_rect() > surf1.fill((0,0,255)) > surf2=pygame.Surface((300,300)) > rect2=surf2.get_rect() > rect2.left=300 > surf2.fill((0,255,0)) > surf3=pygame.Surface((300,300)) > rect3=surf3.get_rect() > rect3.top=300 > surf3.fill((255,0,0)) > surf, surf1, surf2, surf3=supersurface((surf1, rect1), (surf2, rect2), > (surf3, rect3)) > clock=pygame.time.Clock() > fade=255 > while fade: > clock.tick(15) > fade-=1 > for event in pygame.event.get(): > if event.type==pygame.QUIT: > fade=0 > screen.blit(surf, (0,0)) > pygame.display.flip() > surf1.fill((0,0,fade)) > surf2.fill((0,fade,0)) > surf3.fill((fade,0,0)) > pygame.draw.circle(surf, (255-fade,255-fade,255-fade), (300,300), > 20) > > > > On Tue, Mar 9, 2010 at 3:39 PM, René Dudfield <ren...@gmail.com> wrote: > >> On Sun, Mar 7, 2010 at 6:47 PM, B W <stabbingfin...@gmail.com> wrote: >> > >> > >> > On Sat, Mar 6, 2010 at 11:44 AM, Kris Schnee <ksch...@xepher.net> >> 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 >> > >> > >
