Hello!
I have upgraded a game client to the libs V1.0beta 3. The game has been running smoothly on V0.98 for about a year. Now a problem has occurred for about 3 out of maybe 100 users that the application no longer responds to the keyboard. To be exact, typed text is no longer accepted.
Question: Was there a major chane in the way keyboard input is processed?
since 0.98 there has been some input changes.
How are you using the keyboard ?
The keyboard is polled about 20 times per second by the following code:
Keyboard.next();
int key = Keyboard.getEventKey();
// react only to pressed keys
if( Keyboard.getEventKeyState() )
{
// still holding the same old key
if( lastKeyDown == key
&& System.currentTimeMillis() < lastKeyTime )
{
return;
}
lastKeyDown = key;
lastKeyTime = Long.MAX_VALUE;
switch( key )
{
case Keyboard.KEY_F12:
Game.getPeople().toggleNameMode();
break;
...
For those people experiencing the problem, the switch() is never called. For most people it works fine.
Before this code, there is a call to
Keyboard.isKeyDown( Keyyboard.KEY_ESCAPE ) ) for quitting the application. That always seems to work.
* BUMP *
Has anybody any idea what the problem might be?
Anything wrong with the way I am calling those methods?
We still have the problem, that keyboard works for most users, but for some their input is ingored.
Keyboard seems to work fine for me, heres some code on how it do it might help.
if (Keyboard.next()) {
switch (Keyboard.getEventKey()) {
case Keyboard.KEY_E:
if (Keyboard.getEventKeyState()) {
emboss = !emboss;
}
break;
case Keyboard.KEY_M:
if (Keyboard.getEventKeyState()) {
useMultitexture = ((!useMultitexture) && multitextureSupported);
}
break;
case Keyboard.KEY_B:
if (Keyboard.getEventKeyState()) {
bumps = !bumps;
}
break;
case Keyboard.KEY_F:
if (Keyboard.getEventKeyState()) {
filter++;
filter%=3;
}
break;
}
}
It appears that all users with the problem are using Windows 98.
Has anybody observed any problems with that version and LWJGL?
I haven't. Unfortunately I dont have access to a win9x box, so a bit hard to find the cause
Clarification. I have learned that we have 7 users with this problem and all of them seem to have Windows 98 SE. The regular Win98 seems to work.
Also, the problem seems to be with regular keys. F-Keys and Enter do work, just all regularly typed keys are not coming through. This looks like it was not a problem with my code but with LWJGL under Win98.
Anybody out there who can confirm or disprove this theory?
I reworked my code a little according to the code sample posted and removed the time-dependent code. But no change, typed letters seem not to work on Windows 98 SE.
have you tried with debug turned on(http://lwjgl.org/wiki/doku.php/lwjgl/tutorials/usingdebug)?
what version of directx is installed?
I comitted a possible fix, please test these pre-built libraries (as I have no access to any win9x machines):
http://download.oddlabs.com/elias/lwjgl.jar
http://download.oddlabs.com/elias/lwjgl.dll
- elias
Nope, I haven't. I don't have a Win98 SE system either, otherwise I'd provide much better information. :-)
The problem has occurred at 7 of our players machines. It is reproducible there, but due to the nature of an online game I can't get there for debugging.
What was the nature of the changes in keyboard input between 0.98 and 1.0?
Several changes, but mostly moving stuff from native to java which should be without any side effects, but you never know of course. The fix I comitted was a reversal of the removal of the usage of ToAscii for win9x machines. It seems that the alternative, ToUnicode, was only available for NT based OSes.
- elias
Quote from: "elias"Several changes, but mostly moving stuff from native to java which should be without any side effects, but you never know of course. The fix I comitted was a reversal of the removal of the usage of ToAscii for win9x machines. It seems that the alternative, ToUnicode, was only available for NT based OSes.
Ist it possible that this change is related to the problem? I think there are two circumstances that may be hinting at this:
- only Windows 98 SE machines are concerned
- only letters (which would go through this conversion) are disappearing, enter, function and cursor keys are working
Hmm, by closer inspection it might not be the problem after all - I see you're not using the translated characters, but raw keys. Then I'm not sure what could cause this - the only bigger change I can recall is the dinput3->dinput8 conversion (with fallback to dinput3 if dinput8 is unavailable). What version of directx are your users running?
- elias
Another thing - are you using JInput or similar, accessing directinput outside of LWJGL?
- elias
So far, I have precise information from two users having the problem:
Win 98 4.10 build 2222
DirectX 9.0c 4.09.0000.0904
Win 98 4.10 build 2222 A
4.09.0000.0904 (DirectX 9.0c)
All users did not change their system configuration except for updating my client software. My client did not contain any changes in the keyboard code, just the upgrade of the lwjgl libs.
Ok, they should work fine with the directinput8 input methods of LWJGL, so I'm out of ideas, really :/ (I assume you've already tried -Dorg.lwjgl.util.Debug=true and checking any debug output to see if there's anything suspicious there) If you want to move forward on this issue, I see two possibilities:
1. Do a binary search on the LWJGL version, that is, try the LWJGL version "1.0beta", and if that works, "1.0beta2", until we know which version that broke input for you.
2. Go with my hunch and disable the directinput8 path:
Change:
private static WindowsDirectInput createDirectInput() throws LWJGLException {
try {
return new WindowsDirectInput8(getDllInstance());
} catch (LWJGLException e) {
LWJGLUtil.log("Failed to create DirectInput 8 interface, falling back to DirectInput 3");
return new WindowsDirectInput3(getDllInstance());
}
}
in WindowsDisplay.java to:
private static WindowsDirectInput createDirectInput() throws LWJGLException {
return new WindowsDirectInput3(getDllInstance());
}
I have gotten some players to run a client with the debug flag enabled. Here is the result:
Illarion Client V0.98astarted Sat Oct 21 00:04:28 BST 2006
Initial mode: 1152 x 864 x 32 @0Hz
Found 30 displaymodes
Removed 0 duplicate displaymodes
Found mouse object: X-axis
Found mouse object: Y-axis
Found mouse object: Wheel
Found mouse object: Button 0
Found mouse object: Button 1
Found mouse object: Button 2
Mouse buffer overflowed
That is all, nothing else. And it is the same for every player.
Can it be the mousebuffer message? But the mouse is working for all of them.
Is there anything I can do about the mouse buffer?
The mouse buffer message is normal, and can be ignored. I did a memory corruption fix (in SVN), which could theoretically cause all sorts of trouble. But it's very hard to trigger, so I'm not sure you are affected by this. Other than trying the current SVN version, I need you to do the binary search of the offending version and/or the dinput8->dinput3 fallback.
- elias
Ok, we have started the binary search. For a start I have reverted back to LWJGL 0.98. I have the first positive feedback that keyboard input works again with that version of the lib and the latest version of my code. I'm waiting for the feedback of some more people, then I am going to step up through the versions. Any bets which one it is going to be? :-)
I'm guessing the version that introduced dinput8 support. Not sure if that was introduced in beta 3 or beta2.
- elias
I have moved to LWJGL 0.99 now. While the I/O works, for one player an unrelated problem has popped up. This is the log:
Initial mode: 1024 x 768 x 32 @0Hz
Exception occurred while querying registry: org.lwjgl.LWJGLException: Failed to open registry key
java.lang.NullPointerException
at org.lwjgl.opengl.Win32Display.nGetVersion(Native Method)
at org.lwjgl.opengl.Win32Display.getVersion(Win32Display.java:83)
at org.lwjgl.opengl.Display.getVersion(Display.java:826)
Any hint what's the problem here?
It's a known bug with Display.getVersion()/getAdapter(), which is fixed (possibly only in SVN). You can work around it by catching the NPE and treating the value as null. Sorry for the inconvenience.
- elias
Can you tell me what causes this problem? Two players are having this problem, but when I start the same version, updated in the same manner, it runs fine.
It's caused by a failure to read the registry key with the display adapter information. When it succeeds (on your machine) the bug is not triggered. The fix was a simple null check.
- elias
We have nailed down the problem. Everything is working fine up to V1.0 beta 1.
After update to V1.0 beta2 the keyboard is no longer working properly for Win 98 SE. F-keys, cursor keys and Alt-Shift-Ctrl do work, but letters do not.
I think your guess was correct. Now what can we do to solve the problem?
Excellent. A quick check reveals that beta2 was the release that introduced dinput8 support (for jinput compatibility). The release also moved the input stuff from native to java. If my guess is correct, we'll need to disable dinput8 and test without it. Can you svn checkout the beta3 version (we fumbled the beta2 tag in SVN):
https://svn.sourceforge.net/svnroot/java-game-lib/tags/lwjgl1.0beta3
or the latest HEAD:
https://svn.sourceforge.net/svnroot/java-game-lib/trunk/LWJGL
and change src/jav/org/lwjgl/WindowsDisplay.java:
from:
static WindowsDirectInput createDirectInput() throws LWJGLException {
try {
return new WindowsDirectInput8(getDllInstance());
} catch (LWJGLException e) {
LWJGLUtil.log("Failed to create DirectInput 8 interface, falling back to DirectInput 3");
return new WindowsDirectInput3(getDllInstance());
}
}
to
static WindowsDirectInput createDirectInput() throws LWJGLException {
LWJGLUtil.log("Falling back to DirectInput 3");
return new WindowsDirectInput3(getDllInstance());
}
thus only using dinput3 everywhere. It should be equivalent to dinput8, except that jinput will not work with LWJGL. Rebuild lwjgl.jar and re-use the lwjgl.dll from beta3 (or one built freshly off HEAD).
If that fix works, I'll make sure dinput3 is always used on win9x machines.
Please reply if you have any doubts, or reach me on msn at: elias_naurAThotmail.com
- elias
I have done this, but it did not work. I changed the source to DirectX3 only and used that lwjgl.jar with the beta3 binaries. The no typing problem persists with this version.
Any more ideas?
I finally got hold of a Win98 SE machine, to try and reproduce the bug. However, I can't reproduce what I think you specify as the bug, but I can reproduce the bug I fixed in HEAD that makes Keyboard.getEventCharacter() fail on (some?) win9x platforms. Your original code snippet does not contain getEventCharacter(), but the way you explain that the Function keys and the arrow keys work, makes me suspect that maybe it's not really getEventKey() that fails, but getEventCharacter instead.
So, I'd like to know exactly which method you use for "typing" that fails on Win98 SE - is it Keyboard.getEventKey() or Keyboard.getEventCharacter()? Note that I mean character input, not arrow keys, function keys and the escape key (which can only be queryed through getEventKey()). In fact, my question could be posed as: Do you use Keyboard.getEventCharacter() at all in your project?
- elias
I think you are right on the mark. I use getEventCharacter() to get the typed key after having handled the F- and cursor keys. The following is the code that takes the typed key and adds it to the editor (which does not work with the bug).
Quotedefault:
char c = Keyboard.getEventCharacter();
if( c >= 32 )
{
Gui.getEditor().addChar( c );
}
Great! Then there's a good chance you'll find beta4 working on win98 SE. You can either wait for the release (should be very soon, probably this weekend), or if you like to test it, compile either directly from SVN or use these prebuilt binaries:
http://download.oddlabs.com/elias/lwjgl-17112006.zip
- elias
I have tried the pre-build files. Unfortunately this always gives me the following exception:
java.lang.IllegalStateException: Destroy the Keyboard first.
at org.lwjgl.input.Keyboard.create(Keyboard.java:293)
at org.lwjgl.input.Keyboard.create(Keyboard.java:312)
(I used the old lwgjl_util.jar, as there wasn't a pre-built one.)
Try this newer lwjgl.jar with that bug fixed (you can keep the natives):
http://download.oddlabs.com/elias/lwjgl.jar
- elias
This appears to work. Thank you.