Re: [pygame] Limited FPS?

["René Dudfield" <renesd@xxxxxxxxx>]

yeah, it's an annoying thing.

It might be cool if there were some optional warnings for blitting
non-converted surfaces.



On Fri, Nov 21, 2008 at 12:28 AM, Chris Smith <maximinus@xxxxxxxxx> wrote:
> 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 <renesd@xxxxxxxxx>
>>
>> Hi,
>>
>> have you used convert() on the surfaces you are blitting?
>>
>>
>>
>> On Thu, Nov 20, 2008 at 11:47 PM, Chris Smith <maximinus@xxxxxxxxx> 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 <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
>> >> >
>> >> >
>> >
>> >
>
>