Well, I did some quick profiling, and here is what I mean.
If we say that I have a maximum FPS of 60, and each 'frame' takes just over
1/60th of a second, then yes, I will get 30 FPS as the screen flipping waits
patiently for the raster to get back to the start of the screen.
My original code got this (a few functions removed from the profile output
not relevant):
Software surface (turned out to be quicker than a hardware surface), 30 FPS:
ncalls tottime percall cumtime percall filename:lineno(function)
64120 9.394 0.000 9.394 0.000 {method 'blit' of
'pygame.Surface' objects}
610 1.505 0.002 1.505 0.002 {method 'fill' of
'pygame.Surface' objects}
610 7.860 0.013 7.860 0.013 {pygame.display.update}
So I culled 2/3's of the blitted objects (they are all 64*64 images):
Only blit about one third, in software, 39 FPS:
ncalls tottime percall cumtime percall filename:lineno(function)
22600 3.236 0.000 3.236 0.000 {method 'blit' of
'pygame.Surface' objects}
610 1.208 0.002 1.208 0.002 {method 'fill' of
'pygame.Surface' objects}
610 10.163 0.017 10.163 0.017 {pygame.display.update}
So now my blitting is 3x faster but - hey update is taking *longer*! I
thought I would see a 'sudden' jump from 30 FPS to 60, but that is simply
not the case. Just for comparison, I tried it with *no* blits:
No blits or fills, 120 FPS
ncalls tottime percall cumtime percall filename:lineno(function)
610 5.115 0.008 5.115 0.008 {pygame.display.update}
Seems logical enough. but that middle result at 39 FPS I don't understand.
Chris
2008/11/20 Jake b <[EMAIL PROTECTED]>
> My guess is your surface type is wrong/not matching, so its re-converting
> it on every op, making it slow.
> For fills, I think you want software surface, not hardware
>
> (If you mix a hardware surface with a software one, or there might be other
> bad combinations too )
> --
> Jake
>
