Tile movement smoothing just plain isn't possible except at certain very specific values.
Please change glide_size to a floating point value.
This will allow us to have better control over sliding in tile-based games at any fps. Currently, there is quite a bit of jarring jerkiness even when using perfectly calculated glide_size.
ID:1882348
 Jun 25 2015, 10:19 pm
|
|||||||
Resolved
| |||||||
Making glide-size a float will likely prove difficult because of the way appearances are handled. Not impossible, though. Making glides themselves track residual offsets in non-integer values would be helpful too.
One thing I've often wondered is if a flag of some kind would be warranted, to say that a movable uses a different form of gliding. Right now for instance it will try to move glide_size in exact distance toward the target, but what if it merely scaled the max x/y step to glide_size? Then a diagonal would take just as long as a sideways movement, which in some games would make good sense. | |
If you're up to adding a new variable to movables, you could add a step_time variable that determines how long a step should take to animate. I'd say that a lot of games have been using the "delay between steps" method:
client A built-in step_time variable would be a kind of inverse of glide_size, like world.fps is to world.tick_lag. Then you'd just have to change how glide_size works to accommodate this. Some games focus on glide_size and determine the step_time from it, making glide_size analogous to an actual movement speed. For example, glide_size=1 means you appear to move one pixel per frame, and you can only control your movement every, say, 32 frames. It's easy to use and pretty simple to set up. Either way, the issue is still that glide_size can't handle non-integer values, and both systems currently experience the same uneven steps issue. | |
^I strongly support this. Glide_size doesn't really make any kind of sense as a value to expose to the developer. What we as developers want is to lock gliding time to a specific movement delay.
Though, for consistency's sake, glide_time should be measured in 1/10th seconds, meaning at 40fps a single-frame movement would be 0.25, and at 30fps a 4-frame movement would be 1.33333. | |
Now, I know you can't move by a partial pixel, but by rounding at the source, rather then per-move, you compound rounding errors.
If I set something's glide size to say 1.5, I know you can't move by 1.5 pixels, they don't work like that, but I do want the glide to finish in 23 ticks, not 16 or 32 ticks. So it should move by 1 pixel, then 2, then 1, etc. So its more about how long it takes to move to the next tile, overall, and less about the per-pixel movement, you can round the perpixel part (and track how many pixels you've actually moved to keep the rounding error from compunding.) | |
http://www.byond.com/forum/?post=1882348
Lummox said this was happening in 509. I can't find the thread where he said that was coming in 509. It might have been during a PM conversation that has since lapsed. | |
Yes, this is on my list for 509.
| |
Lummox JR resolved issue with message:
The value of glide_size now supports fractional numbers, not just integers. | |
O frabjous day! Callooh! Callay!
| |
Holy smokes, already?! Now I totally gotta get rid of the implementation I have. One of the few soft-coded things I was waiting to become hard-coded.
EDIT: Whoops! This was glide_size, not step_size. I was also waiting for this, but not for my current project that since I mainly use pixel movement! | |
So movable.glide_size as well as client.glide_size should support floats. It's easy enough to use animate() to cause the desired gliding effect, but of course you can't animate() the camera to follow along, so this would only be a good workaround for games where the camera isn't expected to be locked on the player.
It might also be worth addressinig the apparent speed of diagonal moves. Should it take the same amount of time to go from one tile to any adjacent tile? Or should it take longer by a factor of sqrt(2) to go diagonally?