Managing multiple animations

[ConnorJW]

Hey all,

I'm working on a project at the moment which visualises sort algorithms to demonstrate how they differ in handling the sort problem. This requires a lot of on-screen animation, but vitally, takes in no user input. I'm pretty new to SFML, so I was wondering what's the best approach to handling the animation of each element on the screen?

The elements (each are sprites), will be moved one after another to show the process of sorting. Then once sorted, the sprite will be highlighted green; this has already been implemented. The problem is with all the animations playing at the same time, apposed to first animation, pause, second animation, pause etc...

Originally I though of using threads (coming from a currency programming background), but the SFML tutorials suggest to not use threads to handle graphics. So would you suggest using state machines to achieve this?

Any document/references will be most helpful - or your opinion on how you would go about implementation.

[Jesper Juhl]

Personally I'd use Thor Animations :

 http://www.bromeon.ch/libraries/thor/v2.0/tutorial-animations.html

 http://www.bromeon.ch/libraries/thor/v2.0/doc/group___animations.html

[Arcade]

When you say animation, it sounds like you are asking how to handle visually moving the elements on screen, not how to animate the sprites with multiple frames, correct? When Jesper Juhl suggested Thor Animations, I think he was assuming the latter.

Anyway, it is hard to suggest something without knowing exactly the visual effect you are going for or how you have approached the problem so far. Can you provide us with a something so that we can see what you currently have? Perhaps source code (if it isn't large), a build of your program, screenshots, a video, or animation gif?

You say your biggest problem is that all elements are moving at the same time. Why not just compute the first step of your sorting algorithm and move that element to its destination before computing the next step?

Alternatively, another basic approach could be to compute all animations ahead of time (which sounds like what you have already done) and then store the elements in a vector or something. Move only the first element until it has reached its destination, remove it from the vector, and repeat until there is nothing left in the vector.

Can you also explain how you were thinking threads could help you with this problem? That doesn't sound right, but if you explain your reasoning it may help give more details on exactly what you are stuck on.

[Jesper Juhl]

When you say animation, it sounds like you are asking how to handle visually moving the elements on screen, not how to animate the sprites with multiple frames, correct? When Jesper Juhl suggested Thor Animations, I think he was assuming the latter

I was indeed.

[ConnorJW]

Yes, sorry, all the sprites are doing is moving via the sprite.move() every frame until it reaches the desired location on the x,y axis, then stays there. This is done via an update function:

void DrawCups::update(float perFrameX, float perFrameY, float desiredX, float desiredY)
{
        _cup1Sprite.move(perFrameX, perFrameY);
        if (_cup1Sprite.getPosition().x >= desiredX)
        {
                _cup1Sprite.setPosition(desiredX, desiredY);
                _cup1Sprite.setColor(sf::Color(0, 255, 0));
        }
}

which is called in the window main loop:

while (window.isOpen())
        {
                sf::Event event;
                while (window.pollEvent(event))
                {
                        if (event.type == sf::Event::Closed)
                                window.close();
                }

                window.clear(sf::Color(250, 240, 230));
                drawToWindow.drawBench();
                drawToWindow.update(1,0, 400,230);
                drawToWindow.drawCups();
                //drawToWindow.update(1,1,500,330);
                window.display();
        }

The program isn't running on the back of a sorting algorithm, it serves the purpose to explain problem solving process in a visual way; i.e. Insertion Sort uses cups with numerical values which then move in location to demonstrate the updating elements within the data structure as the sort continues through.

[Arcade]

Is the code you posted the actual code you are using, or just an example to demonstrate to us what you are doing? I'm assuming its the latter because in your original post you said that the problem you were having was that all of your sprites (the cups?) were moving at the same time. In the code snippet you provided I only see one sprite (_cup1Sprite). Can you show us how you are updating and drawing all of your sprites?

[ConnorJW]

Yes, the code provided is just for one sprite, sorry about that.

The sprites are loaded through an init function in the DrawCups constructor:

void DrawCups::initSprites()
{
        loadImage("./images/InsertionSort/red_cup_1.png", _cup1, _cup1Sprite);
        _cup1Sprite.setPosition(200, 230);
        _cup1.setSmooth(true);

        loadImage("./images/InsertionSort/red_cup_9.png", _cup9, _cup9Sprite);
        _cup9Sprite.setPosition(sf::Vector2f(300, 230));

        loadImage("./images/InsertionSort/red_cup_3.png", _cup3, _cup3Sprite);
        _cup3Sprite.setPosition(sf::Vector2f(450, 230));

        loadImage("./images/InsertionSort/red_cup_5.png", _cup5, _cup5Sprite);
        _cup5Sprite.setPosition(sf::Vector2f(600, 230));

        loadImage("./images/InsertionSort/red_cup_2.png", _cup2, _cup2Sprite);
        _cup2Sprite.setPosition(sf::Vector2f(750, 230));

        loadImage("./images/InsertionSort/red_cup_8.png", _cup8, _cup8Sprite);
        _cup8Sprite.setPosition(sf::Vector2f(900, 230));
}

Each sprite is being drawn via the 'drawCups' function:

void DrawCups::drawCups()
{
        _window.draw(_cup1Sprite);
        _window.draw(_cup9Sprite);
        _window.draw(_cup9Sprite);
        _window.draw(_cup3Sprite);
        _window.draw(_cup5Sprite);
        _window.draw(_cup2Sprite);
        _window.draw(_cup8Sprite);
}

I removed the code for the moving of the other cups because it was the exact same function as the .update(), just updateCup3() etc... I've decided to go in the direction of just having one update function that will call the name of the sprite needing to be updated.