Title: 'Unlimited Sprites' Effect

Author: Gareth Noyce (http://www.korruptor.demon.co.uk)
Submission date: Aug 29, 2002

Description: A port of the famous 'Unlimited Bobs' demo effect.

Download: unlimited-sprites.zip

pygame version required: Any
SDL version required: Any
Python version required: 2.0 or newer

Comments: The impressive "Infinite Bobs" visual effect is the latest demo effect to be ported to pygame by Gareth Noyce. Let this one run for a few minutes - you'll be amazed at the amount of motion achieved with a few lines of code. This submission achieves its eye-catching effect without the aid of Numeric and Surfarray.

Messages: 5


"""
Name	:	unlimited 'bobs' - korruptor, http://www.korruptor.demon.co.uk
Desc	:

I first saw this in the Dragons MegaDemo on the A500 back in '89 and it blew me away. 
How gutted I was when Wayne "tripix" Keenan told me how easy it was and knocked up an 
an example demo a couple of years later.

For those of you that didn't know how it was done, here's a pygame example. It's 
basically a flick-book effect; you draw the same sprite in different positions on 
25 different 'screens' and flick between them. When you've drawn on all 25 you loop 
back to the beginning and keep on blitting. 

Sprite offsets make it look like you're adding sprites. Simple.
"""

import pygame, pygame.image
from pygame.surfarray import *
from pygame.locals import *
from math import *


# ------------------------------------------------------------------------------------

RES 		= (480,400)
PI 		= 3.14159
DEG2RAD 	= PI/180
SURFS           = []

# ------------------------------------------------------------------------------------
def main():
     
    	# Initialise pygame, and grab an 8bit display.
    	pygame.init()
    	screen		= pygame.display.set_mode(RES,0, 8)
        bob		= pygame.image.load("bob.gif")
        
        # load a sprite and set the palette
        bob.set_colorkey((255,255,255))
        screen.set_palette(bob.get_palette())
            

        # Create 25 blank surfaces to draw on.
        for i in range(0,25):
            SURFS.append(pygame.Surface(RES,0,8))
            SURFS[i].set_palette(bob.get_palette())

        xang    = 0.0
        yang    = 0.0
        surf    = 0
        
        # Fruity loops...
        while 1:
    
            # Have we received an event to quit the program?
            for e in pygame.event.get():
                if e.type in (QUIT,KEYDOWN,MOUSEBUTTONDOWN):
                    return


            # Get some x/y positions
            x = (RES[0]/2)*sin((xang*DEG2RAD)*0.75)
            y = (RES[1]/2)*cos((yang*DEG2RAD)*0.67)
  
            # Inc the angle of the sine
            xang += 1.17
            yang += 1.39
        
            # blit our 'bob' on the 'active' surface
            SURFS[surf].blit(bob,(x+(RES[0]/2)-32,y+(RES[1]/2)-32))
            
            # blit the active surface to the screen
            screen.blit(SURFS[surf],(0,0))

            # display the results
            pygame.display.flip()

            # inc the active surface number
            surf = (surf+1) % 25
            
        # Bye!
        return

# ------------------------------------------------------------------------------------
if __name__ == '__main__': main()
# End of sauce. Pass the chips...


From: Jake

Date: September 06, 2002 17:14 GMT


Is blitting to an 8 bit display surface faster than to 16 or 32 bit, even when your display system (Win32 or X) is running at a higher depth? Would this affect a HWACCEL surface?

Thanks.

 

From: Futility

Date: September 07, 2002 06:40 GMT

There's no hard-and-fast rule; it depends on what optimisations your driver writers have decided to make. If you're really curious, I'd suggest testing it yourself for your particular combination of driver version and video hardware.

 

From: Codexus

Date: September 08, 2002 11:51 GMT

I remember when I saw that demo on the Amiga too. It was with my coder friends at the Amiga club. For a few minutes, we were blown away. Then I said, "oh, no! that's too easy!", my friends looked at me like I was crazy and I explained the trick to them.

 

From: Anonymous

Date: September 11, 2002 21:17 GMT

The answser is no.

It is (disclaimer: almost) always faster to use the same color depth than a different depth. Your video driver has nothing to do with it, at least as far as software surfaces go. If your pixel isn't in the right format, SDL has to convert it on the fly.

 

From: TheG

Date: January 04, 2003 19:55 GMT

Erm, remove:

from pygame.surfarray import *

It's not needed...

 

Main - Repository - Submit - News

Feedback