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.

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.

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

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

simple, paragraph 3 & 4:

Quote

3. You may otherwise modify your copy of this Package in any way, providedthat you insert a prominent notice in each changed file stating how and whenyou 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 FreelyAvailable, such as by posting said modifications to Usenet or an equivalentmedium, or placing the modifications on a major archive site, or by allowingthe Copyright Holder to include your modifications in the Standard Version ofthe Package.b) use the modified Package only within your corporation or organization.c) rename any non-standard executables so the names do not conflict withstandard executables, which must also be provided, and provide a separatemanual page for each non-standard executable that clearly documents how itdiffers 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 orexecutable 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 getthe Standard Version.b) accompany the distribution with the machine-readable source of the Packagewith your modifications.c) accompany any non-standard executables with their corresponding StandardVersion 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.

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

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.

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.

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....

Did some benchmarking. 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:

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.

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.

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.

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.

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...

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org