ID:2392537
 
Resolved
Movement sometimes ended too early when moving by more than step_size and using non-integer steps.
BYOND Version:512.1446
Operating System:Windows 10 Home 64-bit
Web Browser:Chrome 68.0.3440.106
Applies to:Dream Daemon
Status: Resolved (512.1447)

This issue has been resolved.
Native sub-pixel movement doesn't happen at a consistent speed at certain angles when moving by a distance larger than the size of the mover's bounding box. If the size of the bounding box is increased, or if the movement speed is decreased, then the issue doesn't happen.
Move(loc, dir, step_x + move_x, step_y + move_y)

Here's a demo: http://files.byondhome.com/Kaiochao/bug/ NativeSubPixelMovementBug_src.zip

Here's a video of it in action: https://streamable.com/c9bux

There are two dots in this demo: red and blue. The demo compares native sub-pixel movement to custom sub-pixel movement.

Red dots use native sub-pixel movement. They sometimes fall behind, making them visible. This only happens to the faster ones, and more so to the fastest ones.

Blue dots use custom sub-pixel movement. They move as expected.

Purple dots are overlapped blue and red dots. They're when native matches custom. Most of these are the slowest-moving ones, which move at the same speed as the size of the bounding box of the dots.

They move at 3 different speeds: the slowest move at a speed equal to the size of the bounding box. The faster they go, the greater the error size.


Also, pixel gliding isn't perfect either. I have several different possible ways of calculating a step_size at least as big as the movements (to force a slide rather than a jump move), but none of them provide smooth pixel gliding at all angles.
Lummox JR resolved issue with message:
Movement sometimes ended too early when moving by more than step_size and using non-integer steps.