New version of Joystick Driver for Java released

[blackdiamond]

Hopefully this is the right forum to post this announcement.

I’ve occasionally been working on a Java Joystick driver interface for a few years now. I released my open source code in 2000, and I figure that it’s been working pretty well for me and a few other people since then. I was hoping to get some feedback on the project in order to improve it a bit more.

The Java joystick driver currently works on Windows and Linux, and you can download a copy from here.

Joystick Driver for Java

Comments and code contributions are welcome.

[elias]

A joystick driver… are you by any chance interested in putting esp. the linux version into lwjgl? Currently, support for both gamepad and joystick is missing from lwjgl.

• elias

[princec]

Well, it is and it isn’t… maybe Brian will have a look at them both and see which one’s best for our purposes.

Cas

[elias]

Sorry, I meant is missing from linux lwjgl. Apologies.

[Matzon]

well our joystick implementation works fine, in windows…
a couple of things:
it isn’t based on direct x on windows - this may or may not be a turnoff. I just remember not going with the win32 joystick methods because I read something about analogue devices could take up to 50 ms to poll. I didn’t actually test it, nor did I check if DX has the same limitation.

AFAIK the joy* methods in win32 are deprecated and they do not allow for all features of a joystick.

The artistic license isn’t compatible with BSD/MIT - the author would have to rerelease it for us as BSD.

I plan on doing a joystick with forcefeed back and all that neat stuff (not nescecarilly in the lwjgl space, since we want to keep it lean and mean, but some other OSS project…). Going with the above solution would render my efforts nil.

So my call would be to keep the one we have for win32 and keep the interface - and use this joystick implementation as a reference of HOW to do it.

How does one do FF back on linux?

[elias]

Don’t worry, I think the win32 implementation of the Joystick is fine! It’s the linux joystick handling code I’d want to integrate.

I have no idea how force feedback is done in linux, in fact I have no idea how joystick at all is done in linux. And that’s why I was interested in this code.

• elias

[Matzon]

uh - one small thing that IS better than the lwjgl implementation, is that we only support 1 controller.

[Matzon]

yeah - but you’d still have to make some changes to fit the lwjgl controller interface

[blackdiamond]

Hi All

Where does it say that the joy* methods are deprecated? I looked all over the msdn.microsoft.com site, and I didn’t see that mentioned anywhere, especially on the documentation of those functions. I only see that DirectInput superscedes the joy* API, but that doesn’t mean that it’s deprecated.

From my past experience, COM and JNI are slow compared to using C/C++ directly. That is one reason why I’m using the C API. The C API is also easier.

I also don’t see how the BSD license is incompatible with the artistic license. I guess that is why I’m not a lawyer I know that I don’t want my project with the GPL or LGPL license. I wanted the source code freely available to anyone without any restrictions on modification or incorporation of the source code as long as they gave the original author(s) credit. I don’t consider giving credit that much of a restriction.

If someone can explain to me what is incompatible between the BSD and artistic licenses, I might change the license.

I’m not sure how to do force feedback on Linux either, but I do know that the Microsoft way of force feedback is highly platform dependent. Last time I looked at force feedback on Windows, it looked very difficult and it seemed that it required extra files to specify the wave signal to the joystick. So I focused most of my attention to making the joystick interface simple, flexible and fast. The project works with game pads and traditional joysticks, and I’ve heard that it’s been used with HIDs with analog buttons (it had 20 axes and required a small modification to the code).

Yes traditionally polling can be slower than event callbacks, but from my experience of navigating some VRML models in Java I couldn’t tell the difference in speed. In Java the biggest speed killer has almost always been the garbage collector. Of course speed differences are all hearsay without a performance test to show the difference

I believe that the usage model in Joystick Driver for Java is significantly different from lwjgl, and it would take plenty of work to integrate it into lwjgl

[Matzon]

[quote] If someone can explain to me what is incompatible between the BSD and artistic licenses, I might change the license.
[/quote]
simple, paragraph 3 & 4:

