I’m starting with LWJGL and the jar I got from the site doesn’t seem to match the Javadoc at all… For one thing, there is no GLFW package (well, in the system package… but the classes are completely different)… What is going wrong here? Is the javadoc and tutorial out of date or is the jars and natives?
Which docs are you reading? The sources are also included with the download, so your IDE should use those if you link them in the project config.
EDIT: is this your problem? http://forum.lwjgl.org/index.php?topic=5588.0
Thx… does this mean that in the future it will add the GLFW packages?
Also, I am kind of finding it annoying that LWJGL3 is designed to have multiple windows with one per thread but must of the actions (including getting and setting info like input and window size) require you to be in the main thread…
Isn’t “main thread” just the thread of whatever window is current?
Disclaimer, I haven’t worked with LWJGL3, but I believe in the principle of least surprise.
nope, it wont work in the thread of the current context… it must be the main thread… this is for things like:
- changing window properties
- creating or destroying windows
- polling events
- getting input info (keyboard, mouse and controllers)
about the only thing that you can do outside the main thread is making the window the current context and swapping buffers
Well then the rest of it makes sense. Why is that annoying?
because it is supposed to be a window per thread so my idea was having multiple threads with their own windows and game loops but for, instance, i wanted to destroy the window if the mouse is in a certain area… I have to tell the main thread some how to get the X and Y and then wait for the main thread (which i guess would have its own loop in this sense) to get those values, then I have to check the X and Y and if it is in a certain area, I have to then tell the main thread to destroy the window and wait for it to be destroyed…
Yes I know I can just tell the main thread to do all that at once but this is for a game engine and I dont think I would be able to make a message for the main thread for everything that the developer might want…
Going by the Getting Started code, events like mouse position and such is just like in Swing or what-have-you, via glfwSetKeyCallback etc. In fact it’s probably cleaner.
And if you use Java 8 (maybe not a good idea if it’s for an engine) then lambdas make it really nice.
I don’t immediately see any need to actually have to deal with threads in your game loop, maybe aside from GLContext.createFromCurrent();
“Everything the developer might want” is what LWJGL is. You’re trying to make a wrapper for a wrapper?
Three things:
- Not get events from input, get actual input data…
- Multiple threads for a window and a OpenGL context per thread
- My game engine is going to be easier and along the idea of “make an entity and tell it what to do (program it) then leave it… no need to update it and render it every frame”
Out of all the tedious things in programming, calling render() and update() are pretty low on the list. Besides, how are you going to make an engine without these methods?
Just as a simple overview:
- You have a World object
- You add overriden entities to it
- The update method will be called on all the entities every frame
- In the update thread the developer has code which should do stuff like check input, change entity position, etc.
- Everything is rendered
I like making my own stuff 
I have fun doing it and it makes me happy when I am finished knowing that I made everything that I am seeing on my screen. (except for the background stuff like Java and LWJGL)
No, I’m saying that maybe you should design your engine towards an FRP engine. Adds novelty, I don’t know of any FRP java game libs.
Maybe, I’ll have a look into it…
Well anyway, to get back on topic:
Is there any way to have multiple windows in multiple threads? Or do I just have to do what I did with my last engine and have one static World (window)
Yes. The restriction on keeping event handling in the main thread comes from GLFW (if you haven’t already, it’s a good idea to familiarize yourself with the GLFW reference documentation). Some functions may only be called from the main thread and some may not be called from callbacks. That does not preclude using multiple windows in multiple threads. A rendering context can be made current on any thread, regardless of where the window was created. Once you’re familiar with what can and can’t be called from where, it’s fairly easy to set something up.
I didn’t write this and haven’t tested it myself, but this is an example of using multiple windows in multiple threads with GLFW in C. From there, it’s not hard to work out how to push events onto per-thread cues to handle as you see fit. GLFW also has an API for querying the device state per window (glfwGetKey, glfwGetMouseButton, etc). I haven’t looked closely enough at LWJGL3 yet to know if they expose that or not, but if they do those functions appear to be callable from threads other than main.
Short answer:
-
Yes, it is possible to do multi-threaded rendering with multiple windows, as long as events are handled in the main thread. Here is a sample of doing exactly that with LWJGL 3, from the LWJGL tests module.
-
LWJGL 3 exposes everything in GLFW, including the native APIs.
-
The javadoc problem was probably related to the recent change of the GLFW package. It was moved from org.lwjgl.system.glfw to org.lwjgl.glfw. The javadoc and latest build should be in sync now.
Long answer:
As aldacron said, the main thread limitation exists because of GLFW’s design, not LWJGL’s. This is not an arbitrary design decision. The primary restriction is the design of OS X: you have no choice there but to do everything in the main thread. If for some reason you need more than one main event loop, the only workaround is to launch multiple processes that communicate via an IPC mechanism. Other OSes are more relaxed, but there are still some restrictions, e.g. on Windows the event loop must run on the same thread that created the window. These issues are all solved neatly by doing what GLFW does, run all window management and event handling functionality in the main thread.
This is not a unique design either, most other (cross-platform) GUI toolkits/frameworks work the same way. For example, we have the event dispatch thread (EDT) with AWT/Swing, which on OS X is forced to be the first thread in the process. This is also why AWT and GLFW are fundamentally incompatible on OS X; they both require that first thread to be the thread in which they run their respective event loops.
So in summary, is it just going to be easier to just have one static window?
Generally, in software development, working with multiples of anything does not make things easier.
The point of LWJGL 3 is that it’s up to you, assuming you follow the rules of the binding used (GLFW in this case). One window or multiple windows, one thread or many threads, it’s your choice. If you think GLFW’s design is not satisfying, feel free to suggest a better alternative or roll you own (LWJGL exposes OS-specific APIs, e.g. Xlib on Linux).