ID:137522
 Oct 22 2001, 7:34 am
|
|
Movement states in icons are played as normal animations, which means the frames do not start from the beginning of the animation sequence. In the next BYOND update, would it be posible to have them behave like flick()ed icon_states?
| |
I guess it's unimportant. I worked around it with flick(), since I don't expect Dantom to release a revision before Saturday just to suit my tastes for the Tanks special edition ;)
| |
Shadowdarke wrote:
I guess it's unimportant. I worked around it with flick(), since I don't expect Dantom to release a revision before Saturday just to suit my tastes for the Tanks special edition ;) Maybe they could have it so it uses something like flick for the animation but after the movable atom reaches it's destination, the animation terminates. | |
Ebonshadow wrote:
Shadowdarke wrote: Still wouldn't work in my case. If the animation starts after every move it would look like the person took two steps with their left. | |
Spuzzum wrote:
I dunno... my game usually only has time to play one-and-a-half frames. Thus, it looks something like this:... So, I would probably request some sort of toggle, since Dantom is supposed to be revising the smooth movement anyway. ;-) Right. Basically the movement works like it does to handle this situation. However, I am not happy with it; a while back someone said that the "smooth" movement sometimes tended to look like "disabled gerbils", as good of a description as any. I think that what we want to do is always play the exact number of frames in the movement animation whenever the object moves. So if the object is moving quickly, rather than skip frames we should simply increment the frame rate for the sequence. We may run into redraw limitations, but I think for the most part it will work well enough. It would also solve ShadowDarke's problem, since each movement animation would start at the initial frame. | |
Tom wrote:
I think that what we want to do is always play the exact number of frames in the movement animation whenever the object moves. So if the object is moving quickly, rather than skip frames we should simply increment the frame rate for the sequence. We may run into redraw limitations, but I think for the most part it will work well enough. It would also solve ShadowDarke's problem, since each movement animation would start at the initial frame. When I coded movement to flick() each time, I got the problem Spuzzum was talking about, each movement showed the first frame and then before the next frame showed, they were already into the next movement. I finally settled on something like you're talking about, only flicking the animation if it's been 4 ticks (for the 4 animation frames) since the last flick. I'm very pleased with the results. :) You can see the fruit of my efforts on green team movement in the Tanks Special Edition coming this Saturday :) | |
Move
[step left]
Move
[step right]
Move
[step left]
Move
[step right]
If that change were made and the steps originated from the time of movement, then it would appear as
Move
[step left]
Move
[step left]
Move
[step left]
Move
[step left]
Move
[step left]
So, I would probably request some sort of toggle, since Dantom is supposed to be revising the smooth movement anyway. ;-)