Re: [pygame] super surface... a surface made up of many smaller surfaces
The largest surface my laptop can handle is 16383x16383
Re: [pygame] super surface... a surface made up of many smaller surfaces
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 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 wrote: > >> On Sun, Mar 7, 2010 at 6:47 PM, B W wrote: >> > >> > >> > On Sat, Mar 6, 2010 at 11:44 AM, Kris Schnee >> 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
Re: [pygame] super surface... a surface made up of many smaller surfaces
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 wrote: > On Sun, Mar 7, 2010 at 6:47 PM, B W wrote: > > > > > > On Sat, Mar 6, 2010 at 11:44 AM, Kris Schnee 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 structu
Re: [pygame] super surface... a surface made up of many smaller surfaces
On Sun, Mar 7, 2010 at 6:47 PM, B W wrote: > > > On Sat, Mar 6, 2010 at 11:44 AM, Kris Schnee 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 >
Re: [pygame] super surface... a surface made up of many smaller surfaces
On Sat, Mar 6, 2010 at 7:44 PM, Kris Schnee wrote: > On 3/5/2010 10:40 AM, René Dudfield wrote: >> >> Hello, > >> pygame already has a subsurface, which is part of a larger surface. >> It refers to the same pixels as the surface it comes from. >> >> 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.) > > Years ago, someone posted a demo of a faster scrolling-tile engine, but I > forget how it worked; if it relies on a Pygame surface that limits the > practical size of the level. > yeah, cool. I remember a few of them. > The pygame.sprite module has never seemed useful to me, because it seems > like a simple container object (it doesn't have drawing functions) and > because it assumes that the sprite's pixel size is the same as the size of > the object it represents. I try to think in terms of a physical unit system > so that I'm not bound to a particular sprite/tile pixel size. Similarly, I > always seem to have some reason to redraw everything on the screen (maybe > wrongly), so I end up treating the whole screen as "dirty" and missing any > optimization there. > yeah, I think a super surface will be better for some. Mainly because it shares the same interface as a Surface. Off topic... but related: Spreading updates over frames is another optimization that is useful for full screen games. In effect you change the FPS of some elements. That way certain elements might only get updated every third frame (as an example). This is good for things like text, or status bars - which although they do change, do not need to change with the same frequency.
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.
Re: [pygame] super surface... a surface made up of many smaller surfaces
On Sat, Mar 6, 2010 at 11:44 AM, Kris Schnee 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. 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. 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... But if your thoughts go in another direction, René, I would love to hear more. Gumm
Re: [pygame] super surface... a surface made up of many smaller surfaces
On 3/5/2010 10:40 AM, René Dudfield wrote: Hello, pygame already has a subsurface, which is part of a larger surface. It refers to the same pixels as the surface it comes from. 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.) Years ago, someone posted a demo of a faster scrolling-tile engine, but I forget how it worked; if it relies on a Pygame surface that limits the practical size of the level. The pygame.sprite module has never seemed useful to me, because it seems like a simple container object (it doesn't have drawing functions) and because it assumes that the sprite's pixel size is the same as the size of the object it represents. I try to think in terms of a physical unit system so that I'm not bound to a particular sprite/tile pixel size. Similarly, I always seem to have some reason to redraw everything on the screen (maybe wrongly), so I end up treating the whole screen as "dirty" and missing any optimization there.
