here some starter code :)

Just thought this may help some people get started with the cool JInput action:

import net.java.games.input.*;

public class KeyboardTest {
  Keyboard kb = null;

  public KeyboardTest() {
    ControllerEnvironment ce = ControllerEnvironment.getDefaultEnvironment();
    Controller[] cont = ce.getControllers();

    System.out.println("cont: " + cont.length);
     for (int i = 0; i < cont.length; i++) {
       if (cont[i].getType() == cont[i].getType().KEYBOARD) {
         kb = (Keyboard) cont[i];
      }
    }
    
    for(int i = 0; i < 100000; i++) {
      keyboardupdate();
    }
    
    System.out.println("done...");
  }

  public void keyboardupdate() {
    kb.poll();
    Axis[] ax = kb.getAxes();
    for (int x = 0; x < ax.length; x++) {
      float num = ax[x].getPollData();
      if (num != ax[x].getDeadZone()) {
        if (ax[x].getName().equalsIgnoreCase("key 110")) {
          System.out.println("up arrow");
        }
      }
    }
  }
}

Sorry !!..

I run the code in IDE but it can’t found any “Controller”.
Please tell me what’s wrong?

You don’t have jinput.jar installed and you don’t have the native jinput plugin installed.

@gregorypierce:
Can you explain the deadzone thing?

I was able to build a small app using jinput that uses the keyboard and I only checked for absolute values of kb.getPollData().

for digital devices i thought it would mean:
1.0f => pressed
0.0f => unpressed

unfornately jinput’s apidoc is lacking much details.

Hi
The deadzone is used for joysticks and is the amount by which the joystick axis value can change even if the joystick is held still. If you get a joystick axis value, and it doesn’t move by more than the deadzone amount, you pretend it hasn’t moved, if it moves by more than the deadzone amount you accept the new position, if you calibrate a joystick under windows where you have the gui to look at axis positions, you will notice it ‘twitching’ about a point, the deadzone is so that the twitching doesn’t show.

If that makes sense :slight_smile:

Cheers

Endolf

Now until i manage to find the JInput docs, i’m working blind - but I tried this example code yet JInput seems to hit a null pointer deep within itself somewhere:

Importing preferences from file: ./config.xml
java.lang.NullPointerException
      at net.java.games.util.plugins.Plugins.scanPlugins(Plugins.java:78)
      at net.java.games.util.plugins.Plugins.<init>(Plugins.java:73)
      at net.java.games.input.DefaultControllerEnvironment.scanControllersAt(DefaultControllerEnvironment.java:170)
      at net.java.games.input.DefaultControllerEnvironment.scanControllers(DefaultControllerEnvironment.java:162)
      at net.java.games.input.DefaultControllerEnvironment.access$000(DefaultControllerEnvironment.java:57)
      at net.java.games.input.DefaultControllerEnvironment$1.run(DefaultControllerEnvironment.java:108)
      at java.security.AccessController.doPrivileged(Native Method)
      at net.java.games.input.DefaultControllerEnvironment.getControllers(DefaultControllerEnvironment.java:106)
      at com.vecript.core.Vecript.testJInput(Vecript.java:128)
      at com.vecript.core.Vecript.<init>(Vecript.java:121)
      at com.vecript.core.Vecript.<clinit>(Vecript.java:43)
java.lang.NullPointerException
      at net.java.games.util.plugins.Plugins.scanPlugins(Plugins.java:78)
      at net.java.games.util.plugins.Plugins.<init>(Plugins.java:73)
      at net.java.games.input.DefaultControllerEnvironment.scanControllersAt(DefaultControllerEnvironment.java:170)
      at net.java.games.input.DefaultControllerEnvironment.scanControllers(DefaultControllerEnvironment.java:164)
      at net.java.games.input.DefaultControllerEnvironment.access$000(DefaultControllerEnvironment.java:57)
      at net.java.games.input.DefaultControllerEnvironment$1.run(DefaultControllerEnvironment.java:108)
      at java.security.AccessController.doPrivileged(Native Method)
      at net.java.games.input.DefaultControllerEnvironment.getControllers(DefaultControllerEnvironment.java:106)
      at com.vecript.core.Vecript.testJInput(Vecript.java:128)
      at com.vecript.core.Vecript.<init>(Vecript.java:121)
      at com.vecript.core.Vecript.<clinit>(Vecript.java:43)
