RE: [pygame] sForzando speed update

["Michael Robin" <vimakefile@yahoo.com>]

>I really have no idea what's up at this point.  It seems like redrawing the
>whole screen every frame is actually FASTER than redrawing small bits of it
>that change.  I don't have a clue why.

I had a similar experience. There are two things may be involved??
(BTW, I'm on Win2k/DirectX drivers.)

(1) The BLT code is super-optimized assembly or C, perhaps with hardware
support, at least in Fullscreen. The more stuff you do in the Python
interpreter, the slower you can be. When I was working on my game, I added
lots of "smarts" - not only was it complicated, but it didn't speed things
up at all. (Ended up about even.) Because my game was vector- and not
blt-based (with transformations in python), this was probably more
pronounced for me than usual though.

(2) In hardware modes, I got some kind of refresh "interlocking" going on. I
would gradually increase the number of game objects drawn, and it wouldn't
slow down at all, until the # reached a certain point and then it would slow
down in "quanta" that was a multiple of the frame rate. (E.g, the frame rate
would be about 60fps, then about 30fps, then 15, etc., but didn't really
land in-between. When I was on a "cusp", the screen would visibly jitter
because one frame would take X fps, but an X/2 fps frame would crop up every
so often (or visa-versa). Some code (DirectX?) was aparently spin-waiting
for the next frame to be ready to draw or something.

mike


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

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