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