>As for the splitting the sprites, I considered that. The problem is that when >a row is complete (just like in >Tetris), a whole piece that fell wouldn't >necessarily disappear, but only part of one. I guess I could separate >each >piece into multiple sprites, but that would involve dozens of sprites and I >don't think that the tracking >of it would be any better than what I have >right now.
It might make collisions, and lining up of colors easier you you did it something like this: Have a Block() object for each of the 'squares' that makes up a Piece. So the line actually spawns 3 Blocks() right after another, so it looks like one object. I would find that easier to do collisions for the more complicated shapes --- unless you are already doing it this way. ----- I ran the program, and see it. I tried finding the problem, but I'm not sure where it is. ( seems kinda random when it does or not show up. ) I think it's time to re-factor your code. It would make it a lot clearer, and you'll probably fix the problem in the process. You might want to grab the shootorial py code I just posted on the mailing list to use as a template. Then fill in your upate() and draw() code. The code includes class Text() which auto-manages a bunch of pygame.font related things. ( loads font, only re-renders text if something has changed, etc... ) This lets you do something like: def loop() """Doing a single loop like this, then branching your 'draw' and 'update' functions based on mode can make it clearer to navigate""" if mode == 'titlescreen': self.text.text = "Rastras" self.text.size = 32 do_titlescreen_event_handling() draw_titlescreen() elif mode == "game": self.text.text = score self.text.size = 16 do_game_event_handling() draw_game() def draw_titlescreen(): self.text.draw() #draw buttons, etc... def draw_titlescreen(): self.text.draw() #draw blocks, etc.... # ie: you can do repeated calls to set text to "Rastras", yet it only needs to render the text once, and blits the cached surface. -- hope that helps, Jake