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
> >
>
