Problem: When client.fps matches world.fps, it's possible to calculate mob.glide_size so that glides take a certain amount of time (and vice-versa). However, when client.fps doesn't match world.fps, the timing of the glides is no longer correct. Since mob.glide_size isn't something that can be changed per-client, this is definitely something that the clients is responsible for.
Demo: https://puu.sh/vygmH/284ff29c17.zip
Compare how uniform the gliding is between matching FPS and different FPS. To me, it's perfect when the FPS matches, and different FPS creates jumpy gliding.
edit: Some of this could be attributed to the way that repeating macros repeat. It's noticeably smoother with a loop that only checks key state, but still not perfect, getting worse the farther apart the FPS are.
ID:2241289
 Apr 27 2017, 3:22 pm (Edited on Apr 27 2017, 3:33 pm)
|
|||||||||||||
| |||||||||||||
That's what I assumed it should be doing, but it doesn't appear to be working correctly. Thanks for the confirmation.
| |
Right, meant to verify it was buggy from the documented behavior in there somewhere but got side-tracked and posted without it (lol).
| |
I was able to verify there's some jumping behavior. Oddly the only place it was really strong was when world.fps was 10 and client.fps was 60. At other combos it was pretty okay. I took care of some of the problem by changing the way "acceleration" is calculated. There's code that handles acceleration that also will reset x/y glide offsets, but acceleration shouldn't be in play at all when there's a firm glide size.
I believe most of the rest of the problem (there's a speedup/slowdown effect now in place of the jumping) has to do with timing where the original movement command is getting to the server late, but repeats fire earlier. So a background move loop as a replacement ought to help there, and now with this jumping fixed I think those two approaches will basically take care of it. For high-FPS code a move loop is probably the best idea anyway. | |
Lummox JR resolved issue with message:
With world.fps and client.fps disparities, sometimes repeated movements from holding down an arrow key could cause "jumping" to appear. This behavior has been improved, although for high-FPS projects it is also advisable to use a movement loop. | |
Lummox JR changed status to 'Open'
| |
I've had to completely revert this change. The fix that was put in place, and further corrected in id:2243924, simply doesn't work right at all. The old behavior was way better, and for the time being I'll have to stick with that till I can figure out a more in-depth solution.
Ultimately, what I'd like to do is not reset the glide if the remaining glide is below a certain fraction of the original, but I'm not going to play around with that in 511.1383. | |
Would be nice to have it scale properly before 512.
| |
Bump.
| |
Any plans to address this soon? Client FPS is probably the most useful/desired feature BYOND has had in a long while.
| |
I would like to revisit this, but it's a Pandora's box, so I haven't come back to it just yet.
The last time I thought I had this problem licked, my fix introduced a lot of horrible new problems. That's something I absolutely don't want to have happen again. | |
We've been experimenting with different movement systems to see if there are any workarounds, and in our latest approach the "jumping" is a lot less noticeable, and while it's still there, it's *very* slight. Will post more details later.
| |
It seems to me that this is a remnant of bad decisions from the early days of BYOND. The reason that this issue is rearing its ugly head, seems to be that developers want to think in terms of how long a glide will take, while the engine expects you to supply how many pixels an object will try to move per frame.
IMO the engine should be the one doing the math to figure out how many pixels should be moved per frame, while the developer should be the one specifying the duration of the glide. So glide_size has basically always been a bad feature. I think the ultimate solution to this problem is to just deprecate glide_size and instead favor a new variable: glide_time, which will basically allow the developers to offload the work that they are already doing to keep movements uniform straight to the client. The key problem with keeping the pixel size of the glide in terms of frames like it is now, is that it basically ensures that you can't have variable client FPS and have your movements interpolate properly for each client. This would not be the case if we were passing the total time that a glide should take to move over step_size. This would bring gliding behavior in line between both pixel and tile movement modes, and would eliminate a lot of visual jitter and kludge in the process. | |
Is there a plan to get this working in the near future? Because I think that the majority of developers would likely agree that client FPS was the best feature release BYOND has had in years. It would be a shame if this wasn't salvaged.
| |
bump
| |
Bump
| |
Bump
| |
Bump!
| |
Bump 2021..
| |
"The glide size is measured in server ticks. If you use a different client tick rate by altering client.fps or client.tick_lag, the actual glide used will be scaled appropriately. E.g., if your client.fps is 4 times greater than world.fps, the actual glide amount each client tick will be glide_size/4."