aconstlink
commented
3 years ago One reason for the stuttering might be in the interval timing for the particular on_* callbacks in the app class. The stuttering became quite annoying.
There are several on_* function like on_physics, on_logic, on_render, on_update and so forth. The delta time for each of those functions is calculated individually. It turned out, this can not be done. Theoretically, there should be no issue at timings in microseconds range, but there actually is when the bounds of the intervals are hit.
The solution is to make a single delta time computation before any callback and use that delta to increment all the individual timings. So every system is incrementing based on one timing. Commiting soon.
Somewhere in the engine an issue causes continuous "smooth" movement of objects(i.e. sprites) to stutter during movement. For a very small fraction of time the image can be seen stuck and then pops back to its position where it should be.
If vsync is disabled, the movement is much smoother. So the problem should lie somewhere with rendering.
What could cause the problem? There are two main points that cross my mind:
The first issue is already taken care of, but didn't really change the appearance of the original issue much. The second one is something I wanted to tackle for some time anyway. This one could be a good guess. The d3d11 renderer should be easy, because it already uses constant buffers. OpenGL and ES is not so trivial, because those renderer do not use uniform buffers yet, so variables are updated and uploaded just before rendering. If the data update could be done before the point of rendering, the async renderer could release the entry lock to the renderer so the next frame could be prepared while the scene is rendering.