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

Author Topic: [SFML2] Input on another thread  (Read 6795 times)

0 Members and 1 Guest are viewing this topic.

roosterkin123

  • Newbie
  • *
  • Posts: 43
    • MSN Messenger - rogerboy@hotmail.co.uk
    • View Profile
[SFML2] Input on another thread
« on: December 17, 2010, 11:58:37 pm »
I really need some help.

I have tried to separate the rendering (main thread)
and input/update (worker thread)

both are running at the same time and no deadlocks seem to be detected.

When the game runs:
Displays first frame fine but has the windows 'wait' icon and mouse cannot be moved or anything, if you do it just crashes or says unresponsive.

I am assuming there is some error with detecting input on another thread but I dont know.

On the worker thread I am using the getinput method of finding if a key is pressed (ie sticky keys) and also some standard event processing like how it is in the tutorial.

This is SFML2 branch that is todays date

Thanks

tntexplosivesltd

  • Full Member
  • ***
  • Posts: 163
    • View Profile
[SFML2] Input on another thread
« Reply #1 on: December 18, 2010, 12:50:32 am »
It probably isn't worth having the input thread on a seperate thread. If one thread is held up (e.g. rendering), the input will be problematic, and gameplay could be adversely affected.

roosterkin123

  • Newbie
  • *
  • Posts: 43
    • MSN Messenger - rogerboy@hotmail.co.uk
    • View Profile
[SFML2] Input on another thread
« Reply #2 on: December 18, 2010, 02:55:58 am »
Well I had it that way before and I did not like it, it produced very akward result when fps slowed down.

And a lot of people on forums advise to separate rendering and update function

tntexplosivesltd

  • Full Member
  • ***
  • Posts: 163
    • View Profile
[SFML2] Input on another thread
« Reply #3 on: December 18, 2010, 03:01:51 am »
Okay then. What is meant by update?

roosterkin123

  • Newbie
  • *
  • Posts: 43
    • MSN Messenger - rogerboy@hotmail.co.uk
    • View Profile
[SFML2] Input on another thread
« Reply #4 on: December 18, 2010, 03:09:56 am »
all the game logic
ie everything but opengl calls

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
[SFML2] Input on another thread
« Reply #5 on: December 18, 2010, 02:33:30 pm »
It's common to separate game logics and rendering into separate threads but in order to make it work well without any losses you have to design the system to be asynchronous. I've done it using messaging but so far I only got Rendering thread and Main thread. I have the main thread pull events from the window, turn them into a message and send them to the appropriate thread. This way the threads don't depend on each others and they can run full speed without having to wait up on synchronization.

Also a gain from this is that my main thread runs at a frequency of 100 times a second and my rendering at 60. My logic thread will probably run at 100 too or faster. This architecture would also allow you to make the physics(if you want that) in it's own separate thread.

*EDIT*
More about your problem, are you somewhere pulling the events from the window? If you don't then the Input object won't be updated. And you should pull the events in the same thread as the input object or else you might read invalid input at the same time as you try to update it. Also why Windows interpret your application as unresponsive might be if you have the update thread run at full speed without any sleep. I.E your frequency of your thread is the same as the CPU.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

roosterkin123

  • Newbie
  • *
  • Posts: 43
    • MSN Messenger - rogerboy@hotmail.co.uk
    • View Profile
[SFML2] Input on another thread
« Reply #6 on: December 18, 2010, 08:02:07 pm »
Thanks a lot for replies im going to try to change the input object when I get home.

As for the sleep thing, my update loop is pretty large. theres all sorts of raycasts and sound checks going on im pretty sure it doesnt need to sleep, but then again I can allways experiment later on

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
[SFML2] Input on another thread
« Reply #7 on: December 18, 2010, 08:36:44 pm »
Quote from: "roosterkin123"
Thanks a lot for replies im going to try to change the input object when I get home.

As for the sleep thing, my update loop is pretty large. theres all sorts of raycasts and sound checks going on im pretty sure it doesnt need to sleep, but then again I can allways experiment later on


Also, check so that you are pulling events from the window. Or else input won't get updated.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

roosterkin123

  • Newbie
  • *
  • Posts: 43
    • MSN Messenger - rogerboy@hotmail.co.uk
    • View Profile
[SFML2] Input on another thread
« Reply #8 on: December 19, 2010, 01:19:03 am »
Whats happening so far is:

Render loop on main thread with while(GLR->GetMainWindow()->GetEvent(Event)){blah;} works fine

As soon as I move the while(GLR->GetMainWindow()->GetEvent(Event)){blah;} to a worker thread it stops working.

Its not even using input objects right now
its just accessing a window that was creating on the main thread.

Any suggestions>?

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
[SFML2] Input on another thread
« Reply #9 on: December 19, 2010, 02:16:38 am »
Don't know if handling event's in one thread other than the one creating the window will screw it over. But you can pull the events in the original thread and still use the input object in another thread.

Can you specify more how it "does not work"? What does actually happen?
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
[SFML2] Input on another thread
« Reply #10 on: December 19, 2010, 08:28:36 am »
Quote
Don't know if handling event's in one thread other than the one creating the window will screw it over.

It does.
Laurent Gomila - SFML developer

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
[SFML2] Input on another thread
« Reply #11 on: December 19, 2010, 02:15:01 pm »
Quote from: "Laurent"
Quote
Don't know if handling event's in one thread other than the one creating the window will screw it over.

It does.


Thought so, SDL got the same problem.

What you can do rooster is that you pull all events in the original thread and then use Input to read the events in the update thread. If you need to sometimes maybe work directly with the events in the update thread, you can use a synchro object with a queue which you push the events into and then pop them in the update thread.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

roosterkin123

  • Newbie
  • *
  • Posts: 43
    • MSN Messenger - rogerboy@hotmail.co.uk
    • View Profile
[SFML2] Input on another thread
« Reply #12 on: December 19, 2010, 03:43:53 pm »
Ah I see well now im thinking of just launching another thread to handle the event itself. But still having the event processing on the main thread.

It doesnt become unresposive anymore thanks.

Do you know how much of a performance decrease doing the whole while loop of GetEvent is on the rendering thread? I dont have any profiling experience so I dont know.

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
[SFML2] Input on another thread
« Reply #13 on: December 19, 2010, 05:11:47 pm »
Look don't worry about performance. You'll have to do something really stupid in order to make performance matter. Just do what you feel is natural and just try to get everthing running.

"Make it work, Make it right, Make it fast", do it in that order ;)
Developer and Maker of rbSFML and Programmer at Paradox Development Studio