On Fri, Jan 30, 2009 at 8:32 AM, Sebastián Gurin <[email protected]> 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 >
