Plugin system / usability

Engines, Libraries and Tools JInput
#1

Hi
I’ve just had a reasonable length phone all with KevGlass, and one of the things we discussed is why JInput doesn’t seem to be used much. Kevs opinion is that one reason might be the plugin system that seems to cause so many people so much problem. I really like the flexability it provides, but can see how developers working on games don’t want to spend ages trying and failing to get it working.
One solution that we came up with I quite liked. The plugin loader in JInput is modified so if it finds no plugins, it loads (as a ClassLoader.getSystemResource call) a file, something like defaultPlugin. This file contains the string name of the plugin to load. There is a copy of this file in each plugin src folder, and on compiling JInput as well as the current files, one jar for each plugin, that contains not only the plugin code, but the jinput core jar contents and the jutils core contents and that file. So a dev on say windows only needs the jinput-dx8.jar and the native library. If more plugins on a particular platform are required, the dev will probably research the plugins system, which will still be the first approach take in the plugin loading code.
This leaves us with the flexability we have, but adds the simplisity that most games devs will be looking for. That combined with the new static Identifiers should make JInput a much more tempting option.

Comments/questions?

Endolf

#2

Also, I’d really like to validate the assumption that no one is using JInput… are there loads of people out there using it that are just very quiet?

Kev

#3

There are simply not enough bug reports for people to have actually tried it :slight_smile:

Endolf

#4

Well, I use it for mouse input, so thats 1 person at least :wink:

// Gregof

#5

I am using it for everything except mouse-style input devices in freefodder.dev.java.net . By default it uses an AWT based input system. That kills gamepad coolness but works everywhere. See the project page for details setting up JInput support in the game.

Did I mention that I had written my own version of the Linux based plugin for this game …

Bug report: Well, I am not sure but there seems to be a problem with JInput in combination with LWJGL on Windows: The keyboard does not return any poll data (always 0.0f). ATM I am not sure whether this might be a problem on my side. If someone has some spare time he/she might write a little app that controls something in a LWJGL window with JInput.

#6

That smells like the cooperative level setting in direct input. My guess is they are stealing the k/b. I might be able to sort that in jinput, but some interaction with the LWJGL guys might be needed. I’ll have to have a play at some point.
Can you raise that as an issue in the issue tracker?

Thanks

Endolf

#7

Which cooperative level is needed? In src/native/win32/org_lwjgl_input_Keyboard.cpp we have:

lpdiKeyboard->SetCooperativeLevel(getCurrentHWND(), DISCL_NONEXCLUSIVE | DISCL_FOREGROUND)

  • elias
#8

Hmm,
JInput is using NONEXCLUSIVE BACKGROUND, but as they are both non exclusive it shouldn’t be an issue. I think I need to get hold of LWJGL and test this. For force feedback stuff JInput tries to get exclusive mode, but still background. I have also remembered that the dummy window is needed for changing the cooprative mode. Also for getting things like joystick recalibration events etc.

Endolf

#9

I found the plugin system difficult to use. I see from the source that the PluginLoader class is supposed to find the native library in the same directory as the jar, but it didn’t seem to work. Worse, I didn’t get any sort of error or message or anything on standard output or standard error about the failure. (I think I may have been using an older version, since the 1.1.0 source appears to have fixed that.)

Now that I’ve looked at the source and discovered what I need to do, I’m not too happy with the steps required to use it. I sure wouldn’t expect users to set up such things.

I’d like to suggest making use of Java’s own “SPI Jar” specification:

http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service%20Provider

Pretty short read, isn’t it? It does everything the Plugins class does, and it’s a Sun standard that’s already used by New I/O, XML parsing, sound, Image I/O, and input methods. I’ve used it in projects both at work and at home, and it works quite well.

The easiest way to use it is with the javax.imageio.spi.ServiceRegistry class, which despite its package works with any SPI jar. (There’s also a sun.misc.Service class, but relying on an undocumented sun.* class is not wise.)

One thing the Plugins package does which SPI jar doesn’t do, is provide a ClassLoader that can find a native library which is simply in the same directory as a jar file. While I understand the reason for that functionality, I can’t help feeling like that’s the job of the installation process: put jinput.jar and linux-jinput.jar (or whatever) in ${java.home}/lib/ext, put the native library in ${java.home}/lib/${os.arch}, and if we’re using the SPI jar approach, there’s no more setup to do. No system properties, no extra classpath. Developers would still use ControllerEnvironment.getDefaultEnvironment().

#10

HI,

So if you guys want to replace the plug-in system, Im not offended even though I’m its origianl author. It was actually a repalcement for the ORIGINAL plug-in system Mike Martak wrote, which you guys never saw, and which required manually modifying a config file.

Do whatever works best for you. Not every idea Ive ever had is a winner and the great thing about open soruce is you get many minds on a problem.

Let me explain the reasoing though behind the support for a nested file structure in the controller directory and the association of the jar to the plug in isharing the same folder. Thsi was done to solve the problem when two different independant plug-in developers call their dll “input.dll” :slight_smile: If they all had to live in the same folder then you wouls have an unresolvable incompatability. The sub-folder system was designed to solve for that.

Now, maybe I was over-engineering, but I wanted to at last make sure everyone udnerstood the original motivation.

Persoanlly, I rather dislike the SPI system. I like “drop it in place and forget it” plug in systems and find manifest munging an annoyance. But thats just personal taste :slight_smile:

#11

[quote]I found the plugin system difficult to use. I see from the source that the PluginLoader class is supposed to find the native library in the same directory as the jar,
[/quote]
btw. This worked in original release. AFAIK it still does. If you have a good test case that shows that it doesnt maybe you shouls zip it up anmd send it to me so I can look at it.