This sounds like a common problem from ages ago when game coordinates were using integer/pixel location vs floats. Every loop/iteration would lose some precision and rounding/truncating would cause jitter every few updates like you have described because pixels would be gained/lost in the math. The idea that a fluctuation of 2-5 frames/second could cause a noticeable display issue like this, as others pointed out, is a very unlikely. I wont say impossible but this all rings very familiar to me even recently when working on HTML5 canvas games where browsers have wide ranges of deltas between updates and even display rates.
Pygame - alternatives?
@Julie.chan It is exactly ONE iteration of the main loop. But every measurement shows exactly the same result. Because it is actually how I described: The game loop code takes very little time and thus on my machine the game has hundreds of FPS when running without limitation.
I have now done a different kind of testing. I have limited the game's FPS to 60 using pygame.Clock, and I have measured the duration from one frame to the next, which should be a very constant value in a perfect world. And if I would do this in a C++/SDL game, it would work too. However, in Pygame, I have the following results:
0.0159058570862
0.0160629749298
0.015741109848
0.0169258117676
0.0149910449982
I picked out some values just to show the variance. As you can see, the numbers range from 15 ms to 17 ms, in a quite unstable manner. This is what I am talking about. I hope now it's clearer.
It is exactly ONE iteration of the main loop.
That's not going to tell you anything useful whatsoever.
But every measurement shows exactly the same result. Because it is actually how I described: The game loop code takes very little time and thus on my machine the game has hundreds of FPS when running without limitation.
Of course the game loop takes "very little time". All game loops do. But you've completely missed the point that running such a short test is completely useless because all your results are getting rounded, and as a result you have zero information about when the slower parts are, which is the meaningful result. Getting multiple results with this pointless single-loop test you have is never going to get you any closer to understanding what's going on because of this.
This is what I am talking about. I hope now it's clearer.
Yes, I know what you're talking about. You're worried that a 0.2% difference of timing, which is perfectly normal, must somehow be the cause of all your problems. But if you want to actually solve the real problem, that being the thing you describe as "jittering" (which is quite vague, and you haven't clarified what you mean by it), you need to drop the pretentiousness and think outside this box you have constructed.
Otherwise, feel free to just drop all your work and start over with C if that's really what you want to do.
Just to let you know, I have replaced all my pygame calls now with pysdl2 calls, and now that it's possible to enable VSync (which is not possible in SDL1, only in SDL2), everything works jitter-free as expected. The rest of the code is 100% identical.
I might wait for the upcoming pygame2, which will be based on SDL2, but if that takes too long, I will stick to PySDL2.
1 hour ago, drwuro said:Just to let you know, I have replaced all my pygame calls now with pysdl2 calls, and now that it's possible to enable VSync (which is not possible in SDL1, only in SDL2), everything works jitter-free as expected. The rest of the code is 100% identical.
I might wait for the upcoming pygame2, which will be based on SDL2, but if that takes too long, I will stick to PySDL2.
You can use pygame 2 now with SDL2 if you want to compile from source. It's two lines on Desktop platforms to download dependencies and compile. https://www.pygame.org/wiki/Compilation
2 hours ago, renedudfield said:You can use pygame 2 now with SDL2 if you want to compile from source. It's two lines on Desktop platforms to download dependencies and compile. https://www.pygame.org/wiki/Compilation
ah yes, I will try that :) I think you also suggested this to me on discord yesterday, is that possible?
if that works fine I might switch to Pygame2 immediately :)
@renedudfield do you know whether Pygame2 will also use SDL2's "renderer" functionality? (i.e. Textures instead of Surfaces) or will that still use the normal Surface stuff?
22 hours ago, drwuro said:ah yes, I will try that I think you also suggested this to me on discord yesterday, is that possible?
if that works fine I might switch to Pygame2 immediately
Ah yes. This conversation felt familiar. hehe
20 hours ago, drwuro said:@renedudfield do you know whether Pygame2 will also use SDL2's "renderer" functionality? (i.e. Textures instead of Surfaces) or will that still use the normal Surface stuff?
It can use Textures, and Renderers. See examples/video.py. The old API uses Surfaces, but the scaling is done in hardware. Which makes even using surfaces quite a lot quicker than with SDL1. The nice thing is you can use that API, and have things work quickly on software only platforms (embedded mostly these days).