# How can I access LWJGL's Keyboard from a thread other than the graphics thread?

I'm loving LWJGL, but have been running into a number of odd problems with it. Most of it seems to deal with the fact that OpenGL is a state-machine and was only ever meant to be accessed from a singular thread.

However, I'm dealing with OpenAL and input as well, and they are both bound pretty tightly into LWJGL. In spite of the fact that they are entirely independent of graphics, I have been getting an IllegalStateException every time I try to access Keyboard.isKeyDown outside of the graphics thread. It's hard to emphasize how important it is to me that I have a new thread for each feature of this project; the classic game loop will not do the job.

How do I accomplish this? There must be a way.

• Here's a crazy idea: use the Lightweight Java Graphics Library for graphics, and use separate libraries for audio and input? – Fault Dec 4 '13 at 19:28
• Indeed a crazy idea. It's the "Lightweight Java GAME Library", not Graphics Library. – Basaa Dec 4 '13 at 19:58
• I've considered that, but a large part of my rationale in using LWJGL instead of JOGL was its inclusion of OpenGL, OpenAL, and a few odds and ends like JInput. So it really isn't ideal. The other possibility (I think) is to establish a new LWJGL Display for each thread, but that's hardly resource efficient and just feels sloppy to me. – Michael Oberlin Dec 5 '13 at 7:25

One solution (and probably the easiest) would be to create a small wrapper class around the LWJGL input system. Check all the key states, and save them in an ArrayList. Then, somewhere at the beginning of your game loop, update your Input class once, and use that information you stored for future reference.

Code example: click

This also has the benefit of you being able to seperate pressed, hold and released keys. The example also includes the same system for the mouse.

• I don't think you understand the concern. I don't have a standard game loop, because that concept (as prevalent as it still is) has been outdated since the Source engine came out in 2001. The thing is that it clearly demonstrated that funnelling graphics, audio, AI, physics, and other independent concerns into their own threads provided substantial improvement in resource management. Since the framework that I'm building is for more than just games, I intend to go with the road of multithreading everything; LWJGL works fine, I need it to work in multiple threads at once. – Michael Oberlin Dec 5 '13 at 7:29
• Then you failed at explaining in your question what you want to know. You asked how you can access LWJGL's input system in multiple threads, and this is the answer. As LWJGL doesn't allow you to do it the normal way, you must make a wrapper for it. And at some point, you have to poll for your Keyboard events and you have to save this data somewhere. There is simply no other way. – Basaa Dec 5 '13 at 12:23
• Okay, I'm suspecting that on the inside, LWJGL is running a parallel loop of its own. My idea was to be able to hot-swap threads if I ever wanted to port this to JOGL or some super-advanced nonexistant version of JavaFX that might come along. I've done that before (old audio editing program) and it worked pretty well. I suppose I could write something in to provide static access to the keyboard. Is stand-alone JInput anything like this? – Michael Oberlin Dec 5 '13 at 15:59
• I did something else, but I think your advice did the job, thank you. – Michael Oberlin Dec 5 '13 at 17:07

The way I did it is simply calling Keyboard.create() in all the threads that I need to use Keyboard.isKeyDown(int key). I know this sounds sloppy, but it has been working perfectly for me so far.

So, after some helpful comments and a little digging through decompiled jars, here's my conclusion. In a word "no," but generally that's just because LWJGL operates (once again) through state machines.

I would like it very much if there was a way to separate those without rewriting the library, but in the mean time, I've established a single thread as an LWJGL thread but kept my original architecture and interfaces around. The LWJGL thread is simply compatible for audio, input, and video all at once. If I want to direct audio to a new AL thread, or get input from a new Input thread, I can do that in the future.

The main idea was to separate model, view, and control from the old school game loop; and I think it's working pretty well.