I would start by separating animation logic from the draw method into an update method. Secondly I would the make the animation logic framerate independant. As it is now it's written in a frame dependant way which causes the animation to look different depending on the speed of the machine.

I'll try to do some pseudo-code below to show how I do animation logic myself below.

// Animation frames ( can be used for longer intervalls of certain frames as shown using the frame 4 more than the others ).
private int[] animationSequence = { 1, 1, 2, 2, 3, 3, 4, 4, 4, 5, 5, 4, 4, 4, 3, 3, 2, 2 };

// Animation framerate.
private float animationFramerate = animationSequence.length / 1000F;
private int currentFrame = 0;
 
 
public void update( long ms ) {
 
    currentFrame += ms * animationFramerate; 
    if( currentFrame > animationSequence.length ) 
    {
        currentFrame %= animationSequence.length;
    }
}
 

Thats pretty much it for the lazy-mans version. There are some fixes which could be made for even better synchronization. Thats by adding logic which can handle "half" frames. You can then use a variable for time spillover, i.e. when you show frame N and you still have som time left on that frame before moving into the next one.

In the above code, there are two ways to tweek your animation speed. One is to change the value of 1000F to either a higher value (slows down the animation) or vice versa for a faster one OR you can alter the animation sequence to have more frames of the same index in a row. When it comes to the rendering part you have two options as well. Either treat the index value in the sequence as an Image in your array or my preferred choice an offset in a sprite-sheet.

I would start by separating animation logic from the draw method into an update method. Secondly I would the make the animation logic framerate independant. As it is now it's written in a frame dependant way which causes the animation to look different depending on the speed of the machine.

I'll try to do some pseudo-code below to show how I do animation logic myself below.

// Animation frames ( can be used for longer intervalls of certain frames as shown using the frame 4 more than the others ).
private int[] animationSequence = { 1, 1, 2, 2, 3, 3, 4, 4, 4, 5, 5, 4, 4, 4, 3, 3, 2, 2 };

// Animation framerate.
private float animationFramerate = animationSequence.length / 1000F;
private int currentFrame = 0;
 
 
public void update( long ms ) {
 
    currentFrame += ms * animationFramerate; 
    if( currentFrame > animationSequence.length ) 
    {
        currentFrame %= animationSequence.length;
    }
}
 

Thats pretty much it for the lazy-mans version. There are some fixes which could be made for even better synchronization. Thats by adding logic which can handle "half" frames. You can then use a variable for time spillover, i.e. when you show frame N and you still have som time left on that frame before moving into the next one.

In the above code, there are two ways to tweek your animation speed. One is to change the value of 1000F to either a higher value (slows down the animation) or vice versa for a faster one OR you can alter the animation sequence to have more frames of the same index in a row. When it comes to the rendering part you have two options as well. Either treat the index value in the sequence as an Image in your array or my preferred choice an offset in a sprite-sheet.

So you are saying I need to use the long millisecond to make it frame rate independent?

So you are saying I need to use the long millisecond to make it frame rate independent?

He's saying that regardless of your timing method you should get some kind of delta time between updates called on your object and use that alongside the concept of say, a second, to time how often the animation frame changes. The code above is just an example of one way to do it.

The goal is that even if the update only runs 10 times a second it will change to the proper frame of the animation(even skipping frames if need be) and that framerate won't make it run at a different timing.

So you are saying I need to use the long millisecond to make it frame rate independent?

He's saying that regardless of your timing method you should get some kind of delta time between updates called on your object and use that alongside the concept of say, a second, to time how often the animation frame changes. The code above is just an example of one way to do it.

The goal is that even if the update only runs 10 times a second it will change to the proper frame of the animation(even skipping frames if need be) and that framerate won't make it run at a different timing.

Interesting. Thanks I will use this idea as a leverage.