Thanks for taking the time Peter to do this benchmark, but I don't believe that this is testing the overhead that exists in the pygame C code. To clarify, your benchmark is slightly contrived in that it is doubling the python workload, when I am interested in seeing the results of getting lower to SDL blitting. I get your message, I am absolutely clear that python is generally the bottleneck. If you can find a way to isolate and test the following parts of the C extension library, I would be happy to see the results.
https://bitbucket.org/pygame/pygame/src/d61ea8eabd56025fcb4ceb24d63f9a6a30fbe8d4/src/surface.c?at=default&fileviewer=file-view-default#surface.c-2988:3114 On Mon, Mar 14, 2016 at 12:06 PM, Peter Finlayson <frnkn...@iafrica.com> wrote: > On 2016/03/14 04:35 PM, herve wrote: > >> before being a skilled pygame developer, there is a newby developer and >> _maybe_ >> giving him good performance for simple things will let him stay and >> growing to >> skilled developer. >> > > A newbie developer seeing a "faster" unchecked function, trying to use it, > and then getting discouraged when it inevitably fails... That is exactly > why unsafe_blit() is a bad fit for Pygame. > > If you want a quick benchmark to show you are barking up the wrong tree, > you can do one at home, with no C experience needed! Take some game code > you wrote, and run it three ways: > > 1. Once unaltered > 2. Once where you run the sprite update code twice (logic, movement and > physics) > 3. Once where you draw every sprite twice > > Record the FPS every time and see if that shows you where the real > bottleneck lies. Here are the results I got from one of my projects: > > 1. Base: 125 FPS > 2. Double logic: 75 FPS > 3. Double draw: 115 FPS > > I had to take the game all the way up to 6x draw calls per frame (4000+ > blits!) before I got it down to the 75 FPS mark. > > The point here is that if I was writing a game to have even double the > sprites I do now, the game logic overhead would be the problem. Even if the > unsafe_blit() magically doubled the speed of my draw routines, it would > have little effect on my overall frame rate. > > Regards, > Peter Finlayson >
