The pixel data and game logic is both refreshed and handled respectively at 60Hz , and the sprite is moved by using arrow keys:

if I move the sprite 1 pixel a tick (60 ticks in 1 second, 1 tick = 0.016~ s, so 1 tick = 16 ms), it is smooth, however the sprite only moves 60 p/s, which is slow for the gameplay. If I move it, say 4 pixels per tick (4 pixels every 16 ms), it is certainly fast for gameplay, as it moves 240 p/s, however the animation is not smooth, and looks like the sprite is teleporting small distances (basically, the animation is choppy).

I feel like I cannot achieve a smooth and fast animation and have to make a trade off. Is there a solution to this problem? I've heard about frame independent sprite movement but I don't understand it fully.

I tried logging the time (before regulating the FPS) in milliseconds for each frame, and it gives a steady range of 0 to 1 ms.

After regulating FPS, the time is ~16 ms , which gives about 60 FPS. As far as I've observed there are no frames being skipped.

The motion blurred texture idea sounds cool, but I'm sure there is a more straightforward solution to the problem.

Are you using ints or floats for the sprite position? If using ints you will see some skipping because you actually need to move 3.84 pixels per 16 ms. 240 pixels/sec = 0.24 pixels/ms. 0.24 pixels/ms * 16ms = 3.84 pixels. But, you still might see skipping with floats if it's moving too fast.

Are you using ints or floats for the sprite position? If using ints you will see some skipping because you actually need to move 3.84 pixels per 16 ms. 240 pixels/sec = 0.24 pixels/ms. 0.24 pixels/ms * 16ms = 3.84 pixels. But, you still might see skipping with floats if it's moving too fast.

I'm using ints for everything (using SDL so I cannot use floats no matter what).

Also, the changing factor is frames per second (sometimes framerate drops by 1 so it oscillates between 59-60) and not the amount of pixels moved every second. 240 p/s is an approximation too, I would say 220 - 250 would be a decent range for the pixels moved every second by the sprite to be a good gameplay.

You can still use floats for your internal representation of the sprite position, and then cast to int when passing to SDL for rendering. Otherwise you are losing precision in movement which can make the animation less smooth.

You can still use floats for your internal representation of the sprite position, and then cast to int when passing to SDL for rendering. Otherwise you are losing precision in movement which can make the animation less smooth.

Why should I use floats for internal representation then? say instead of increasing 4 per tick, I increased 4.5, it would be truncated to 4 always, and if rounded, to 5 always, so I can't really see why would you want use floating point values.

Why should I use floats for internal representation then? say instead of increasing 4 per tick, I increased 4.5, it would be truncated to 4 always, and if rounded, to 5 always, so I can't really see why would you want use floating point values.

Because if you use floats internally then you will get 4.5 + 4.5 = 9 instead of 4.5 + 4.5 = 8. You are accumulating error.

Think of it as what distance do you want the sprite move every second. If you want it to move 240 units per second (in this case units are pixels) and your time step is 0.016 seconds, then every time step, it must move 3.84 units for a constant velocity. After 4 time steps, you will move 15.36 units (in pixels you will have moved 15 pixels). If you ignore the fraction part and round to 4 units, then after 4 time steps you will have moved 16 units (or 16 pixels). Now your sprite is 1 pixel off from where it should be. These errors will then get worse the farther you move.