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 <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]> 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 <[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
> >
> >
>
