ID:622340
 
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
I've never found a case where it was convenient that icon delays are specified in tenths of a second. I'd rather be able to set the delay for a frame of animation to 2 and have that image be shown for two frames whether world.fps is 30 or 40. I'd rather base the game's delays around the framerate than deal with extra frames due to rounding errors or changed framerates.

This would be especially handy because BYOND doesn't seem to honor the specified framerate. world.tick_lag is stored to two decimal places, so setting world.fps to 59 or 60 has the same effect:

10 / 59 = 0.16949...
10 / 60 = 0.16666...

Both get truncated to 0.16, and 10 / 0.16 = 62.5, which gets rounded to 63. So if you do this:

world.fps = 59
world << world.fps
world.fps = 60
world << world.fps

That'll output 63 twice. This isn't a huge problem, but if you set icon delays to 0.16666 expecting a rate of 60 frames per second, it might not work out like you'd expect if the game is actually running at 63 fps (or 62.5 fps).
Semi-related, single frames need a speed setting. If I wanted to flick() a static frame I have to create a duplicate frame of animation then add the delay to that one.
Forum_account wrote:
I've never found a case where it was convenient that icon delays are specified in tenths of a second. I'd rather be able to set the delay for a frame of animation to 2 and have that image be shown for two frames whether world.fps is 30 or 40. I'd rather base the game's delays around the framerate than deal with extra frames due to rounding errors or changed framerates.
That sounds rather inconvenient, and a bit backwards. It would mean that every time you changed world.fps (which I have been doing a lot of lately), you would have to go into every icon_state of every icon and update their delays. It also means icons wouldn't animate consistently between projects, unless they were using the same world.fps.

Your complaint sounds like more of an issue with internal rounding, than with icons displaying inconsistently between frame rates. Perhaps they could work on the way they round things, there is also an issue with the rounding done in step() on pixel sizes.


SuperAntx wrote:
Semi-related, single frames need a speed setting.
I agree, that should probably be its own feature request.
Falacy wrote:
It would mean that every time you changed world.fps (which I have been doing a lot of lately), you would have to go into every icon_state of every icon and update their delays. It also means icons wouldn't animate consistently between projects, unless they were using the same world.fps.

It depends on what you want to be consistent. If you have an animation that's 10 frames at 40 fps and runs in 0.25 seconds, when you change world.fps to 35, do you:

1. Want the animation to still take 0.25 seconds.

2. Want the animation to still take 10 frames.

The current behavior is the first option, the animation will still play in 0.25 seconds (or as close as it can get). The duration is consistent across projects with different framerates but the quality of the animation isn't. Frames will be skipped or repeated based on how the framerate changed. With the second option the quality of the animation would be consistent but the duration isn't.
In response to Forum_account
Forum_account wrote:
1. Want the animation to still take X seconds.
Yes, that would be the preferred behavior.

Frames will be skipped or repeated based on how the framerate changed.
That sounds like a bug. I haven't noticed frames repeating or being skipped, unless you are referring to this?
If the client's refresh rate is tied to the server's framerate, it'd have to skip or repeat frames.
In response to Forum_account
Forum_account wrote:
If the client's refresh rate is tied to the server's framerate
Shouldn't be, and doesn't seem to be. Clients are not locked at the server's FPS, they don't follow any strict refresh rate. If you have an icon updating at 5 FPS, then the client will redraw at that rate, if you switch that icon_state to something at 10 FPS, then the client will redraw that fast instead. All the server should say is "play X-animation on Y", and the client should be able to handle everything from there.

it'd have to skip or repeat frames.
It should never have to repeat frames. If you are attempting to play some 100 FPS animation, and the game is only running at 50 FPS, then it makes sense that some frames may be missed. But this is a somewhat obvious design concept to work around.