No.
With .convert()
ncalls tottime percall cumtime percall filename:lineno(function)
64120 0.725 0.000 0.725 0.000 {method 'blit' of
'pygame.Surface' objects}
610 1.212 0.002 1.212 0.002 {method 'fill' of
'pygame.Surface' objects}
610 7.201 0.012 7.201 0.012 {pygame.display.update}
Now I feel like a a real idiot! Surprising how much difference that makes.
Cheers for the help
Chris
2008/11/20 René Dudfield <[EMAIL PROTECTED]>
> Hi,
>
> have you used convert() on the surfaces you are blitting?
>
>
>
> On Thu, Nov 20, 2008 at 11:47 PM, Chris Smith <[EMAIL PROTECTED]> wrote:
> > 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
> >> >
> >> >
> >
> >
>
