How to handle animations properly

[fjanisze]

Hello folks,

Some time ago in order to learn how SFML works I wrote my personal version of the game 2048. Today i came back to my code with the idea of going some refactor.. Besides many issues, one the most problematic is how the animation are handled, i really think it may be a better way but i have no idea on how to proceed using SFML.

To animate a Sprite, my app every give time just change the position of the sprite object in order to emulate the motion, it happen in two different steps:

• A thread runs in background and update the sprite positions continuously, the frequency of the update depends on the sprite 'speed', if i want a quick moving object the position update will happen very frequently
• The main thread draws the sprite on the rendering window 60 times per seconds

The idea works, since the sprites are animated.. But the effect i think is very poor and my question to you is: How to animate efficiently sf::Sprite object in SFML? Is there any 'proper' way?

For reference:
A video of the game (if you dont want to build everything):
The quality of the video is pretty poor.
Repo for the game: https://github.com/fjanisze/2048.git
Repo for the animation engine only (with a banal demo to test the code): https://github.com/fjanisze/simple_animation_engine.git

Please do not comment the texture quality ecc, i know is everthing ugly

Thanks

[Nexus]

A thread runs in background and update the sprite positions continuously, the frequency of the update depends on the sprite 'speed', if i want a quick moving object the position update will happen very frequently

Multithreading is not needed here -- moreover, it's a bad idea, since it increases the complexity unnecesarily. There is nothing that has to run in parallel in order to animate sprites. You should rather update the animation logic in every frame, dependent on the elapsed time (can be fixed time step).

How to animate efficiently sf::Sprite object in SFML? Is there any 'proper' way?

A very simple way would be to use my library Thor and its Animation module. You could have a look at the tutorial and API documentation.

[Ixrec]

It sounds like you're asking about smooth movement rather than "animations" (ie changing a sprite's texture every frame).  Using a separate thread for this is an absolutely bizarre way of doing it.  At the very least you should be updating the sprite's position within your normal game loop (the same one where you draw it), if only because doing this in a separate thread gains you nothing but race conditions.

For how to do the update "correctly" so that it depends on delta time rather than a fixed framerate, read this: https://github.com/SFML/SFML/wiki/FAQ#graphics-smooth-animation  Yes, it has code examples.

If you want to upgrade from basic delta time to a fixed timestep, read this: http://gafferongames.com/game-physics/fix-your-timestep/  Note that fixed timestep is often overkill for super simple games and (if this forum is any indication) it's frequently misunderstood by newbies, so start with delta time.

If you actually did want animations, Nexus' post covers that.

[fjanisze]

Multithreading is not needed here -- moreover, it's a bad idea, since it increases the complexity unnecesarily. There is nothing that has to run in parallel in order to animate sprites. You should rather update the animation logic in every frame, dependent on the elapsed time (can be fixed time step).

Using a separate thread for this is an absolutely bizarre way of doing it.  At the very least you should be updating the sprite's position within your normal game loop (the same one where you draw it), if only because doing this in a separate thread gains you nothing but race conditions.

For this specific case is not rquired, but in other circumstances is needed. I use the same engine also for other projects and having the whole application blocked until an animation (which may take seconds) is ongoing is a bad idea (expecially when i have plenty of object rendered). For this reason, the drawing logic works on a separate thread.

Thanks all for your links, i will read them carefully.

[Nexus]

I use the same engine also for other projects and having the whole application blocked until an animation (which may take seconds) is ongoing is a bad idea

That's not the way you are supposed to do it.

You do not complete an animation before you handle other parts of the game -- you only compute a single frame and then draw that frame. In the next iteration of the game loop, you compute the frame again by incorporating the since elapsed time. Maybe the animation has advanced already, so that the next frame is shown. Maybe it still shows the same frame. That's exactly what Thor encapsulates by the way, it probably gets clearer when you read the tutorial.

Thus: no, threads are definitely a bad idea for animations.

[AFS]

For this specific case is not rquired, but in other circumstances is needed. I use the same engine also for other projects and having the whole application blocked until an animation (which may take seconds) is ongoing is a bad idea (expecially when i have plenty of object rendered). For this reason, the drawing logic works on a separate thread.

Regardless of how long the animation will take, you still can do everything on one thread. You need to simply advance your animation a little per frame, and always check input regardless if the animation is playing or not. You don't need to FINISH the animation before checking input, just advance it.

So, your game loop should be something like:
- Clear window.
- Check input.
- Advance the animation a little bit (for example, moving your block only 1 pixel to destination).
- Draw.

That's it. Your application shouldn't get blocked.

EDIT: ooops, didn't see Nexus's answer.

[fjanisze]

I think i got your point guys, thanks for the feedback and if you have any other resource to share you're welcome