Smooth out gliding so movement isn't (as) jerky #11159
Conversation
Only applies to non-ghost, non-camera mob movement. Scales automatically to any fps and any move delay. Also took this oppurtunity to remove tickcomp because it was USELESS and shit. All the rounding is because of floating point imprecision. round(2.7, 0.9) != 2.7, for example. 2.7 + world.time would wind up being < than world.time 3 ticks later even though they should be equal.
|
Interesting 👍 |
|
Add a .gif, please? |
rofl. |
|
Ehh, that was a dumb statement. A video, then? |
|
github doesn't support webm Plus I'm awful at recording them. |
|
correct me if I'm wrong, but isn't havin wonky movements, in part, due to you guys manually setting the oudated glide_size var on all atoms? |
|
glide_size is only outdated if one doesn't use pixel movement, which we don't |
|
Some notes, I think the rounding out of the world.ticklag might be doing you more harm then good. Rounding out loses preciseness, called rounding errors as I'm sure you know. Doing multiplication or division with these rounded out numbers compounds the rounding error. I noticed some times with slower movements, it could be choppy, like the glide was too slow compared to the move speed, and I'm thinking these rounding errors might be to blame. at fpses of 24 or 60, you have world.ticklags of 0.4166666666 and 0.1666666666. in the case of 24, you round to 25, in the case of 60, you round to 50. This also leads to issues with running anything above 75fps as this will round out to 100fps, a rather big jump |
|
There may not be a perfect solution (for now) because byond enforces glide_sizes in whole numbers anyway, but yeah, I'll do something about the rounding. |
|
if you need a whole number, and thus NEED to round, then you should do it after all the calculations, so you're rounding the "final" number, this mitigates rounding errors in the rest of the calculations as much as possible. |
Rounding now happens after calculations instead of before. The delay is also unrounded.
|
Should be right now |
|
Something is messed up in the math, glidesize is much too high on higher move speeds, and too low in lower move speeds. Edit: figured it out, byond floor()s glide_size, so 0.9 == 0, 1.9 == 1, etc. (and 0 is the same as no glidesize) mixed with the ceiling() for ticks. MORE COMPOUNDING! =P You can fix that by just checking if mob.glide_size is glide_size, and rounding if it isn't. In fact, I'm testing that as a fix and gonna pr it to you if it works Edit2: Actually, you want it to ceiling() glide_size since it's better to get to the square before your next move, then to get to it late and 'jump' to it during the next move. |
|
I don't really want to have to redo this after http://www.byond.com/forum/?post=1882348#comment16384168 Nice 404 MSO |
|
There we go, exactly as requested. It does feel a bit better in testing with odd fps's and slower movement speeds. |
|
Continue to merge this now please. |
Smooth out gliding so movement isn't (as) jerky
|
There's some big visual problems when dragging or grab-dragging people or objects, mrperson. |
very good excellent |
|
As somebody actually playing on the server right now, the amount of lag is absolutely incredible, and judging by what I've heard from people, sourced to this here update. |
|
No it didn't. It sourced to MSO increasing the FPS massively, which means
|
Smooth out gliding so movement isn't (as) jerky
Only applies to non-ghost, non-camera mob movement. Scales automatically to any fps and any move delay.
Also took this oppurtunity to remove tickcomp because it was USELESS and shit.
All the rounding is because of floating point imprecision. round(2.7, 0.9) != 2.7, for example. 2.7 + world.time would wind up being < than world.time 3 ticks later even though they should be equal.