Re: [pygame] starting questions

[René Dudfield <renesd@xxxxxxxxx>]

On Fri, Jan 30, 2009 at 8:32 AM, Sebastián Gurin <sebastigurin@xxxxxxxxx> wrote:
> Hello all. I'm just starting with pygame. I'm droping the following
> questions, any help or references are welcome:
>
> *) LAYERS - z-index in sprites. I think i've understanded the concepts
> of sprites, rect, surface well but I can't find a way of managing
> sprite layers. I need to 1) i need to set the zIndex attribute for
> sprites so when they overlap with another one is showed on top of the
> other. I also need 2) a way of know the top most sprite that receives
> a mouse event. I would like to know if this stuff is already present
> in pygame api, or if I have to create/simulate it by hand.
>

As Marcus says... the LayeredDirty sprite classes can do all this
stuff efficiently.

> *) GUI lib. What gui light library do you recommend me?. (theme
> support would be nice). I like pgu's
> (http://www.imitationpickles.org/pgu)  gui module, but their site -
> releases seems to be old (2007); is pgu project active?
>

pgu has been abandoned by phil, and phil is looking for a new
maintainer for pgu... so I can't really recommend that.

I'm not really sure what to recommend for GUIs.  Probably write your
own.  Maybe ocempgui... but Marcus plans a rewrite.


> *) events in games. I come from the GUI visual world (html, gtk,
> swing) and I used to attach events to visual objects. In pygame
> examples I see the programmer must capture a global event and find the
> related object. does pygame support the first? (something like
> "aSprite.addMouseListener(listener)" ?)


It's kind of a nicer way to handle events.  As events become first
class objects, rather than callbacks.

It means you have a lot more flexibility about how your events are
routed, and for the simple cases it becomes simple to use.  You can
easily route events in your own way... and people have built their own
event systems on top of pygame events.  Lots of people do it
differently...

I like to make separate objects which behave like separate pygame
programs.  Then you can test them separately, and also add the objects
how you like.

eg.
http://rene.f0o.com/~rene/stuff/game.py

from game import Game

class g(Game):

    def update(self, elapsed_time):
        Game.update(self, elapsed_time)
        # update your object here.

    def draw(self, screen):
        rects = Game.draw(self, screen)
        # draw your things here...
        return rects

    def handle_events(self, events):
        Game.handle_events(self, events)

        # handle your events here...

        for e in events:
            if e.type in [KEYDOWN]:
                pass

    def load(self):
        Game.load(self)
        # loading stuff here.


Notice how it allows you to pass in a screen, your events, and the
elapsed time.  This means you can abstract away those things from
pygame.  You decide the amount of elapsed time, and also what surface
to draw on.  They could be real values, or perhaps you've recorded
some events yourself that you're playing back, and the surface is
actually a part of the real screen(a subsurface) -- and the
elapsed_time is really  `elapsed_time / 4.` -- bullet time.  It also
means you can reset each one with it's load method, whenever you want.

The basic Game class allows automatic passing and handling of draw,
load, event, update down to children Game instances... held in each
ones .games attribute.  It also allows stopping of each Game, or
pausing each Game.


Anyway... that's just one option.  You could also keep your event
processing separate from your game objects.



>
> *) OLPC: have somebody experience in developing pygames for olpc (one
> laptop per child)?

There's an OLPC games mailing list with people interested in games on
olpc.  http://lists.laptop.org/listinfo/games

Also there's a few people who lurk here who have made OLPC games with pygame.


>
> Well, thanks in advance and excuse my poor english.
>
> Sebastián Gurin
>