Using sf::Thread to display Animations?

[Samyboy]

Hello,

Does using a Thread to display an animation -> showing one sprite, waiting for some time, showing the next one, etc. sound reasonable?

Should Threads be used for smaller stuffs? Or is using a Thread not good for performance?


Thanks

[Laurent]

I don't think so. Graphics should be updated in the main loop -- keep threads for stuff that can benefit from not being synchronized with it, like physics or background loading.

[Samyboy]

I don't think so. Graphics should be updated in the main loop -- keep threads for stuff that can benefit from not being synchronized with it, like physics or background loading.

Okay.

So what do you suggest? When I want to show an Animation of, let's say 50 sprites with a delay of 0.05 beetween each sprite, should I use an sf::Clock and do the checks in the main loop?

What if I do this with 50 other Animations? Won't it get too messy? :S

[Laurent]

You can use one of the animation classes that are on the wiki, at least as a starting point.

Won't it get too messy?

If you encapsulate and organize things properly it never gets messy

[Nexus]

What if I do this with 50 other Animations? Won't it get too messy? :S

No. Just don't do it manually for each of those 50 sprites. Write code that automatically takes care of that functionality. If you store the 50 sprites in a container, you can just iterate over the whole range and apply a function to each element.

And by the way: How do you imagine a thread to become less messy? Don't underestimate the problems related to multithreading.

[Samyboy]

What if I do this with 50 other Animations? Won't it get too messy? :S

No. Just don't do it manually for each of those 50 sprites. Write code that automatically takes care of that functionality. If you store the 50 sprites in a container, you can just iterate over the whole range and apply a function to each element.

And by the way: How do you imagine a thread to become less messy? Don't underestimate the problems related to multithreading.

You're totally right, thanks

[g33kz0rd]

Ive been just readin about Game Loops and stuff a while ago. And it comes to that is totally right some article that ive readed in that time that they say that the graphics should be totally separated from event manager.

Reasons?

It wont care if your machine its really slow generating graphics, your Event response will be the same anyway.

The fact is that i really wanted to take advantage of that.

How?

Making this

And it wont work -_-

Code: [Select]

////////////////////////////////////////////////////////////
// Headers
////////////////////////////////////////////////////////////
#include <SFML/System.hpp>
#include <SFML/Graphics.hpp>

// Create the main rendering window
sf::RenderWindow App(sf::VideoMode(1024, 768, 32), "Teh Game");

bool appRuning = true;

void ThreadFunction(void* UserData)
{
    sf::Event Event;
    while (appRuning)
    {
            if (Event.Key.Code == sf::Key::F1)
            {
                appRuning = false;
            }
    }
}

////////////////////////////////////////////////////////////
/// Entry point of application
///
/// \return Application exit code
///
////////////////////////////////////////////////////////////
int main()
{
    // Create a thread with our function
    sf::Thread Thread(&ThreadFunction);
    // Start it !
    Thread.Launch();

    sf::Image imgIntroLogo;
    imgIntroLogo.LoadFromFile("images/introLogo.png");
    sf::Sprite sprIntroLogo(imgIntroLogo);

    // Hides original SO mouse cursor
    App.ShowMouseCursor(false);

    // Disable vertical synchronization to get maximum framerate
    App.UseVerticalSync(true);

     // Start game loop
    while (appRuning)
    {
        // Clear the screen with red color
        App.Clear(sf::Color(255,0,255));

        // Draw teh Logo
        App.Draw(sprIntroLogo);
    }

    return EXIT_SUCCESS;
}


Why this dosnt works?

Btw, the problem is that it wount take any event. Ive tried in so much ways, it dosnt want to work!

[Ashenwraith]

I don't think this is correct.

Most games have events/input synched with the frame rate so if time slows down you can keep up with the game. If you had it out of synch it would be all weird. That would create input lags like in online play and would be a pain to manage.

[g33kz0rd]

But... i mean, i think u r on the wrong way, meanin that the fact that if you have sync the event manager with the frame rate, that would mean, that in a low frame rate, you will have less response from the event manager.

PD. Sorry my bad english, just not from english speakin countrys.

[gsaurus]

they say that the graphics should be totally separated from event manager.

I think you're taking it the wrong way. Totally separated doesn't have to mean they are in separated threads, but managed in an independent way somewhere inside the game loop.

SFML already takes care of the input capture behind, and provides you with the events states ready to be used, so you don't have to worry about it.
Your code has several problems. I would say, get rid of threads, you shouldn't need them until you do netplay or other advanced things such as loading resources on background as Laurent said.

[Ashenwraith]

But... i mean, i think u r on the wrong way, meanin that the fact that if you have sync the event manager with the frame rate, that would mean, that in a low frame rate, you will have less response from the event manager.

PD. Sorry my bad english, just not from english speakin countrys.

There are input buffers that can only hold so much. If the sprite is barely moving, it doesn't matter how many times you tell it to move/do something different.

Otherwise all of a sudden your sprites would start teleporting and everything would be all jerky.