Messages

1

Graphics / Re: Thread separation

« on: November 13, 2019, 12:03:41 pm »

Thank you for the response!

I have more than extended experience in multithreading programming and I am fully aware of the issues. I agree with your assessment that people should not jump into it if they are just getting started.

For my purpose it means that I will have to investigate  the details of SFML implementation (which is very clean and easy to follow as a matter of fact) and wrap it around the multithreading facilities I have in mind.
 
My understanding on the context implementation in SFML though is different than yours. It seems that there is a global shared context, that threads can use and access the state without the need of switching. All you need is an active SFML context on each thread. Please let me know if this is incorrect. I plan proper measures that guarantee no opengl location is written by two threads at the same time.

Your answer gives me a very clear path.

2

Graphics / Thread separation

« on: November 11, 2019, 11:57:07 pm »

Hello,
I want to separate the game logic and rendering in two individual threads. Essentially the game logic will be responsible for modifying the SFML drawables (like changing position or color) and the rendering thread will of course perform the rendering. I will  guard against thread collisions through an immutable facility (i.e. the render thread will be reading objects that provably cannot change).

I browsed the sources and this seems feasible because it seems to me that when for example setting the position of a shape, SFML does not perform any opengl calls.

Hence my question is: is this separation guaranteed by the SFML design or this just applies to certain functions only?

Edit: To phrase it differently in case it helps: does SFML invoke opengl calls on objects on the draw call only, or also when modifying the objects properties also( like position, color, etc). I am interested both about shapes and views.