>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
