Fixed timestep with interpolation - 2D movement jitter/stutter - General and Gameplay Programming

Crowbone · 2023-08-21T21:24:26

I've been trying to implement frame-rate independant motion for a simple 2D example (rectangle moving across the screen) written in C++17/SDL 2.0.10 on Windows 10. My monitor refresh rate is 60Hz and I have my physics update running at 60 updates per second. The problem is that I'm using linear interpolation but my rectangle still jitters/stutters only when there is no fixed update during a frame render and I cannot understand why. I have: Checked for precision issues with floating-point numbers calculating alpha (seems ok) Checked possible overflows with nanosecond precision (seems ok) Increasing/decreasing physics update rate to be greater/less than frame rate (jittering still present) Enabling/disabling VSync (no difference) Logged the output of the interpolated drawing position (no abnormalities in position) Every article I have read says that interpolation is the solution to smooth movement so why does it still jitter? What's wrong in my implementation? Code example: #include <cassert> #include <SDL.h> #include <chrono> constexpr int WINDOW_WIDTH = 640 * 2; constexpr int WINDOW_HEIGHT = 480 * 2; constexpr int RECT_WIDTH = 128; constexpr int RECT_HEIGHT = 128; struct Window { unsigned long long lastSecond{}; unsigned long long frames{},lastFrameTime{}, frameTime{}; unsigned long long fixedUpdates{}; unsigned long long accumulator{}; unsigned long long now{}; }; Window window; SDL_Window* mainWindow = nullptr; SDL_Renderer* renderer = nullptr; float cx = 0; float cy = 64; float px = cx; float py = cy; float rx = 0; float ry = 0; float xspeed = 1.0f; float yspeed = 0; auto NOW() { using namespace std::chrono; return duration_cast<nanoseconds>(high_resolution_clock::now().time_since_epoch()).count(); } void update() { // for brevity } void drawRectangle(const float x, const float y, uint8_t red = 0, uint8_t green = 0, uint8_t blue = 0) { // Draw rect auto result = SDL_SetRenderDrawColor(renderer, red, green, blue, 0xff); assert(result == 0); SDL_FRect fillRect = { x, y, RECT_WIDTH, RECT_HEIGHT }; result = SDL_RenderFillRectF(renderer, &fillRect); assert(result == 0); } void render() { window.frames++; // Clear black auto result = SDL_SetRenderDrawColor(renderer, 0, 0, 0, 0); assert(result == 0); result = SDL_RenderClear(renderer); assert(result == 0); drawRectangle(rx, ry, 0xff); // Present to screen SDL_RenderPresent(renderer); } void fixedUpdate() { window.fixedUpdates++; px = cx; py = cy; cx += xspeed; cy += yspeed; } int main(int argc, char* argv[]) { #define NS_PER_SECOND (1000000000) #define TARGET_FPS (60) #define NS_PER_MS (1000000) window.lastFrameTime = NOW(); window.lastSecond = NOW(); auto init = SDL_Init(SDL_INIT_VIDEO); assert(init == 0); mainWindow = SDL_CreateWindow("Timestep", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, WINDOW_WIDTH, WINDOW_HEIGHT, SDL_WINDOW_OPENGL); assert(mainWindow); renderer = SDL_CreateRenderer(mainWindow, -1, SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC); assert(renderer); SDL_version version; SDL_GetVersion(&version); printf("SDL Version: %d.%d.%d\n", version.major, version.patch, version.minor); while (true) { int thisFrameFixedUpdates = 0; window.now = NOW(); window.frameTime = window.now - window.lastFrameTime; if (window.frameTime > 25 * NS_PER_MS) { window.frameTime = 25 * NS_PER_MS; } window.lastFrameTime = window.now; constexpr unsigned long long dt = (NS_PER_SECOND / TARGET_FPS); window.accumulator += window.frameTime; while (window.accumulator >= dt) { fixedUpdate(); window.accumulator -= dt; ++thisFrameFixedUpdates; } float alpha = window.accumulator / static_cast<float>(dt); assert(alpha >= 0.0f && alpha <= 1.0f); rx = cx + ((cx - px) * alpha); ry = cy + ((cy - py) * alpha); if (thisFrameFixedUpdates > 0) { printf("--- (rx,ry) (%.2f,%.2f)\n",rx, ry); } else { printf("*** (rx,ry) (%.2f,%.2f)\n",rx, ry); } update(); render(); } return 0; } Help much appreciated Thanks

