[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Limited FPS?



I measure the FPS by adding up the time taken (or what the profiler tells me), and dividing the total frames by that.

My do_stuff() is real small because I pre-calculate almost everything. 0.066 seconds spent over 610 frames, so I'm pretty sure it's the update() routine that's doing it.

I know 30 FPS is reasonable for most games, I have a fancy gfx effect that is a tad too slow at 30 FPS. I was hoping a quick fiddle would suddenly give me to 60 FPS but it doesn't seem to work like that.

Chris

2008/11/20 René Dudfield <renesd@xxxxxxxxx>
hi,

Try and time the code before update each frame.  Then time the update
call each frame.

Something like this:

t1 = time.time()
do_stuff()
t2 = time.time()
pygame.display.update(rects)
t3 = time.time()

That should tell you how long each part is taking, and from that you
can check if your do_stuff is taking up too much time or not.


Also, can probably just limit the frame rate to 30fps for a lot of games :)

How are you measuring the fps?  If you use pygame.time.Clock.tick() it
can pause the game.


cu!





On Thu, Nov 20, 2008 at 11:24 PM, Chris Smith <maximinus@xxxxxxxxx> wrote:
> 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 <ninmonkeys@xxxxxxxxx>
>>
>> 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
>
>