cont: 0
java.lang.ExceptionInInitializerError
Caused by: java.lang.NullPointerException
      at com.vecript.core.Vecript.keyboardUpdate(Vecript.java:152)
      at com.vecript.core.Vecript.testJInput(Vecript.java:143)
      at com.vecript.core.Vecript.<init>(Vecript.java:121)
      at com.vecript.core.Vecript.<clinit>(Vecript.java:43)
Exception in thread "main" 

I’m using the latest nightly build, is this known to be stable or should i be trying an older version? How stable is JInput at this time (both in terms of crashes and in terms of API changes)?

Any help appreciated.

Hi
It looks liek there are two problems there, the null pointer is one, but the other is the fact that its using the DefaultEnvironmentPlugin, which suggests you don’t have the native part in you java library path.

HTH

Endolf

So how do i fix the DefaultEnvironmentPlugin to something else? I’ve currently got: jutils.jar, jinput.jar, dxinput.jar in the classpath, and dxinput.dll in the path. I’m surprised theres no jinput.dll like Jogl and Joal, but theres nothing else lying around in the binarys .zip file.

try java -Djava.library.path=

also, the dxinput.jar needs to be in a directory called controller, relative to where ever you are running from.

I managed to get this working, turns out i was still using the early unofficial build of the Jogl/Joal/JInput (the jsr138.jar file) which was the reason beind the null pointer exception. A quick switch to the latest Jogl and JInput fixed this problem.

I also needed to change the dxinput.jar to a controller dir as you mentioned. I’m not too happy with this, it mucks up my carefully crafted directory structure >:( but it will do for now. I assume that JInput is doing some sort of fancy dynamic loading and expects it to be in this location? Is is possible to alter this behaviour?

Edit: Ah I see the PluginClassLoader scans a directory to load the plugin classes. The ‘controller’ string sits hardcoded in the source, but i’m unsure how it could be made to be externally settable…? Unless it could be passed in as an argument to the api somewhere…

Hi
It would make sense to me to see it as a system property, something like jinput.controllerPluginPath, which can be set either in a proeprties file or with the -D flag. defaulted to controller of course

Cheers

Endolf

[quote]try java -Djava.library.path=

also, the dxinput.jar needs to be in a directory called controller, relative to where ever you are running from.
[/quote]
Or it can be in a directory called controller in the right palce in your Java SDK instllation (I believe its lib\ext but I need to look to make sure.)

Isn’t this documented? I thought it was.

Doing an over-ride with a -D aught to be easy.

(I’d still keep the set palces as defaults if there is no over-ride property defined.)

I’m up to my waders in alligatros on server code right now, does someone else want to make that change? Should be all of about 3 lines of code…

Hi
I agree about how simple it should be, unless it’s done when I get up (it’s just gone midnight here) I will do it.

Endolf

Thanks again End. You’re a real trooper :slight_smile:

Hi
Forgot yesterday, but just checked in the change,

-Djinput.controllerPluginPath=<location of plugin>

will override the plugin path that is scanned for the plugin. if it’s not supplied it will default to controller like before.

Endolf

im not sure what happened (perhaps i triggered a debug mode in the osx install? but after running just those simple lines of code, my computer has been spitting out millions of lines of “Queue getNextEvent return value :0”. I killed the process about 4 mins ago, and its still going. Writing that much is bound to kill any 3d app… is there a way to turn this mode off?

although jinput version number is 1.1 and contains beta in its name it is more alpha. diagnostic messages are spilled out on every platform. :frowning:

at least you are trying the stuff and comment here. IMHO I think a lot of people just lose interest after realizing that Jinput isn’t that shiny now.

if you want to participate feel free to enter the suggestion’s thread: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jinput;action=display;num=1087176216