[quote]3. You may otherwise modify your copy of this Package in any way, provided
that you insert a prominent notice in each changed file stating how and when
you changed that file, and provided that you do at least ONE of the following:
a) place your modifications in the Public Domain or otherwise make them Freely
Available, such as by posting said modifications to Usenet or an equivalent
medium, or placing the modifications on a major archive site, or by allowing
the Copyright Holder to include your modifications in the Standard Version of
the Package.
b) use the modified Package only within your corporation or organization.
c) rename any non-standard executables so the names do not conflict with
standard executables, which must also be provided, and provide a separate
manual page for each non-standard executable that clearly documents how it
differs from the Standard Version.
d) make other distribution arrangements with the Copyright Holder.
[/quote]

4. You may distribute the programs of this Package in object code or
   executable form, provided that you do at least ONE of the following:
   a) distribute a Standard Version of the executables and library files,
   together with instructions (in the manual page or equivalent) on where to get
   the Standard Version.
   b) accompany the distribution with the machine-readable source of the Package
   with your modifications.
   c) accompany any non-standard executables with their corresponding Standard
   Version executables, giving the non-standard executables non-standard names,
   and clearly documenting the differences in manual pages (or equivalent),
   together with instructions on where to get the Standard Version.
   d) make other distribution arrangements with the Copyright Holder.

BSD:

[quote] * Redistribution and use in source and binary forms, with or without

• modification, are permitted provided that the following conditions are
• met:
• • Redistributions of source code must retain the above copyright
• notice, this list of conditions and the following disclaimer.
• • Redistributions in binary form must reproduce the above copyright
• notice, this list of conditions and the following disclaimer in the
• documentation and/or other materials provided with the distribution.
• • Neither the name of ‘Light Weight Java Game Library’ nor the names of
• its contributors may be used to endorse or promote products derived
• from this software without specific prior written permission.
  [/quote]
  so with the artistic license you are often required to publish your changes - with BSD license (and deriviative) you can do whatever you want, as long as you retain the copyright, and do not use names of its creators/contributors to endorse or promote products derived

[Matzon]

[quote] Where does it say that the joy* methods are deprecated? I looked all over the msdn.microsoft.com site, and I didn’t see that mentioned anywhere, especially on the documentation of those functions. I only see that DirectInput superscedes the joy* API, but that doesn’t mean that it’s deprecated.
[/quote]
yeah - you’re absolutely right - my bad.

[quote] From my past experience, COM and JNI are slow compared to using C/C++ directly. That is one reason why I’m using the C API. The C API is also easier.
[/quote]
yeah - I tend to agree - however given that the joy* methods are not implemented using DX, they might be slower - I have no benchmarks to prove this, nor to disapprove it though…

[elias]

… And as Matzon hinted to me - force feedback might be alot easier with the directx interface. Newer vendors probably don’t support other ways of wiggling the stick anymore.

• elias

[Matzon]

Did some benchmarking. ;D
I ran a test where I poll each joystick implementation 500000 times. I benchmarked only polling the device, and another where the device is polled and the relevant fields are updated:

code used for joystick test:

package com.centralnexus.test;

import com.centralnexus.input.*;

public class JoystickPollBenchmark {

  public JoystickPollBenchmark() {
  }

  public void executeTest(int count) {
    Joystick joy = null;
    try {
      joy = Joystick.createInstance();
    } catch (Exception e) {
                  e.printStackTrace();
            }
    
    System.out.println("Polling " + count + " times");
    long starttime = System.currentTimeMillis();
    for(int i=0; i<count; i++) {
      joy.poll();
    }
    System.out.println("Total time used: " + (System.currentTimeMillis() - starttime) + " ms");
    System.out.println("Average time for poll:" + ((float)(System.currentTimeMillis() - starttime)/count) + "  ms");
  }

  public static void main(String[] args) {
    JoystickPollBenchmark jpbm = new JoystickPollBenchmark();
    jpbm.executeTest(Integer.parseInt(args[0]));
  }
}

code used for lwjgl test:

package org.lwjgl.test.input;

import org.lwjgl.input.Controller;

public class ControllerPollBenchmark {

      public ControllerPollBenchmark() {
      }

