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
>> >
>> >
>
>