[SFML2] Input on another thread

[roosterkin123]

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]

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]

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]

Okay then. What is meant by update?

[roosterkin123]

all the game logic
ie everything but opengl calls

[Groogy]

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.

[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

[Groogy]

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.

[roosterkin123]

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]

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?

[Laurent]

Don't know if handling event's in one thread other than the one creating the window will screw it over.

It does.

[Groogy]

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.

[roosterkin123]

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]

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