Re: [pygame] sForzando speed update

[Richard Jones <richardjones@optushome.com.au>]

On Sat, 3 Nov 2001 15:54, Michael Robin wrote:
> >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??

I'd say definitely.


> (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.

Yep. My advice is to figure where you're doing your most complicated 
calculations and try to abstract them out into a separate bit of code. Once 
you've done that, you have some psuedo-code you can turn into a C module. C 
modules, thanks to distutils, are a cinch to compile (though on Windows, 
you'll need VC++). C module programming is pretty easy, expecially if you're 
just moving something like a vector normalisation routine off into C. The 
example code that ships with Python is pretty good to use as skeleton code.


> (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.

Sounds like you're double-buffering. That sort of system will usually wait 
for a new screen refresh to actually flip the buffers, so the screen doesn't 
flicker. Hence the slowdown is pretty much a screen quanta at a time.


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