[Solved] SFML and Multi Threading

[reduz]

Hi! I intend to give a try to SFML at the small game studio were i´m working at.
We tried to use SDL for portability, but it really has a lof of design limitations, so I´m wondering the same things about SFML.

First of all, how multi-threaded is SFML? In modern games that utilize OpenGL, it is very common that one thread handles keyboard, logic, and many OS ops, and another thread exclusively does scene culling and rendering, as this scales into multicores and modern game consoles. So, is it possible in SFML to move the graphics to a separate thread (And get the OpenGL context with it) while the rest of SFML runs in the main thread?
Because as said before, SDL is not designed and not able to do this, and this is a very important feature needed for modern 3D engines.

Thanks in Advace!

[Laurent]

A lot of efforts have been made to make SFML multi-thread compliant.

First, you have explicit control over binding the OpenGL context, so you can move it to any thread. Then, events handling have been separated from rendering code, so again you can put it in a separate thread.

However, not all the classes have been designed and tested with a multi-thread architecture in mind, so there might be some code which requires explicit synchronization or special care regarding concurrent access. And I'll be glad to improve SFML if you can find such issues

[reduz]

However, not all the classes have been designed and tested with a multi-thread architecture in mind, so there might be some code which requires explicit synchronization or special care regarding concurrent access. And I'll be glad to improve SFML if you can find such issues

This is great to know, and I will undoubtly make sure to let the developers know of any problems I may find.

Also, I wanted to ask... SDL has this really bad problem that resizing a window destroys the opengl context and there is nothing that can be done about it (textures/arrays and anything other on video memory are lost). do you know if SFML works around this issue properly?

Thanks!

[Laurent]

You mean, resizing from the code (ie. recreating the window) ?

Anyway, SFML always keeps a dummy OpenGL context alive until the end of the application, which is shared with all other contexts. So your resources are never lost.

And later, I'll probably add a function to let you resize the window without completely recreating it.