Disabling Input in Window class?

[Juggers]

G'day all,
My name is Adrian Hofman and I'm developing a games engine in java as part of a team for Charles Sturt University in NSW Australia.

In short, I really just want to know if theres any way to disable the input stuff that appears to be going on in the Window.create() and Window.update() methods. It's conflicting with our current implementation, and we don't necessarily want to use the lwjgl input system.

Please help?

[Matzon]

you should be able to call Mouse.destroy() after the window has been created - else you can set either of these two to disable all input or just mouse input:
org.lwjgl.opengl.Display.noinput
org.lwjgl.opengl.Display.nomouse
that is - pass it like this:
java -cp <classpath> -Dorg.lwjgl.opengl.Display.nomouse=true MyApp

[Juggers]

Many thanks.
It is properly disabled when I use

org.lwjgl.opengl.Window.noinput

as opposed to

org.lwjgl.opengl.Display.noinput

as you suggested. Have I got an old version or something?

[jglover13]

You probably have the last actual release 0.9a.  The CVS source has merged the funtionality of Display and Window into the Display class.

[Juggers]

Ah yes, ok, thanks.

Just one final comment / critique (not trying to start a flame war): I think it is terrible OO design to have the Window (or now Display class) updating the Input system automatically. I have a lwjgl app that is updating the input system when I didnt even import the input package. Just imagine the rude shock I get when I find that just by initialising the lwjgl renderer, it is mucking up my current input implementation! The naming is misleading (what does Display have to do with input at all?), and nothing is mentioned in the JavaDocs. What im saying is, If I want to use the input system, I should have to explicitly say so in my code.

Just my two cents.

[Matzon]

The reason for this behaviour, is that 99.9% of all LWJGL users will make a Display, Mouse & Keyboard - We therefore decided to make it easy to use LWJGL for those 99.9%, and a "harder" for the remaining 0.1%.
However, I do agree that it can seem a bit odd that Display updates the Input stuff - it's just a lot easier to have it do it for you, since you're required to call Display.update() each tick anyway.

[elias]

I'm curious as to what exactly is interfering with your implementation? Per default, the mouse is not even grabbed, so that shouldn't interfere with your input system. One thing Mouse did was reset the cursor position to the middle of the window, but I have removed that in CVS. So what's left?

- elias

[Juggers]

Matzon: Thats a fine reason and perfectly justified, but it really should be explained in the javadocs for Display.update().

elias: Our current implementation uses JInput. All i know is,  when I called Display.create or Display.update, JInput couldn't poll the keyboard. Calling destroy() on each of the lwjgl input classes (Keyboard, Mouse, Controller) after the create() and update() calls didn't make any difference.