I just wanna be straighforward. I read a dozen of articles talking about game loop, components, modules, structures, time control, etc...

But, in the end I'm still somewhat confused of how animation actually takes place in the game flow...

Explicitly: Each time the render() assumes command It may render (say) a player sprite (in 2D game). The player "animations" would be expanded in a spritesheet (?) and player object may hold it's state and frame. Say "running" frame 'n'. So the render will render that sprite.

Is that it?

If so, how should I control the actual frame when using a time based game loop (for fps control)?

How do I sinc that with the update variables (x and y position) of the player itself. That will mean that the character will "slide" until next frame (in a walking sequence)...?

Comments, pseudo-codes and maybe a link to a more deep-in article concerning these issue is appreciated... ;)


  • \$\begingroup\$ This is a possible duplicate. See here: gamedev.stackexchange.com/questions/100405/… and here: gamedev.stackexchange.com/questions/38535/…. Also the best intro imho for gameloops and constant frame rates is DeWitters seminal blog: koonsolo.com/news/dewitters-gameloop \$\endgroup\$
    – Majte
    Commented Oct 26, 2015 at 22:39
  • \$\begingroup\$ hmmm.. the first two explains only part of these question (the time issue against the frame state). Also koonsolo focus on time sequence, fps, and interpolation... nice material tho. \$\endgroup\$ Commented Oct 26, 2015 at 22:50
  • \$\begingroup\$ That's why I said possible duplicate and didn't vote to close it down :) It's a mesh of duplicates and having just put in any of these keywords into the search field would have given you, the OP, already excellent and well thought out answers. \$\endgroup\$
    – Majte
    Commented Oct 26, 2015 at 22:53

1 Answer 1


Both approaches are viable:

You can make the animation state part of the game state and control it such that it updates in the defined manner. It then can influence also what can happen. In that case the render has to check the animation state and select a different sprite based on the outcome. How you sync that with any movement depends on how you want it synced. For instance OpenTTD has such animation states for several of its base graphics - the relative positions of the sprites towards their 'parents' are in those cases also part of the animation sequence, as such it's synced to lateral movements.

Alternatively you can decouple an animation from the game state and simply pick a new sprite and draw the next state ever draw call or every other (whatever you want). That makes sense for animations where exact control is not important (for instance smoke or water waves maybe). It frees you of some complexity in the game state and allows for easier implementation of parallel threading in a way that you can de-couple processing the game state and drawing the game.

  • \$\begingroup\$ Hmmm.. So it seems I'm not too far from what I guess a "hard-coded" animation would be... Anyway I found that question wich have a good point also... \$\endgroup\$ Commented Oct 26, 2015 at 22:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .