XBox 360 Controller Issue

OpenGL Development
#1

Hi,

I’m using an XBox 360 Controller with the LWJGL API, more specifically the Controller Class, and every time I start up the default values for the left and right axis’s are ( -1.0, -1.0 ) until I move the analog sticks. Is this the default behaviour and is there anything I can do to make it default to ( 0.0 , 0.0 )?

Thanks

#2

This is “expected” behaviour though it would be nice if the LWJGL fixed it under-the-hood for the purposes of homogonising it across all controllers and platforms… but basically how I handle this quirk is:

  1. At controller create time, I record the initial polled values for each axis
  2. I then wait until all initially non-zero axes are different from this initial value before I decide the controller is “initialised”.

Actual live code in the pastebin. Notice that I try and specifically detect a 360 controller - turns out reading the axes varies on different controllers - grr.

Cas :slight_smile:

#3

This is relevant to my interests.

From the start I wanted to support Gamepads strongly, and special code for the Xbox pad seemed like a good idea.
Because, in case on “any controller”, of course there is a default mapping which can be “wrong”, so the user should be able to just map the pad himself, ingame.
In case of the Xbox controller, they are popular and all internally the same, a default mapping for these should therefore be a “good” one.

#4

First of all, thanks for the code, Cas, it’s really helpful, but I just have a couple of questions about it

  1. What I found was that it stayed at the default value until I moved the sticks, do you get the user to move them?
  2. Do you keep calling the getController() until isControllerInitialised() returns true

Thanks

#5

The idea is that somebody wanting to use the controller generally picks it up and wiggles it. I just call getController() every time I want to use it - that’s all (if it’s null, it’s not “ready”). Upon detecting real movement in the controller I also inform the rest of the game and hide the mouse cursor as well, and the whole UI switches to “controller mode”.

Cas :slight_smile:

#6

Ok, thanks! That clears it up nicely

#7

Forgot to say, if I subsequently detect mouse movement, I make the mouse visible again and switch back to mouse mode.

Cas :slight_smile:

#8

What JInput does under the covers is whatever the OS tells it, this means that it’s up to the device drivers to identify the axis that the controller has. This means that different devices and sometimes the same device but on a different OS will list different axis. It’s not ideal, but JInput was only designed to expose the hardware in a consistent way, not to make the devices or drivers underneath consistent :). As for the initial value issue, this is again down to the OS, JInput reads the initial values of the axis and then waits for the OS to notify it of changes in value, again, we could ignore the initial read and just use the updates, but that’s not what the OS tells us, so we leave that up to the user of JInput.

There might be an argument for a layer above JInput that handles things like axis mappings and the initial value issue, if anyone fancies doing that, feel free :slight_smile:

Endolf

#9

JInput’s perfect; I just think we probably need to try and plug the leaky abstraction at the LWJGL level and try to incorporate some of my hacks into LWJGL to make as many controllers on as many OSes behave as consistently as possible.

Cas :slight_smile:

#10

Lol.

There are at least 2 features that are not implemented that were supposed to be, and the code that I’ve written certainly isn’t perfect :slight_smile:

Endolf

#11

Well, it works for me! :slight_smile:

So far anyway. I’ve yet to unleash it in the wild.

Cas :slight_smile:

#12

I guess it depends on your definition of perfect, for me, perfect and ‘works for me’ are not quite the same, but I did stop ‘perfecting’ it once it reached that stage, hence the missing features :slight_smile:

Endolf