starstruck example - why are animations started/stopped the way they are ?

[valueerror]

how do i put this.. 

 

in my code i do this:

 

 if (cursors.left.isDown)    { player.animations.play('left');    } else if (cursors.right.isDown)    {  player.animations.play('right');    } else    {  player.animations.play('stand');    }

 

 

in the starstruck example it is done this way:

 if (cursors.left.isDown) {        if (facing != 'left')   {            player.animations.play('left');            facing = 'left';        }    }else if (cursors.right.isDown)   {        if (facing != 'right')   {            player.animations.play('right');            facing = 'right';        }}else  {        if (facing != 'idle')  {            player.animations.stop();            if (facing == 'left')   { player.frame = 0; }            else  { player.frame = 5;   }            facing = 'idle';        }    }

both way work  but in the starstruck example an animation that is already running in a loop (for example 'left')  is not started again on every step because it is already on a loop..  thats good..

 

in my case this animation is also running smoothly but it is invoked 60 times a second..  

and instead of stopping an animation i'm just calling the next animation (that is - again - invoked on every step 60 times a second)

 

 

because of the fact that my approach also works the following questions come to my mind..

 

i guess stopping the animations at some point makes sense.. why run animations when a still picture is enough...   is this maybe good for memory and cpu consumption ???

 

but ...  is it even necessary to manually catch if an animation should be already running and to not trigger it again and again or is the animation manager aware of the running animation and ignores all following calls to the animation anyways  ?

 

or am i producing a huge overhead by calling animations.play on every step ?

 

 

thx !

 

 

[wayfinder]

As far as I can tell, already running animations will continue at their current point if you trigger them again. At least, that's what it looks like in my game

 

I have separated the code for displaying player animations from the movement code and am quite happy with that decision. It lets me worry about the peculiarities of how the controls feel without having to additionally worry about the animation frames – I derive those entirely from the actual movement, not the input. I also set up 1-frame anims for my currently non-animated phases, in case I want to animate them at a later point. And finally, I decided to set a movement threshold for when the character is facing which way and scale the y to -1 for left-facing phases, which saves me time and bytes spent on assets.

[valueerror]

separating the code for animations from the movement is a good idea - i also do these 1-frame animations and handle everything with animations.play instead of player.frame   - i also have the same impression that the animation is not reset in any way when triggered again - it looks like the one that already started continues without any disruption..

 

but the question remains.. is this bad practice? should i rather try to stop animations wherever i can and only start an animation when a new one is needed?  i don't know if all those repeatedly triggert animations are maybe producing a lot of garbage, eat up cpu and memory or something?  

 

if i record the javascript cpu profile requestAnimationframe is the one thing that eats up most cpu time..  and it sounds like it has something to do with animations ^^

[wayfinder]

You could do your own check routinely, if it's not in the standard animations.play code already...

[valueerror]

i just found this in the docs.. 

 

animations.play()

"If the requested animation is already playing this request will be ignored."  

 

so it should be safe to call animations.play 60 times a second - it should be ignored 60 times a second  

 

i changed the whole animation setting of my game so animations are set separately from the movment and changed all 1 frame animations to a simple player.frame(#)  -- i guess this is a good way to go