Aressera

3,171

August 14, 2023 11:28 PM

I think its a problem with the timer or time values that are used for the alpha calculation.

Here is a graph I made in Excel showing the rx values as they change over time. You can see its not a straight line like it should be, there is a wiggle to it.

To see the wiggle better, we can look at the derivative:

So, for some reason the rate of change of the time values is not consistent, which I assume is what is producing the jitter. Maybe the timer is not as high resolution as it claims, perhaps you only get 1ms resolution and therefore the alpha values are not consistently increasing modulo 1.

Gnollrunner

474

August 15, 2023 03:40 AM

Crowbone said:
I think the values look correct; here's a sample of requested points/values during a run where it was jittering:

I would not necessarily say that looks correct. Sometimes you move a position. Sometimes you don't. Sometimes you move two. If those are pixels you might need anti aliasing to make it look smooth.

Juliean

7,374

August 15, 2023 09:45 AM

Gnollrunner said:
I would not necessarily say that looks correct. Sometimes you move a position. Sometimes you don't. Sometimes you move two. If those are pixels you might need anti aliasing to make it look smooth.

Again, moving irregular pixel-intervals per frame doesn't produce visible jittering. A lot of pixel-perfect games have irregular move-intervals. The game I'm making, whose movement is equivalent to that of an old SNES-title, has lots of irregular movement. The player moves 1-2-1-2 px/frame when walking, and 2-3-3-2-3-3 when running. NPCs will often move 0.5px/frame (meaning visually one move every other frame). None of which is noticable as jitter, neigther in the original nor in my reimplementation. Render-interpolation in my case also makes the result even more smooth, especially on high framerate monitors, instead of worse. I'm just typing it again because I do firmly believe that unevenly moving in whole-pixel intervals and antialiasing is not something that OP should need to look into.

