Better way to use AnimatedSprite with hundreds of frames (for an eye blink!)?

BingBong

I have a very simple eye blink animation for my player character, its only 3 frames, for when its idle (not moving), putting the frames into AnimatedSprite node, I need to put the eyes open frame, in and copy it 30 - 40 times before inserting the actual blink frames. To keep it not looking regular, Id then need to copy that eye open frame another 20, 50, 30, or so times etc, so the animation cycle is ending up with potentially hundreds of frames, for the most simple of things. Seems hopelessly inefficient, is there a better way to do this, or would it make no real difference to do it this way in terms of processing power?

Id like the blink to at least look random!

Any ideas?

TwistedTwigleg

I might recommend using an AnimationPlayer node (and a Sprite?) instead of a AnimatedSprite. That way, you can have better control over when the texture/frame changes, meaning you do not need to have duplicate textures or have to manually copy multiple frames. Instead, you could just plot the sprite change in the Animation editor at the times you want. I think it would also be a tad more performant as well, since it wouldn't need to keep telling the AnimatedSprite to change frames to the frame it already is (which probably has a very minimal performance cost)

BingBong

Sorry for late response! ooOOOo! Didnt realise you could do that, thought the animated sprite node was its own separate thing for handling sprites.

My first thought was to gdscript it, but as it would still be iterating through the frames there would be zero performance saving, the other thought I had was to use a state machine, with the blink state happening at random intervals, but thats a bit of a sledgehammer to crack a peanut approach!

Its the merest of details to get this going, but the details make the whole! I'll look into the AnimationPlayer a bit further. Ta!