Hi everyone,
I'm currently evaluating LWJGL3 for a Java-based project. The project is a "simple" game engine that will be used in a computer science course on computer game architecture/implementation.
I've used JOGL before, and it has been good, but there's a particular constraint that's been getting in my way lately (particularly, the fact that you can't make OpenGL calls outside of specific locations, like display(GLAutoDrawable) override.), which is why I'm checking this one out.
However, I think I've found something that's getting in my way with LWJGL when it comes to input handling. For example, the documentation (eg.
https://github.com/LWJGL/lwjgl3-wiki/wiki/2.6.3-Input-handling-with-GLFW) seems to imply that the
only way to manage inputs is by using the glfw* functions.
The design problem this creates is that it seems difficult to completely encapsulate/hide the fact that the engine depends on LWJGL from the client application itself because for the client/game to be able to handle inputs, it'd have to use the glfw* functions and callbacks directly, exposing to the client that there's in fact a dependency on LWJGL, instead of relying on interfaces like KeyListener, MouseListener, etc.
My goal is for the client to depend on the "simple" engine that's being developed and on the interfaces that the engine itself should/will expose, rather than "leak" the LWJGL/JOGL/Whatever dependency within the engine itself.
I searched the forum for a bit and did not find anything that seemed related to this. Then again, there were lots of hits and it's not realistic/practical to go through
all of them, so I apologize if this topic has been discussed in some deep and dark corner of the forum, perhaps by using keywords different to those I used during my search
Questions:- Is there a nice way around the situation I've described, perhaps something I'm missing?
- Any suggestions and/or recommendations?
- Anything you'd like me to clarify?
Thanks in advance,
-x