Is animation done in time or realtime? in BYOND Discussion

ID:138320
 
Oct 31 2000, 9:35 am
I tried out using flick() for DragonSnot, in an attempt to move the animation to the client. However, I ran into some timing inconsistencies: three times in a row it would take the same number of ticks, then it might take one more or less.

This morning it occurred to me that I'm tracking this using world.time, but that the client is probably rendering it in realtime.

Is that correct?

If so, in games where the animations are coordinated down to the tick, what is probably needed to make flick() work is for the upcoming icon object to be able to report when the animation is actually completed. I was thinking through a callback...but it would actually work better in this case if in each game tick the icon could be checked to see if it had finished animating yet.

Although, in that case maybe I can still handle it manually by just using realtime for my timing calculations.

Darn, I won't be able to play with this until tomorrow!

#1 Nov 1 2000, 12:14 pm
On 10/31/00 9:35 am Deadron wrote:
I tried out using flick() for DragonSnot, in an attempt to move the animation to the client. However, I ran into some timing inconsistencies: three times in a row it would take the same number of ticks, then it might take one more or less.

This morning it occurred to me that I'm tracking this using world.time, but that the client is probably rendering it in realtime.

Is that correct?

If so, in games where the animations are coordinated down to the tick, what is probably needed to make flick() work is for the upcoming icon object to be able to report when the animation is actually completed. I was thinking through a callback...but it would actually work better in this case if in each game tick the icon could be checked to see if it had finished animating yet.

Although, in that case maybe I can still handle it manually by just using realtime for my timing calculations.

Darn, I won't be able to play with this until tomorrow!


I'm bumping this up 'cause even with realtime I am not having luck here...any ideas on how I can be sure of the tick when an animation completes?
#2 Nov 2 2000, 8:23 am
In response to Deadron (#1)

Depending on exactly when the client receives the flick() message, you can expect some discrepancy between the visual completion of the animation and the total amount of time it should have taken from the server's point of view.


If so, in games where the animations are coordinated down to the tick, what is probably needed to make flick() work is for the upcoming icon object to be able to report when the animation is actually completed.


Yes. This is a tricky business, because currently, due to slight differences in transfer times, it is possible for one client to finish the sequence slightly before another one. In other words, the question might depend on who you ask. I guess that is the argument in favor of server-controlled animation.

I should have warned you about this potential problem. I didn't realize a difference of one tick would be apparent to the user.

One simple solution would be to provide a parameter to flick() that specifies whether the animation should run strictly according to the server's clock. I would send a timestamp indicating when it started from the point of view of the server and the client would adjust the frame speed to catch up as necessary so that the final frame comes at the desired time. That would be the 'synchronized' animation mode.

--Dan
#3 Nov 2 2000, 8:43 am
In response to Dan (#2)
On 11/2/00 8:23 am Dan wrote:
I should have warned you about this potential problem. I didn't realize a difference of one tick would be apparent to the user.

The reason it becomes very apparent in this situation is that the next flow starts early, and for a tick or so there is a dark gap that stands out between these bright green areas. Minor fluctuations in how fast the flow progresses don't seem to be an issue in other situations (after all, how consistent can you expect snot to be?)


One simple solution would be to provide a parameter to flick() that specifies whether the animation should run strictly according to the server's clock.

That could be interesting. Would the time checks take significantly less bandwidth than the icon state updates?
#4 Nov 3 2000, 11:07 am
In response to Deadron (#3)

One simple solution would be to provide a parameter to flick() that specifies whether the animation should run strictly according to the server's clock.

That could be interesting. Would the time checks take significantly less bandwidth than the icon state updates?

The attractive thing about running a flick with a server-specified termination time is that it would still be an entirely client-driven effect. No callbacks from the client or rapid updates from the server would be necessary.

As a hack, it is probably currently possible to get around the brief snot gap by calling flick() again when you want to ensure completion of the previous animation. You would pass it the icon state of the full trench. Does that make sense?

--Dan
#5 Nov 3 2000, 11:11 am
In response to Dan (#4)
On 11/3/00 11:07 am Dan wrote:
As a hack, it is probably currently possible to get around the brief snot gap by calling flick() again when you want to ensure completion of the previous animation. You would pass it the icon state of the full trench. Does that make sense?


Possibly...I'll try playing with that next week.

Meanwhile, for the next GoB we have some exciting new trench shapes coming...