      public void executeTest(int count) {
            try {
                  Controller.create();
            } catch (Exception e) {
                  e.printStackTrace();
                  return;
            }
    
    System.out.println("Polling " + count + " times");
    long starttime = System.currentTimeMillis();
    for(int i=0; i<count; i++) {
      Controller.poll();
    }
    System.out.println("Total time used: " + (System.currentTimeMillis() - starttime) + " ms");
    System.out.println("Average time for poll:" + ((float)(System.currentTimeMillis() - starttime)/count) + "  ms");
    
    Controller.destroy();
      }

      public static void main(String[] args) {
            ControllerPollBenchmark cpbm = new ControllerPollBenchmark();
            cpbm.executeTest(Integer.parseInt(args[0]));
      }
}

The result is pretty close, but it seems that lwjgl is a bit faster. All tests were run three times for each test/implementation and the fastest picked.

`
=================== POLL =======================
joystick:
Polling 500000 times
Total time used: 17745 ms
Average time for poll:0.03549 ms

lwjgl:
Polling 500000 times
Total time used: 14531 ms
Average time for poll:0.029062 ms

================ READ VALUES ===================
joystick:
Polling 500000 times
Total time used: 20860 ms
Average time for poll:0.04172 ms

lwjgl:
Polling 500000 times
Total time used: 19998 ms
Average time for poll:0.039996 ms
`

[dug]

Hi,
I want to add support for force feedback joysticks and steering wheels (hopefully both) for a simulation done in java.

Is this an appropriate thing to add to the jxinput, lwjgl, or javajoystick projects?

One thing that is confusing me right now is about DirectX vs. Immersion. DirectInput code samples don’t recognize Immersion-compatible devices and vice versa. It would be nice if I could make the simulation work on Macs, too, which now support Immersion force feedback. But I think most everyone uses DirectInput now. I haven’t been able to see the ForceFeedback code on the mac-side yet.

A third alternative I was wondering about, does SDL support force feedback devices yet? I don’t think it does, but if it does then maybe the java interface to SDL (JSDL) would be another alternative.

[blackdiamond]

javajoystick can’t handle force feedback, and if it ever supported force feedback, it would have to use DirectInput. I’m not aware of any other way to do force feedback on Windows.

I’ve heard rumors about force feedback on the Mac, but I haven’t seen anything concrete. The Apple documentation about joysticks (HIDs) on the Mac still says that, ‘it’s a work in progress.’

It’s interesting to see the license differences. I’ll have to meditate about changing the license :-/

It’s interesting to see the joystick speed differences. There isn’t much of a difference, but there is a small difference. I know that JDKs sometimes take a while to warm up for performance testing, but you do make a good point. I’m presuming that a normal joystick was used. The polling works differently when it detects that more than the generic 3 axes are used, which causes it to get significantly slower. It could also be due to how the function is declared (static verses “virtual”). Oh well.

I’m personally happier about the javajoystick model though. I like the ability to have more than one joystick in use, the ability to add Java style listeners to a joystick, and the ability to pick and choose which joystick is used.

[Matzon]

[quote] It’s interesting to see the joystick speed differences. There isn’t much of a difference, but there is a small difference. I know that JDKs sometimes take a while to warm up for performance testing, but you do make a good point. I’m presuming that a normal joystick was used. The polling works differently when it detects that more than the generic 3 axes are used, which causes it to get significantly slower. It could also be due to how the function is declared (static verses “virtual”). Oh well.
[/quote]
The benchmark was done using a saitek generic 4 button gamepad.
I was actually a bit surprised about the difference - I had a feeling that the winmm library had been rewritten to use DX - doesn’t seem so.

[quote] I’m personally happier about the javajoystick model though. I like the ability to have more than one joystick in use, the ability to add Java style listeners to a joystick, and the ability to pick and choose which joystick is used.
[/quote]
And that is exactly what differs by lwjgl. lwjgl is about enabling a technology - not to wrap the technology in classes that make them “nicer” and more easy to use.

We might write utility classes for listeners and such - but they’re not our primary objective.

As for supporting n controllers - this is on our list… - it probably won’t make it for 1.0. There aren’t many out there that use two controllers at the same time…