Pixel gliding isn't perfect

ID:2117750
 
Jul 17 2016, 7:07 pm
BYOND Version:511.1349
Operating System:Windows 10 Home 64-bit
Web Browser:Chrome 51.0.2704.103
Applies to:Dream Seeker
Status: Open
Issue hasn't been assigned a status value.
My current setup is somewhat predictable:
world/fps = 10
client/fps = 60

What I'm expecting is that a pixel slide from one point to the next should take at least 0.1s because the next slide can't happen until then.

What I'm currently experiencing is, the slide is actually happening almost instantaneously when moving at low speeds (pixels per world-tick). As speed increases, movement appears to become smoother, but at low speeds, it's as if there's no interpolation at all.

GIF
(I'm only recording at 30 FPS though)
I start off taking small, short steps, then start moving continuously.
As far as I can tell, there's maybe one or two frames of interpolation, instead of an expected ~6 frames.

Next, I start taking bigger steps, and then move continuously that larger step size.
The interpolation is very apparent and it actually looks like 60 FPS (although noticeably choppy still).

Are clients not informed of world.fps for calculating pixel glides?

Also, setting animate_movement to FALSE causes weird jumpiness to occur when crossing tiles.
GIF
It would be nice if that would disable client interpolation on a per-object basis.
Jul 17 2016, 7:29 pm
Any demo projects on pixel glide issues are very welcome. They'll be an enormous help toward sorting all of this out.
Jul 17 2016, 7:35 pm
In response to Lummox JR
Actually, I just found out the cause. It's this part of my custom Translate() proc that forces a slide no matter the offset:
var last_step_size = step_size
step_size = 1#INF // or ~0 or 65535
. = Move(...)
step_size = last_step_size

It looks like the gliding occurs based on the step_size of the object, rather than the actual distance to be covered.

If I instead do this:
step_size = max(abs(translate_x), abs(translate_y))
. = Move(...)
// and not reset step_size

It's drastically improved.
Jul 17 2016, 7:40 pm
It's hard to believe it's not 60! (gif)

There's a bit of a disconnect between the eye and the camera, but it's still pretty good.
Jul 17 2016, 7:43 pm
Pixel gliding does in fact operate on step_size, so that it knows the difference between a glide and a jump.
Aug 16 2016, 11:56 am
How is this looking in 511.1352?
Aug 16 2016, 12:32 pm
In response to Lummox JR
Seems pretty smooth. At low world.fps, it's noticeable that pixel gliding uses non-linear easing compared to the previous versions, which might have helped with stutter between steps?

For bullets that get deleted as soon as they hit something, since pixel gliding is purely interpolation, where the bullet appears is always behind where it actually is, so the bullet disappears a noticeable distance away from the point of contact. To fix this, the first thing I tried was to delay destruction by a world tick, which actually didn't seem to have any effect. Eventually, I tried that same thing, but I also changed the step_size of the bullet to the actual distance traveled (after Move() is called), and it's much improved; it usually doesn't disappear until it's much closer to the point of contact. This makes it clear that pixel gliding still uses step_size and not actual distance traveled, so games with projectiles may have to always take that into consideration when wanting to use a lower world.fps than client.fps.
Aug 16 2016, 9:37 pm
In response to Kaiochao
Kaiochao wrote:
Seems pretty smooth. At low world.fps, it's noticeable that pixel gliding uses non-linear easing compared to the previous versions, which might have helped with stutter between steps?

It does not. It will accelerate the glide speed if an object falls behind, but it does not use any kind of easing. That would actually be rather impossible in the current system.

For bullets that get deleted as soon as they hit something, since pixel gliding is purely interpolation, where the bullet appears is always behind where it actually is, so the bullet disappears a noticeable distance away from the point of contact. To fix this, the first thing I tried was to delay destruction by a world tick, which actually didn't seem to have any effect. Eventually, I tried that same thing, but I also changed the step_size of the bullet to the actual distance traveled (after Move() is called), and it's much improved; it usually doesn't disappear until it's much closer to the point of contact. This makes it clear that pixel gliding still uses step_size and not actual distance traveled, so games with projectiles may have to always take that into consideration when wanting to use a lower world.fps than client.fps.

Pixel gliding is indeed based on step_size. You don't really want to adjust step_size, though, because if a bullet for instance travels 100px per server tick, and the client ticks four times faster, you always want it to appear to be traveling 25px per client tick. If you adjust step_size then the bullet will appear to go faster or slower depending on how far it's going, which isn't right.