Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: OpenGL calls in a different thread  (Read 2875 times)

0 Members and 1 Guest are viewing this topic.

tntexplosivesltd

  • Full Member
  • ***
  • Posts: 163
    • View Profile
OpenGL calls in a different thread
« on: January 17, 2011, 09:40:37 am »
Hi.
I was planning a game loop and decided to have an SFML windowing/input loop in one thread, and an OpenGL 3D rendering loop in another.
Since then, I have come across some potential flaws in my idea:

• If I use SetActive() in one thread, and have the OpenGL calls in another, will it apply the OpenGL stuff to the "active" window.
• Which loop/thread do I have to use the Display() method in? What if the Display() method is called halfway through the OpenGL loop doing it's thing?

Would appreciate any comments/suggestions on seperating rendering and input in seperate threads(is it a good idea?)

Thanks in advance
tntexplosivesltd

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
OpenGL calls in a different thread
« Reply #1 on: January 17, 2011, 10:37:29 am »
Quote
If I use SetActive() in one thread, and have the OpenGL calls in another, will it apply the OpenGL stuff to the "active" window.

SetActive works per-thread. So any OpenGL call will happen in the window that is active in the current thread.

Quote
Which loop/thread do I have to use the Display() method in? What if the Display() method is called halfway through the OpenGL loop doing it's thing?

Probably in the rendering thread. Anyway if you have potential concurrent access, use a mutex.

Quote
Would appreciate any comments/suggestions on seperating rendering and input in seperate threads(is it a good idea?)

If you know exactly why you want to use multiple threads then it's probably a good solution.
If you don't ("threads are fancy, yeaaah I'm gonna use them") then you probably don't need them and the additional work/troubles they bring.
Laurent Gomila - SFML developer

tntexplosivesltd

  • Full Member
  • ***
  • Posts: 163
    • View Profile
OpenGL calls in a different thread
« Reply #2 on: January 17, 2011, 10:52:22 am »
So having the input and OpenGL rendering in the same thread isn't a bad thing? I was only having them in different threds because I thought that if I had input on the same thread as rendering, the input could be undesriably held up. Or is that not such a bad thing?

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
OpenGL calls in a different thread
« Reply #3 on: January 17, 2011, 11:30:37 am »
You can get that effect yeah but most applications don't need it.

The problem is only if you want the user to be able to not feel any lag in input even though you are doing some heavy logic or rendering.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
OpenGL calls in a different thread
« Reply #4 on: January 17, 2011, 11:34:28 am »
It is a bad thing only if you're writing a fast paced game that might run slowly on some users PC.

In any case I'd suggest to test first. Using threads without making sure you really need them is always a bad idea.
Laurent Gomila - SFML developer

tntexplosivesltd

  • Full Member
  • ***
  • Posts: 163
    • View Profile
OpenGL calls in a different thread
« Reply #5 on: January 17, 2011, 10:51:10 pm »
What about for network playing? I don't want one user who's got a slower computer but a fast internet connection to be sending less player position packets because the rendering is holding up the input.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
OpenGL calls in a different thread
« Reply #6 on: January 18, 2011, 08:01:30 am »
If everything's fine locally, network won't be a problem.
Laurent Gomila - SFML developer

 

anything