Besides, I'm not 100% sure how SDL handles the rectangle-drawning internally - the documentation for SDL_RenderFillRectF mentions it uses sub-pixel precision, so maybe it's exactly that what is causing visual jitter for you. You can try to round the values before passing them into the function, my own implementation (and it's SNES-reference) use round-down for rendering.

If that doesn't help, can you try to make a video showcasing the exact thing you see? It might be hard, but maybe with VSync and 60 FPS recording, it could come through. Because jitter can be highly subjective and/or mean different things. So seeing what is actually going on, might help a lot to pinpoint the issue further.

EDIT:

DUDE THIS GARBAGE PIECE OF SHIT FORUM SOFTWARE KEEPS DELETING THE REST OF MY POST; I SWEAR (with a bit less rage - if I type beyond the link that I posted below, it messes up the editor and when I post everythings gone -.-)

Besides, I'm not 100% sure how SDL handles the rectangle-drawning internally - https://wiki.libsdl.org/SDL2/SDL_RenderFillRectF

Gnollrunner

474

August 15, 2023 05:17 PM

Juliean said:
Again, moving irregular pixel-intervals per frame doesn't produce visible jittering.

I wouldn't count it out so fast. It goes from 0 to 2 in places. Intuitively that seems wrong. Also if he's logging a constant time step there isn't much left assuming the logger is correct.

Crowbone

Author

0

August 15, 2023 07:40 PM

Juliean said:
Gnollrunner said:
I would not necessarily say that looks correct. Sometimes you move a position. Sometimes you don't. Sometimes you move two. If those are pixels you might need anti aliasing to make it look smooth.
Again, moving irregular pixel-intervals per frame doesn't produce visible jittering. A lot of pixel-perfect games have irregular move-intervals. The game I'm making, whose movement is equivalent to that of an old SNES-title, has lots of irregular movement. The player moves 1-2-1-2 px/frame when walking, and 2-3-3-2-3-3 when running. NPCs will often move 0.5px/frame (meaning visually one move every other frame). None of which is noticable as jitter, neigther in the original nor in my reimplementation. Render-interpolation in my case also makes the result even more smooth, especially on high framerate monitors, instead of worse. I'm just typing it again because I do firmly believe that unevenly moving in whole-pixel intervals and antialiasing is not something that OP should need to look into.

Besides, I'm not 100% sure how SDL handles the rectangle-drawning internally - the documentation for SDL_RenderFillRectF mentions it uses sub-pixel precision, so maybe it's exactly that what is causing visual jitter for you. You can try to round the values before passing them into the function, my own implementation (and it's SNES-reference) use round-down for rendering.
If that doesn't help, can you try to make a video showcasing the exact thing you see? It might be hard, but maybe with VSync and 60 FPS recording, it could come through. Because jitter can be highly subjective and/or mean different things. So seeing what is actually going on, might help a lot to pinpoint the issue further.
EDIT:
DUDE THIS GARBAGE PIECE OF SHIT FORUM SOFTWARE KEEPS DELETING THE REST OF MY POST; I SWEAR (with a bit less rage - if I type beyond the link that I posted below, it messes up the editor and when I post everythings gone -.-)

Besides, I'm not 100% sure how SDL handles the rectangle-drawning internally - https://wiki.libsdl.org/SDL2/SDL_RenderFillRectF

I've uploaded a youtube video which shows clearly the jittering:

Out of interest, for your game which rendering library do you use? I'm going to test out the same code with other libraries just to rule that out.

Crowbone

Author

0

August 15, 2023 07:45 PM

Aressera said:
I think its a problem with the timer or time values that are used for the alpha calculation.
Here is a graph I made in Excel showing the rx values as they change over time. You can see its not a straight line like it should be, there is a wiggle to it.
To see the wiggle better, we can look at the derivative:
So, for some reason the rate of change of the time values is not consistent, which I assume is what is producing the jitter. Maybe the timer is not as high resolution as it claims, perhaps you only get 1ms resolution and therefore the alpha values are not consistently increasing modulo 1.

It would be pretty strange if the timer wasn't high resolution (I think for Windows, the standard library implementation of std::chrono calls QueryPerformanceCounter()). I didn't think about plotting it out on a line like that! I will experiment with different functions and see if the result is any different.

I read an article before that stated that the reading of the current time should be as close to the exact time the frame is rendered but I'm unsure if this could be an issue also?

Aressera

3,171

August 15, 2023 07:49 PM

Crowbone said:
I've uploaded a youtube video which shows clearly the jittering

It looks pretty smooth to me aside from what looks like an inconsistent frame rate at times. Out of curiosity, does it get better if you remove all logging? Logging to console on windows is much slower than you would think because it is synchronous. It may take a significant (and variable) amount of time.

Crowbone

Author

0

August 15, 2023 07:57 PM

Aressera said:
Crowbone said:
I've uploaded a youtube video which shows clearly the jittering
It looks pretty smooth to me aside from what looks like an inconsistent frame rate at times. Out of curiosity, does it get better if you remove all logging? Logging to console on windows is much slower than you would think because it is synchronous. It may take a significant (and variable) amount of time.

I've checked/logged the frame-rate before; when the program starts up, it's around 39fps then it maintains at 60-61 fps (VSync on) (jittering is still present).

I don't think it makes a difference i.e it doesn't get any better when logging is removed (jittering is still there time to time)

Gnollrunner

474

August 16, 2023 08:23 AM

Crowbone said:
I've checked/logged the frame-rate before; when the program starts up, it's around 39fps then it maintains at 60-61 fps (VSync on) (jittering is still present).
I don't think it makes a difference i.e it doesn't get any better when logging is removed (jittering is still there time to time)

Are you sure it's really maintaining 60-61 the whole time? It seems like it only jitters two or three times. Try to isolate those spots. I had a similar problem. In my case it turned out to be deleting meshes in the render thread due to LOD. Could it be some sort of collection that periodically kicks in? Does it happen in the same spot on every run?

kwikc

1

August 17, 2023 05:28 AM

I think that the red block moving in the youtube video can be considered as smooth. I have a test unit written in DirectX 9 having the similar lag when running under windowed mode, but basically perfectly smooth when running in exclusive full screen mode.

I also experienced such lag when playing AAA titles in full screen. They may be caused by different reasons according to the techniques used anyway.

None