JInput not working correctly in applets

[ryanheise]

I am developing an applet that will use JInput if it is present (in the user's "lib/ext" directory), or will otherwise fall back to standard java.awt techniques.

Here is the problem:

When JInput is detected on LINUX, keyboard events are detected fine, but mouse events are not.
When JInput is detected on WINDOWS, mouse events are detected fine, but keyboard events are not.

My game depends on keyboard input, so the second problem is worse for me.

Here is the code I'm using to see what events are being detected by JInput:

1   2   3   4   5   6   7   8   9   10   11   12

Controller[] controllers = ControllerEnvironment.getDefaultEnvironment().getControllers(); Event event = new Event(); while (...) {     for (int i = 0; i < controllers.length; i++)     {         controllers[i].poll();         EventQueue queue = controllers[i].getEventQueue();         while(queue.getNextEvent(event))             System.out.println(event);     } }

By printing out the array of controllers, I can also verify that a keyboard controller is found by JInput in both WINDOWS and LINUX, but it just doesn't do anything in WINDOWS.

I noticed that a similar problem was described in the thread "JInput and Java 1.6.0_10" although this might be a different problem because in my case there is evidence that things are at least "partially" working.

Is there a solution that doesn't fundamentally change the delivery approach of an applet loading JInput from lib/ext?

My LINUX Java version is 1.6.0_10-beta-b14 (but I unfortunately don't have the WINDOWS Java version at hand).

Thank you

[endolf]

Hi

If the mouse or keyboard is successfully detected, then the loading from lib/ext isn't the issue. I don't know why it might happen, but have you tried just getting one event in the loop instead of emptying the queue, it sounds like one device is keeping the code in the inner part of the loop.

HTH

Endolf

[ryanheise]

If I print "Checking for events" just before the inner loop, the program shows that the outer loop is repeating regularly, so this is not it.

Also, if I use keyboard.isKeyDown(...) instead of events, this method always returns false on WINDOWS.

Were you able to reproduce the problem with the code I provided?

Games published by our own members! Check 'em out!

[endolf]

Running your code I get no events at all.

I'm out for the day, but I hope to have a look at this this evening.

Endolf

[endolf]

If I stick a jframe in there it works.

JInput *should* work from the console, not sure whats changed. I'll look later.

Endolf

[ryanheise]

I'm also not running this code from a console, for me, I used it in an applet.

By the way, another option is to try the game to see if you get the same problem with my code: http://hi-games.net/tessellate-t,lt,O,d/

The polled keys are: Z, X, Arrow keys and Space. You can press F9 *after* the game has started to see if JInput was detected by the applet (if it says "Direct", then it was detected).

When JInput is in lib/ext, keyboard input works on Linux, but not on Windows. When JInput is not in lib/ext, it works on all platforms using standard AWT events.

Thanks for looking into the problem.

[h3ckboy]

I looked at the game, the keys read fine, but I got no direct anywhere I could see.

[endolf]

I created a resource loader for JInput in applets a little while ago that downloads the native files to the users machine. You can try it here. That seems to work using events. I created a test using your code and it works perfectly using that method.

With no window at all, I get no events reported, this is because JInput on windows by default uses raw input for keyboard/mice and directx for everything else, but this method requires the application to have focus. If you provide the properties

1	-Djinput.useDefaultPlugin=false -Djinput.plugins=net.java.games.input.DirectInputEnvironmentPlugin

it will use directx only and will read the keyboard/mouse. The down side is that multiple mice/keyboards are not supported.

HTH

Endolf

[ryanheise]

Hi endolf, I saw your resource loader before actually. It's really cool, nice job! And, it works. But... as I mentioned, I would like not to change my delivery mechanism.

Could it be that the reason your applet works has nothing to do with the resource loader (and would work just as well with lib/ext), and has more to do with the fact that your applet creates JFrames? Can you make a normal applet that runs entirely inside of the applet component and can poll the keyboard using JInput? This would correspond more to what I am hoping to achieve.

If I set the plugin to directx as you suggested, it is then possible to poll the keyboard from within the applet. This is great, except that in order to set the various properties, the applet must be signed, and this changes my delivery mechanism. I do not want users to have to click a button to trust this applet. Also, you mentioned that the directx plugin does not support multiple keyboards and mice. This is ok, but how about joysticks? I will eventually want to support a joystick inside the applet.

Ideally, JInput could be fixed to work inside an applet by default. Is this possible? Thanks again.

[endolf]

I ran your own code within an applet, so no JFrame, and that worked fine using the jinput resource loader.
Using directx only will support multiple joysticks.
JInput will not work without signing the applet, there are too many calls that are restricted. Most of them are to do with checking the configuration, but loading the dll/so/jnilib will also not work inside an unsigned applet.

Endolf

Games published by our own members! Check 'em out!

[ryanheise]

If the JInput jar is placed into lib/ext, isn't it automatically granted the privileges to access whatever it needs to access?

[cylab]

If the JInput jar is placed into lib/ext, isn't it automatically granted the privileges to access whatever it needs to access?

Don't EVER put sumething into lib/ext, if don't know exactly what you are doing. There are multiple problems with this approach:

1. You may break webstart code and applets using a
    different version of jinput than you

2. The dlls/natives won't get loaded from lib/ext, so you have
    to put them to some system library path

3. You will have to tell your users to put the files to
    various (delecate) directories on their system
    (you can't acces the harddisk from a non-signed applet)

4. The applet still won't have access to native code (dlls)
    when unsigned. You could completely circumvent applet
    security otherwise (using win32 native file access for
    example to spread viruses)

5. You would encourage ALL YOUR USERS to get problem no. 1!!!

[ryanheise]

Is the JInput API really unstable? I would hope that if major, incompatible changes were ever made to the JInput API, then it would be given a new package name so as not to clash with the previous version. If there is no goal to do this, then I suppose (1) is a valid point.

However are you sure about (2) and (4)? I have verified that the native libraries do get loaded from lib/ext, even from an unsigned applet.

[cylab]

However are you sure about (2) and (4)? I have verified that the native libraries do get loaded from lib/ext, even from an unsigned applet.

I am not. I just made an "educated guess", so if you verified this works, I don't seem to be as educated as I thought

[endolf]

If there were major changes that were not compatable with the current version of JInput, it would get a new version number, not a name. More importantly, security changes or other bugs would have to be manually updates as per point 1.
I would have thought that if signed applet dialogs were a worry, point 3 would be an issue.

On the other hand, I would like to get this working for you. I have 3 days off this week, not all of it is free time, but I hope to get a chance to look at doing things from lib/ext

HTH

Endolf