I'm trying to go "under the table" and wanggle LWJGL into a different display (specifically SWT but I've wanted to do it with other windows). Everything's fine and dandy except for the input devices. I would really like to be able to use them outside of LWJGL's Display.
Currently the only limitation are the calls to Display.isCreated(). According to the javadoc:
@return true if the window's native peer has been created
It doesn't seem too far fetched if you made isCreated() a native method and have it check if "display_hwnd" is non-null (for Windows) for example. Couple this with an exposed setDisplayHWND() or something down in the dll and that should be enough hooks to make this all possible.
I do have some questions surrounding Display.getDisplayMode() (which Mouse.reset() calls). Primarily, in a windowed environment, is the static initializer in Display ("current_mode = init();") adequate to set the sane display mode?
I'd rather have the input devices themselves fetch the necessary information from a specific Display class. Display would then redelegate all calls to that class (LWJGLWin32Display, LWJGLXDisplay, SWTWin32Display etc.) and implement a package private getDelegate that can be cast to either an XDisplay or a Win32Display. Win32Display would then implement getHWND(), XDisplay would then implement getXConnectionHandle() and getWindowHandle().
- elias
I would also rather not have any handles exposed in Java, package-private or not, but hide it all away natively and use opaque Object handles that the native side can use to get real handles.
Cas :)
That would contradict our mission to move all logic to java, whereever possible, wouldn't it? In a perfect world, I'd have enough time to rewrite LWJGL to use a SWT style OS class and do everything from java. In the meantime, I try to move logic from native code to java while I do other changes to the LWJGL code (for example, the extension initialization has recently been moved into GLContext.java and out of extgl.ccp)
- elias
My intent with:
QuoteCouple this with an exposed setDisplayHWND() or something down in the dll and that should be enough hooks to make this all possible.
was that the "setDisplayHWND or something" was one thing referring to the dll and not "setDisplayHWND()" (implying Java), "or something down in the dll".
Anywho, the point is that I don't want you to expose anything in Java. Just make sure that it's excessible via the native lib. But if you went a Java factory or Java opaque objects route I wouldn't be too heart broken :D
Thanks for the work and you guys rock!
Well, I was thinking that you did the job and posted a patch to us ... ;) Maybe you could reduce it to a java Object set/getDisplayHandle() in Display.java where the Object could be an XHandle or a Win32Handle and let the input classes use getDisplayHandle(). Shouldn't be too much work I think.
- elias
If you're OK with the opaque Object then I'll play with it in the morning and see what I come up with.
What if I went with a more SWT approach and just made a public member "public int windowHandle". I just think that having a setter is asking for someone to use it.
It doesn't really matter at the end of the day, but I'd rather have y'all dictate style on this.
It has to be an Object, because for example X uses many values for determining the window, namely the Display connection handle (Display* type) and the window handle (Window type). I don't really have an opinion on whether to use a public field or a setter and getter.
- elias
I hear you loud and clear.
I would be done at this point except for the minor NPE that's occurring in GLContext.useContext() (mentioned in other post).
Or how about using ByteBuffers instead of opaque Object handles? Let the Display create a ByteBuffer big enough to hold a C struct containing the relevant window handles, and let native code fill it out. We'll avoid the nasty long or (int) conversion to C pointers that way. I'm going to do that for the Pbuffer and Cursor.
- elias
Here's where we're at so far:
Requirements:
o To be able to use Mouse, Controller, and Keyboard without using Display.
[/list]
Functionality:
o Common structs between Display and the various inputs that contains the necessary window information.
o ByteBuffers that contains the contents of the structs.
o There is a Display.getDisplayStructure() (tell me if you want another name) to get the structs for the display. If the Display has not been created, calling getDisplayStructure() will throw. Calling destroy() will reset.
o Mouse/Keyboard/Controller.setDisplayStructure() (tell me if you want another name) sets the structs for the contollers. If the controller is already created, calling setDisplayStructure() will throw. Calling destroy() will reset.
o Mouse/Keyboard/Controller no longer use Display.isCreated(). It checks if the display structs have been set.
o Display.create() sets Mouse/Keyboard/Controller.setDisplayStructure() before Display.initControls() is called so all works as it does now.
o If you don't use Display.create() (i.e. you use some other window creation thingy-ma-bob such as my SWT one) then you must Mouse/Keyboard/Controller.setDisplayStructure() appropriately before calling Mouse/Keyboard/Controller.create().
[/list]
At some point I'll actually finish coding this :D
Do we need the Display.getDisplayStructure() method. Not sure about "Structure", maybe "Handle" would be better? Finally, remember to make a Pbuffer.setDisplayHandle() too, because it needs the Display OpenGL context.
Other than that, sounds great!
BTW, I just comitted the change to Pbuffer and Cursor to use ByteBuffers.
BTW2, if you're fast you may finish it in time for the imminent 0.91 release.
- elias
QuoteDo we need the Display.getDisplayStructure() method
It needs to exist in order to provide it to the various controllers on creation. If it needs to be
public is completely arbitrary at this point. If someone wanted to use JInput (just as an example) with Display, then it would be nice for it to be there. I'll leave it up to you folks.
Ah, it's a JNI method. It makes sense now then.
- elias
I prefer the term "handle" to "structure".
Cas :)
So do I, but in some cases it's not just a single handle, it's a structure and I'm all about disambiguating naming. It's your call so "handle" it is.
Well, it's completely opaque on the Java side so it's effectively a handle to the callers of the API.
Cas :)
I have mailed Elias with my changes.
And it's also temporarily available from:
http://www.realityinteractive.com/software/oss/lwjgl-update.zip