I personally think this feature could propel DM forward quite a bit: The ability to change animation speeds at runtime.
A perfect example of how this could be used:
I want a cleaner combat system in a fighting game. To do this, rather than defining "attack speed" as "the delay between your attacks", I want to be able to define it as "how fast you attack". If I can speed up the attack animation, combat would be cleaner and have more capabilities, rather than having your attack speed cap out once you get to like 0.5 ticks between attacks.
I do not know right now if you can have values less than 1 in animation frames, but this would be very helpful in this feature. Another possibility would be to be able to increase the speed of overall animations (by multiples, perhaps?), meaning that you can take one animation and tell it to go 1.5 or 2x faster.
How feasible is this?
ID:1447203
 Dec 17 2013, 4:25 pm
|
|||||||
| |||||||
|
Dec 17 2013, 4:31 pm
|
|
Makeii
 |
You can use delays less than 1 per frame in animations. When world.fps came out, it used to be that delays were proportional to tick_lag (1 would be one tick). Now, delays are strictly in 0.1s intervals. You can have a delay at any speed below 1 if you would like. However iirc, delays can only be as low as world.tick_lag. Not sure if this has changed or if I am mistaken.
|
That's great, but being able to change it at runtime is the real issue that I'm addressing here. I'd be perfectly content if there was a function (or add-on to a function like flick()) that allowed me to give a multiple to speed the animation up by. I could have an animation at a default 1 (I could increase the delay between attacks if the attack speed goes below 1 attack per second), and I could speed it up by, for example, 1.08x. I hope I'm making sense here. lol
| |
The frame delays are specified in deciseconds (1/10 seconds).
I'm not sure how it relates to the framerate. Rounded, probably. Of course they can be reliably as low as the tick_lag, so at 30 FPS, one animation frame per rendering frame would be 0.33 repeating. I think the simplest option would be to add an animation speed scalar to flick(). This should obviously take any float value. Another would be an atom variable that would apply to all its animations, but with a better name than animation_speed_scale. | |
I like the flick() idea better, simply because there may be certain animations you want sped up and certain ones you don't, and you may be changing between the two often enough to make it a hassle to constantly be changing the variable.
| |
They're not really different features, I meant it more like they should both be added, because they serve different purposes. If you want a continuous, repeating animation going on, you might want to set the speed according to some variable. The flick() version won't repeat.
| |
Ah, gotcha.
| |
You can do this by cycling different icon_states with animate().
| |
I support this, would be very helpful. +100
| |
Bump.
| |
To be honest I think this would be great, I also think we should get procs to obtain the icon_states duration, so we don't need to manually check an icon's frames to set that time on spawn() when we try to make something look smooth. Some guys suggested it on Lummox's thread, but it got rejected.
| |
Bump again.
| |
bump
| |
I would support this, the project I'm working on currently actually needs it. With attack speed having such a big range, we can have more accurate animations if this was implemented. At the moment, I got a sloppy 3 state replica that all have different delays.
Also, the base itself has a ton of states as is, let alone making a state for each state in the attack animation. 110% support. I'd be a very happy man to see this added. | |
Bump
I really hope more people check this thread, it'd be very useful and cool. | |
Eternal_Memories wrote:
Bump +1 Good luck, I hope it gets noticed.. and implemented.. | |
I'll bump again just to make sure it stays noticed.
| |
Supported.
| |
I don't know about just adding a flick() scalar, because that would only work for once-through animations.
In the case of idle and movement animations, it might be good to have a scalar factor for animation speed for the atom itself, allowing you to effectively increase/decrease the rate at which all animations on that mob play, including repeating animations. Might also be good to make it one of the animate() compatable variables as well. Of course, both are probably going to require a major version bump due to needing new messages to account for the new appearance-related property. | |
