Hi there.
I have a really hard time to implement proper multithreading in my application. The problem is that I cant find a way to update the input devices (Keyboard, Mouse, Joystick, etc) without using the Display.update() method.
I have one thread, my "rendering" thread, which is doing all the openGL related stuff. It also updates the Display periodically.
I have another thread which updates the application logic. Only this second thread is supposed to work with user input.
The problem is, that if my rendering is getting more complex and thus laggy, the input starts to lag as well because its connected to the Display update.
I want to keep the application smooth and have the input polled only by the logic thread so it wont depend on the speed of the openGL function calls.
Can anybody guide me through this?
Thank you all in advance.
There is a version of Display.update() which takes a boolean as a parameter which decides whether or not to poll the input devices. You can then poll each input device individually by calling its poll() method.
So use Display.update(false); in your render thread and then call Keyboard.poll() and Mouse.poll() in your logic thread.
I see.
Do I also need to call "Display.processMessages()" in the rendering thread? Because the Documentation for the Display.update(boolean) method says that system messages would not get processed.
I just tested it; I do need to call "Display.processMessages()" and its not quite decoupled since the updates still depend on the message processing.
Yes. I forgot about that one.
Just a little update:
I still havent found any way of achieving this. But this must be possible, right? I mean, the keyboard and mouse are independent of any graphics so why would they be linke together?
Input isn't linked to graphics, but it is linked to the window. You can't have an event loop for a specific window outside the thread that created that window. That is an operating system limitation/design choice.
If you'd like to decouple rendering from input polling, you could a) poll input more than once between SwapBuffers* calls b) offload rendering to another thread (which means another context + framebuffer copy overhead). If you'd like to decouple gameplay from input polling, poll as fast as you'd like on the main thread and pass events to the gameplay thread through a queue.
Thanks for the response. Its a bummer that the window and the input belong to each other.
I dont think having another context for rendering would really improve anything so I would rather not settle for that.
I guess I will work with the SwapBuffers approach of updating input and graphics on different rates.
Just use a ConcurrentLinkedQueue where the rendering threads pushes events to it and the input thread reads from it. That's your best and fastest option.