Custom AWT-Mouse-layer behaving wrong on Linux

[Riven]

I'm making a world-renderer using JOGL, which lets you aim (heading) with the mouse. To get mouse-movement data, I implemented a layer on top of the AWT which I can poll() and then use methods like Mouse.getDiffX/Y().

On MS Windows this seems to work fine, but Linux seems to return scewed acceleration-data.

The source-code for the implementation is:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28

public final void mouseMoved(MouseEvent event)    {       this.mouseMotion(event);    }    public final void mouseDragged(MouseEvent event)    {       this.mouseMotion(event);    }    private final void mouseMotion(MouseEvent event)    {       if (Mouse.ignoreNextMove)       {          Mouse.ignoreNextMove = false;          return;       }       // add the acceleration to the diff      Mouse.xDiff += event.getX() - Mouse.component.getWidth() / 2;       Mouse.yDiff += event.getY() - Mouse.component.getHeight() / 2;       // set mouse at center of component using Robot class      // which fires a to be ignored motion-event      Mouse.ignoreNextMove = true;       Mouse.resetMouse();    }

In the Mouse class:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17

public static final void poll()    {       xLastDiff = xDiff;       yLastDiff = yDiff;       xDiff = 0;       yDiff = 0;    }    public static final int getDiffX()    {       return xLastDiff;    }    public static final int getDiffY()    {       return yLastDiff;    }

So the problem is: why does this work like a charm on Windows, and results in unpredictable behaviour on Linux?

Oh, and I really want to do this with AWT, so please don't start about JInput
(JInput throws an ArrayIndexOutOfBoundsException *inside* ContrlEnv.getControllers() ...)

The trimmed-renderer is webstartable and can be found at:
- http://www.songprojector.com/mmorts/files/webstart/mmorts_client_trimmed.jnlp

Any feedback on the behaviour is really appreciated as I don't run Linux myself

- Skippy

[blahblahblahh]

Who knows? It just crashes:

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

net.java.games.jogl.GLException: glGetError() returned the following error codes after a call to glActiveTextureARB(): GL_INVALID_OPERATION       at net.java.games.jogl.DebugGL.checkGLGetError(DebugGL.java:13705)       at net.java.games.jogl.DebugGL.glActiveTextureARB(DebugGL.java:40)       at com.vhiqs.mmorts.client.world.Terrain.preRender(Terrain.java:66)       at com.vhiqs.mmorts.client.world.Terrain.render(Terrain.java:40)       at com.vhiqs.mmorts.client.engine.Renderer.drawWorld(Renderer.java:187)       at com.vhiqs.mmorts.client.engine.Renderer.display(Renderer.java:249)       at net.java.games.jogl.impl.GLDrawableHelper.display(GLDrawableHelper.java:74)       at net.java.games.jogl.GLCanvas$DisplayAction.run(GLCanvas.java:221)       at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:290)       at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:208)       at net.java.games.jogl.GLCanvas.display(GLCanvas.java:75)       at com.vhiqs.mmorts.client.engine.Ticker.run(Ticker.java:180)       at java.lang.Thread.run(Thread.java:534)

PS why are you "caching" sin and cos? How much faster is it than Math.sin()?

[Riven]

Thanks for trying blah^3!

I think I have to trim the code a lot for you, as your gpu doesn't seem to support the 3 multi-texture-layers, which is ofcourse completely irrelevant in this case, sorry.

P.S.
Caching sin/cos turned out to be 8x faster (client vm), besides that: it takes *degrees* as argument, which is quite nice when working with OpenGL degree-based matrix-rotations.

P.P.S.
I'm making a trimmed version now.

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

[Riven]

Okay, here it is...

http://www.songprojector.com/mmorts/files/webstart/mmorts_client_trimmed.jnlp

Thank you for your patience

[blahblahblahh]

OK, it works (I see a compass and some mem usage data and an X cursor) - although the entire render window just paints blank grey (?).

However, the mouse cursor jumps wildly so I have no idea if it's working or not.

Note: you CANNOT programmatically jump the mouse cursor in the middle of mouse-movement like you are doing. I salute the cunningness of your idea; however, there are plenty of tracking devices that are absolute rather than relative (it actually makes GUI usage a lot faster that using a plain old relative-mouse, although you need some practice to get used to it), and you break all of them with your method (think about it and it should be obvious why ). Some people (like me) don't actually have a mouse at all any more on their main PC (partly because it's a laptop and mice are damn hard to use e.g. on the train - whereas a graphics tablet is easy - although of course I have the built-in trackpad for emergencies, which incidentally wasn't controllable either ).

PS: linux 1.4.2_05

[endolf]

(JInput throws an ArrayIndexOutOfBoundsException *inside* ContrlEnv.getControllers() ...)

 Can you send me a stack trace so I can have a look?. Even if you don't want to use JInput, i'd like to know whats going on so that others don't have the same issue.
 I'm currently implementing an AWT plugin for JInput if that would change your mind?

Endolf

P.S. if you can PM me the stacktrace, or start a new topic on the JInput forum, rather than me threadjacking this one

[Riven]

OK, it works (I see a compass and some mem usage data and an X cursor) - although the entire render window just paints blank grey (?).

It should render some sky-gradients, but if it doesn't I don't really care, as that's not the main prob atm.

However, the mouse cursor jumps wildly so I have no idea if it's working or not.

I think that's the linux-behaviour i heard from others.

Note: you CANNOT programmatically jump the mouse cursor in the middle of mouse-movement like you are doing.

Not a very strong argument, but: I *can* do it on Windows.

Besides that: I don't think it's in the middle of the movement, as it's just an event fired by the EDT *after* the native event occured. (?)

there are plenty of tracking devices that are absolute rather than relative, and you break all of them with your method

That's an interesting point. But would you expect FPS-style movement to take that into account? If I were using JInput I would have only access to relative movement right?

although of course I have the built-in trackpad for emergencies, which incidentally wasn't controllable either ).

Something to be expected as it's probably handled like a normal mouse, which didn't work for other testers on linux too.

~~~

To endolf:

Can you send me a stack trace so I can have a look?. Even if you don't want to use JInput, i'd like to know whats going on so that others don't have the same issue.

done.