RE: [pygame] How fast is pygame meant to be?

[Christian Perfect <cp@byline.co.uk>]

thanks for your help :)
I'm not exactly sure what I was thinking when I wrote AND for the flags, but
it definitely wasn't right :P
Thanks for the tip about global vars - I didn't know about that.
I've implemented your changes (and the index thing for handling the frags
jozef posted) and it runs at 80fps when there's nothing happening, but slows
down to around 15/20 fps when there are lots of frags on screen. I think my
question's answered, then - don't use pygame for pixel plotting :P

Another observation - hardware acceleration doesn't seem to be available in
windowed mode. Is it meant to be?

I've uploaded the new code to the same address -
www.ebizimonkey.com/firepaint.py, if anyone wants to check the frame rates.

Thanks for your help,
	Christian Perfect

-----Original Message-----
From: Pete Shinners [mailto:pete@visionart.com]
Sent: 03 June 2002 21:11
To: pygame-users@seul.org
Subject: Re: [pygame] How fast is pygame meant to be?


Christian Perfect wrote:
> 	I'm a Blitz Basic (www.blitzbasic.com) user who's been playing
> aroudn with pygame, so the first thing I decided to do was to make a
pygame
> version of the "firepaint" demo that comes with BB. It's a simple demo
that
> shoots sparks from your mouse cursor that fall to the screen when you
click
> the mouse.  I'm no good at optimising, so the code just follows the BB
> firepaint demo pretty closely. When I ran the demo, it ran *much* slower
> than the BB demo, at 8fps, whereas in BB it runs at my refresh rate
(80fps+)
> Is pygame just not meant to be used for this kind of thing, and just
> blitting a few images and playing some sounds, or is there some secret
> different way of doing things I haven't found yet? :)

this big difference you are seeing is the difference between 
hardware accelerated graphics and not. i'm guessing blitzbasic only 
works with directx, therefore you probably only get hardware 
accelerated graphics.

in pygame you can also get hardware acceleration, but it's not 
always the case. i've made a couple changes to your code. it should 
now get hardware accelerated if it is supported on your system. i 
tested it on a NT4 machine with no directx. at 300mhz the program 
ran at 26fps with no frags, and 23fps with a couple explosions 
onscreen. with hardware acceleration i'm guessing you will also be 
at 80fps like bb.

here's the main set of changes i made (attached is the slightly new 
version)

first, you were assembling your 'set_mode()' flags slightly wrong. 
you had "HWSURFACE and DOUBLEBUF and FULLSCREEN". this is using 
python's "logical and" operation. what you need is the "bitwise or" 
operation. so this should become "HWSURFACE|DOUBLEBUF|FULLSCREEN".

second, i wrapped all the code into a function named "main". the 
main reason for this was so the game didn't need to access "global 
variables" when it is running. in python global vars are a little 
slower than normal local variables. in code that is called very 
frequently (like frag.update) you can start to notice this difference.

i changed the "pygame.draw.rect" code to "Surface.fill" which will 
do the same thing here for you. the Surface.fill has the benefit of 
being hardware accelerated when it can be.

that's pretty much it. i believe with the acceleration enabled this 
will run plenty quick for you. if not it could definitely be 
rearranged to run faster. if you want to explore that road let me know.

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