I've noticed that one of the things that keeps people form using pixel_movement or anything else that manipulates world.tick_lag is due to the animations playing faster or slower, depending on the tick_lag.
I propose a variable expansion to flick.
flick(icon, object, factor=1)
When flicking an object, the delays will be multiplied by the factor.
By default, the factor will be set to world.tick_lag.
With the current flick, if I change world.tick_lag to 0.25 an I have an animation with 10 frames, instead of playing in 1 second, the animation will play in 1/4 of a second.
With the flick expansion, this will also happen, however if flick(icon, object, 4) is used, then the animation will play at the speed of 10fps. (this assumes that the tick lag is still set to 0.25)
This can be used to easily slow down animations for icons. It will have to go through a variable though.
Although the animation will play at normal speed with flick() there is also the issue of "movie" icon states. If you wanted to just set an icon state normally the animation would play based on the world.tick_lag.
using a variable the icon itself can, at runtime, change its delays to match what the developer needs. icon.factor will work the same as tick but it will be applied to all animations within the icons. While flick(a,b,factor) will change the speed just for the animation and only for the duration of the animation, icon.factor will change the delay of each frame within the icon,based on the factor.
Of course, it's still based on system time, so using 0.25 with a tick_lag of 1 will still result in a delay of 1 tick per frame. This is only meant to allow people to slow down animations to designated speeds.
If you need me to, I can go into more details on how it would work, but I'm sure it seems fairly straightforward and I don't think it would be difficult to implement, but it would result in much higher use of projects that manipulate world.tick_lag.
ID:116730
 Aug 3 2011, 10:48 am
|
|||||||
| |||||||
Pretty much what I was getting at, yes, though I figured that having it applied to the icon would allow people to manipulate it for each icon, and then allowing you to enter a separate value in flick() would allow you to manipulate the timing even further.
A world variable to predefine them all ahead of time is a fantastic idea though. For example, if you want most icons to play at 10fps in a world with tick lag of 0.25 you can set world.icon_delay to 4, then for the few icons that you want to play at 40fps you can adjust their icon.delay (or factor, or speed whatever variable you decide to use) to 0.25. icon.delay will use world.icon_delay as it's relational value and will play based on that. So if you had: tick_lag=0.25 icon_delay=4 icon.delay=0.25 The icon in question would play at 40fps. because it's 0.25*4*0.25. While having one world variable makes it much easier to modify all icons at once, if you wanted to modify only a few icons, they would each need their own speed/delay variable. Then, flick() would modify .delay, temporarily for that icon, in the case that you want certain animations within each icon to play faster/slower than others. | |
I'd expand upon this further. I immediately thought the same thing as Forum_account, but I think it would be better to be able to set the animation delay independent from the tick_lag.
So, the default for the icon_lag/icon_delay var would always be equal to tick_lag if left undefined, but if you define it, it sets the delay around the base of 10 FPS. (Similar to how sleep still runs on 1/10ths of a second regardless of tick_lag.) That way, existing games are unaffected, and you can choose a FPS designed for your animation. (Which, in my opinion, makes a lot more sense than being based around tick_lag.) And it could be expanded further, so that the icon editor could display at other FPS as well. (Could just be based off the icon_lag value from the last game compile by default.) This isn't necessary, though. Also, I kind of feel the reason the animation speed matches the game FPS may be because of a built-in internal limitation. (Though, I have noticed that even when games experience lag and freeze, the animations keep going the same speed, which suggests that animated icons are handled client-side, and always have been. That suggests also that this should be a client var, which opens the possibility for players seeing the animations at different speeds, which could be a cool effect. Similar to how world.view and client.view function together.) EDIT: This may be bordering on a completely different suggestion altogether. | |
That would be cool. If you "slow" a player with a spell, not only does their movement slow down but their icons animations slow down as well, without having to use a separate animation. Very intriguing.
| |
Yeah, I just feel a little off-topic, since that doesn't match your original feature request, which was to be able to change the animation speed of individual icons. (In my opinion, that's quite a bit more complicated than changing the overall speed of all icons on a player's screen. There might have to be a complete system change if it doesn't already support changing the animation speed of individual objects.)
| |
well, the way flick() works is basically a string of icon state changes separated by sleep(world.tick_lag). You can make your own custom flick() proc if you wanted but you'd have to make each frame an individual icon state, since we don't know what the specific way that flick() picks which state to display.
if you were able to modify the sleeps in between by entering a different value then you could control the playback speed of flick() so long as you don't go faster than the tick_lag. | |
Well, I suppose the special thing about flick() is that it always shows the animation for its exact number of frames. (The problem you mentioned with having to have every frame as a different state, which is simply not plausible for obvious reasons.)
I think you should just be able to query the amount of frames in a given icon_state, though. That's probably been suggested already, and it would obviously have many purposes. | |
So, the default for the icon_lag/icon_delay var would always be equal to tick_lag if left undefined, but if you define it, it sets the delay around the base of 10 FPS. (Similar to how sleep still runs on 1/10ths of a second regardless of tick_lag.) The problem is that sleep doesn't work that way. I'm pretty sure it rounds the delay to the nearest increment of world.tick_lag. This could be done with animations, but I expect it'd look strange. I suppose its necessary to support this (because hanging the client's refresh rate might be difficult), so if you sped up animations frames would be skipped instead of just being played faster. | |
To address the issue with world.tick_lag, I'd just add a global variable that effects delays for all icons whether the animation is caused by flick() or not. If you have world.tick_lag set to 0.25, you'd set world.icon_delay to 4.0 to cancel it out and have animations run at 10 fps. The screen would still be drawn 40 times per second (because this might be difficult to change), the icon frames would just be shown for 4 consecutive frames each.