I know that this is not exactly 'input', but would it be possible to add some kind of mouse cursor control to jinput ? In fact, single method for setting mouse coordinates would be enough. If we could control mouse cursor shape (mainly for disabling it), it would be great.

I'm thinking about implementing mouse look - but to do this, I need to recenter mouse cursor every frame. I can use java.awt.Robot, but I would like to minimize dependencies on awt toolkit.

I'm going to have to oppose anything more than turning off the cursor because it doesn't fall under the realm of device input. The mouse itself receives no special treatment under JInput, it being just one of many devices that get enumerated.

I agree.. in fact I would put the pointer hiding into JOGL, even though it isn't OpenGL it IS more display-oriented. If you aren't using JOGL then AWT already has the ability, and I think so does LWJGL.

Hi sort of, but my response would be that the decive (mouse) doesn't give screen position, it gives movement relative to where it was, so, it might be logical to allow you to move the mouse by a certain amount (don't read pixels here, mice know nothing about them), but not to set a position. Screen positions and pixels are somrthing that the GUI knows about.

Ditto. This is something that the application would have to setup. The JInput system can tell you in relative terms where/how the mouse is moving, but it actually has no idea where it is.

You may be misunderstanding the concept of what the API does. JInput is just telling you what happened - its not changing the state of anything on the screen. If you're using JInput, you're not controlling the 'Java native mouse pointer' but instead some other pointer representation you're drawing yourself - similar to what you would have to do with LWJGL back in 0.6, though I believe they've done some work for peeking/poking the native cursor. All you're getting from JInput are offsets - what you do with those offsets, button presses, etc are up to you.

Ditto. This is something that the application would have to setup. The JInput system can tell you in relative terms where/how the mouse is moving, but it actually has no idea where it is.

You may be misunderstanding the concept of what the API does. JInput is just telling you what happened - its not changing the state of anything on the screen. If you're using JInput, you're not controlling the 'Java native mouse pointer' but instead some other pointer representation you're drawing yourself - similar to what you would have to do with LWJGL back in 0.6, though I believe they've done some work for peeking/poking the native cursor. All you're getting from JInput are offsets - what you do with those offsets, button presses, etc are up to you.

So, what's supposed to happen with things like graphics tablets?

E.g. if tablet is in absolute-mode, what data will JInput provide to the app? (At the moment WACOM tablets on several platforms are only supported in absolute-mode...although there are OS projects to try and provide drivers that enable the relative mode too - I hear it's a pretty simple change!)

Obviously, if tablet is in relative mode, then the driver is going to deliver mouse-like relative events, so no problem there...

If I get any free time soon, I'll experiment with my WACOM tablets and let you know what actually happens , but it could be a long time before then

Good question.. in fact I just bought a Wacom tablet for my powerbook and forgot completely that I should see what JInput has to say about it.

I suspect that the tablet will show up as a device with 2-3 axis and a few buttons and that the values returned for each will be straightforward.x & y axis will return the x & y position of the pen - assuming the device always returns absolute co-ordinates and the OS manipulates these to provide a relative "mouse" cursor.

I would guess a third axis, not sure what it will be called (z?), will likely return the pen pressure. And buttons are simple enough.

Although a tablet is not really a gaming device.. so maybe support will be limited in JInput if it is going to take too much effort to make it work right. I'm betting it won't be much trouble though.

Hi Under the linux version at least, if the device reports having absolute axes then absolute values will be reported to jinput, and the type of axis can be obtained from jinput. I've not tried one to test it, as I don't have access to one.

In OSX, the graphics tablet is in a different HID class that doesn't even get enumerated so its highly unlikely to be supported on OSX as it would open the door to enumerating a whole host of other devices that really shouldn't be enumerated and will cause JInput to break if those devices were plugged in.

Remember, HID enumerates anything on the USB bus - so you narrow it down by category. In this case its getting anything the HID chain quantifies as a game controller. Without categories we'd be getting a whole host of strange things like UPSs, hard disks, memory card readers, etc.

This only seems to happen with Windows/DirectX.. on the Mac I am seeing reasonable numbers. This is only with the jinputtester app.. I haven't tried anything "real" with the mouse yet.

linux reports the amount moved too, I beleive Jeff has this on his work list, but it's a long list. I'm in the US on a training course atm, then i'm moving, maybe i'll take a look at it after that if it's not changed.

Remember, HID enumerates anything on the USB bus - so you narrow it down by category. In this case its getting anything the HID chain quantifies as a game controller. Without categories we'd be getting a whole host of strange things like UPSs, hard disks, memory card readers, etc.

But but but.... HID stands for Human Interface Device.... UPSs, HDs, memory cards, etc. have no business being enumerated by HID... sigh....

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