Re: [pygame] GD Zine mentioned on pygame.org

[Pete Shinners <shredwheat@attbi.com>]

Jonathan Atkinson wrote:
> Thanks for the mention, I'm really flattered. Could you fill me
 > in on the mistakes in my code? I'll amend them if necessary, I'd
 > like the zine content to be as accurate as possible. I'd only
 > been using PyGame for about 2 weeks when I wrote that article
 > (which doesn't really make me an expert, I guess, but I like
 > to write about what I'm interested it).

i think there's only one real "error", but there are other things that 
aren't quite "proper use" of python and pygame. of course, since you've 
only seen pygame for 2 weeks, that's not a terrible crime :]

the error is "from pygame import *". it should just be "import pygame", 
since you later refer to the pygame module.


     screen = pygame.display.set_mode((640,480), 0, 8)
     pygame.display.toggle_fullscreen()

this code will not really do what you want. the toggle_fullscreen function 
only works for X11 displays, not windows or any of the other unix rendering 
backends. the best way to get fullscreen is to just pass it in as a flag.

    screen = pygame.display.set_mode((640, 480), FULLSCREEN, 8)

and actually, you are often best off just not passing the final "bit depth" 
flag, so pygame can choose the fastest color depth..

    screen = pygame.display.set_mode((640, 480), FULLSCREEN)


your animation doesn't "erase" or "clear" the position of the old sprite 
image. in your simple example this will work ok if the sprite has a 1 pixel 
border the same color as the background, but usually that's not going to work.

your input loop doesn't check for the QUIT events, which is usually nice 
when the program is supposed to end.

as for the animation loop, usually breaking the animation into its own 
smaller loop is not the best idea. it works fine for simple examples like 
yours, but in a "real game environment" it will of course stop everything 
else from happening while animating. here's a more cooperative and cleaner 
version of the same thing. (plus it is a better showcase for python?)


     moves = {K_UP:(0,-1), K_DOWN:(0,1), K_LEFT:(-1,0), K_RIGHT(1,0)}
     move = 0, 0
     rect = playersprite.get_rect()
     rect.center = 320, 200
     done = 0
     steps = 0
     while not done:
         for event in pygame.event.get():
             if event.type == QUIT:
                 done = 1
             elif event.type == KEYDOWN:
                 if event.key == K_ESCAPE:
                      done = 1
                 elif event.key == K_SPACE:
                      move = 0, 0
                      rect.center = 320, 200
                 else:
                      newmove = moves.get(event.key)
                      if newmove:
                           steps = 16
                           move = newmove
         if steps:
             steps -= 1
             dirty1 = screen.fill((0, 0, 0), rect)
             rect = rect.move(move)
             dirty2 = screen.blit(playersprite, rect)
             pygame.display.update((dirty1, dirty2))


this code will do the same thing as your animation code, with a couple of 
added benefits. first, it will properly erase the old sprite before drawing 
the new one. it also passes the "changed areas" to the display.update() 
function, which will run incredibly faster. finally, it will also allow the 
user to quit or "change direction" during the time the sprite is animating.


whew.. i think that's everything :]
don't take this harsh or anything, i always love to see the "pygame 
propaganda" out there. it was a nice surprise to find your little zine and 
mention of pygame included. i suppoe the tiling engine is in the next issue :]





____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org