ID:814224
 
Resolved
Rounding errors in flick timing could cause animation frames to be skipped or prolonged inappropriately.
BYOND Version:494
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Firefox 13.0
Applies to:Dream Seeker
Status: Resolved (496)

This issue has been resolved.
Descriptive Problem Summary:
It seems flick() now causes some irregular frame delays. Some frames will be displayed longer than they need to while others will be dropped entirely.

Numbered Steps to Reproduce Problem:
I've built a test case you can download here.

In the demo you'll find several rows of blocks. Blocks with an "M" for an icon are animated manually, each tick their icon_state is changed to form an animation. The rows with an "F" animate using flick().

TestBug() will show how the timing is off on all of them in 494 and 495. Reverting to 493 will show them animate correctly.

FirstFrameFail() may be an unrelated bug or just my confusion, but in that command the first frame of animation for the manually animated blocks will fail to be displayed.

Expected Results:
Animations sould be perfectly in sync.

Actual Results:
Using flick() causes irregular delays.

Does the problem occur:
Every time? Yes.
On other computers? Yes.

Did the problem NOT occur in any earlier versions? This seems to be a bug introduced in 494.
I'm experiencing this as well, although it happened when I set icon_state to a frame with [Loop "X" times]. Also, it appeared in 495, in 494 it was fine (at least for me it was).

[Edit]:
As a side note, 494 doesn't seem to be archived as a downloadable.
Under testing this as well, under 493 the animations are as they should be. Under 495 the animation timing is off.
More testing results:

493:
- FirstFrameFail verb Fail
- TestBug verb Success

494 & 495:
- FirstFrameFail verb Fail
- TestBug verb Fail

Maybe my issue is something else then, because it was working in 494, maybe I should report it as a different bug?
In response to Megablaze (#1)
Megablaze wrote:
[Edit]:
As a side note, 494 doesn't seem to be archived as a downloadable.

http://www.byond.com/download/build/

I suggest downloading 354 to see how far BYOND has come ;)
I've tested this with other games compiled in 494 and later, it's definitely widespread. I'm guessing it has to do with the "Flicks were still largely tied to client ticks instead of actual time elapsed." update.

The bug seems pretty major to me as it really screws up a lot of animations, especially so for things like spell effects.
Lummox JR resolved issue with message:
Rounding errors in flick timing could cause animation frames to be skipped or prolonged inappropriately.
I think a similar issue may have resurfaced. When I alter pixel_x and pixel_y, and proceed to flick(), it displays the previous icon for a world tick. It's like it hangs and displays an animation icon_state it isn't supposed to. When I switch this around and flick afterwards, I do not get the altered pixel_x and pixel_y