multi-threaded drawing

[nominos]

Why isn't the code below working correctly? By not working I mean that it isn't fluent like if I would manage everything in the main thread. I just want to seperate the game logic and the rendering. I am very new to SFML and threads in general. Could somebody help me here? Thanks!

Code: [Select]

#include <SFML/Graphics.hpp>

void renderingThread(sf::RenderWindow* window, sf::Shape* shape)
{
    while (window->isOpen())
    {
        window->clear();
        window->draw(*shape);
        window->display();
    }
}

int main()
{
    // create the window (remember: it's safer to create it in the main thread due to OS limitations)
    sf::RenderWindow window(sf::VideoMode(800, 600), "OpenGL");

    sf::CircleShape shape(100.f);
    shape.setFillColor(sf::Color::Green);

    // deactivate its OpenGL context
    window.setActive(false);

    // launch the rendering thread
    sf::Thread thread(std::bind(&renderingThread, &window, &shape));
    thread.launch();

    while (window.isOpen())
    {
            shape.move(0.000001f,0.f);
    }

    return 0;
}
(code is taken from http://www.sfml-dev.org/tutorials/2.1/graphics-draw.php#drawing-from-threads and http://www.sfml-dev.org/tutorials/2.1/start-linux.php#compiling-a-sfml-program)

[Jesper Juhl]

Looks dangerous. No synchronization between the threads.

Why do you even need/want threads?
Unless you have a very good use-case/strong need for threads (and experience with them and C++) then they are very likely to cause you far more trouble than gain.

See also:
 http://en.sfml-dev.org/forums/index.php?topic=15018.msg106017#msg106017
 http://en.sfml-dev.org/forums/index.php?topic=14113.msg100559#msg100559

[nominos]

Looks dangerous. No synchronization between the threads.

Why do you even need/want threads?
Unless you have a very good use-case/strong need for threads (and experience with them and C++) then they are very likely to cause you far more trouble than gain.

See also:
 http://en.sfml-dev.org/forums/index.php?topic=15018.msg106017#msg106017
 http://en.sfml-dev.org/forums/index.php?topic=14113.msg100559#msg100559

I probably need to read more about threads.. I thought that they are much easier.

The reason why I want threads is that I can simplify my code and more importantly to speed up the game because I have to do CPU-intensive stuff like path finding.

[Jesper Juhl]

Threads seem deceptively simple on the surface, but they are hard to use correctly and introduce a lot of complexity.
Sometimes they are the right tool for the job and when used correctly and for the right things they can indeed provide nice speedups. But unless you really need them they are not worth all the trouble they bring (IMHO).

Modern CPUs are incredibly powerful and you can do an incredible amount of work in 16ms or so between frames. As the saying goes "premature optimization is the root of all evil". I'd advice to hold back with the threads until you are either saturating a single core or are facing a problem that is rediculously parallel.

As far as pathfinding goes; I think you'll be surprised at how many nodes a well implemented A* algorithm can explore in just a few ms. And even if your pathfinding needs are so heavy that they cannot be completed in a single frame, then there are ways around that - like only exploring n nodes per frame or only exploring as many nodes as you can in, say, 5ms. You don't need threads for that.

[Syntactic Fructose]

If you're getting into threading I would highly recommend taking a look at using futures, futures are quite literally the future in my opinion!

[Nexus]

Futures are high-level primitives for asynchronous or synchronous (deferred) computations. They can be used when the main thread waits for results of a computation that runs possibly in a separate thread, and are as such not a replacement for threads in general. In particular, they're not directly applicable to scenarios where a second thread is running all the time, such as in this example.

I totally agree with Jesper Juhl concerning the complexity of multithreading as well as premature optimization. A lot of multithreading beginners have the impression that multiple threads would magically make things faster and solve their problems that are in fact none. There are cases where threads are appropriate, and these are mainly operations that would otherwise block the main thread and make the application unresponsive, such as networking, long-lasting resource loading or similar.

Game logic in itself does not necessarily require threads. You should design your code in a modular way that would allow to easily embed threads at a later stage. Important points to consider here are that you program modularly, reduce inter-dependencies between modules to an absolute minimum, and avoid global and static variables at all cost. In multithreaded programs, a challenge is synchronization, and you'll want to keep interfaces small. But the mentioned points are also highly beneficial for single-threaded programs.