Analogue Input handling

I’ve added rebindable controls to my game and have run into some issues.

As far as I know there’s no way to tell whether the call for “onAnalog” came from the keyboard, mouse or joystick. (unless I create seperate action names for them, but that’s really inconvenient, as I’d have to completely rewrite my input handling, not to mention the huge load of extra case testing)
The problem is that the “value” is completely useless to me, because for keyboard I’d like to have a flat “1.0”, and for joystick I’d like there to be values between, based on how far the stick has been pushed. Since keyboard gives delta values, it is totally useless to me.

What’s more, mouse motion events don’t even send a “release” event for onAction (it always claims to be “pressed”), so the game doesn’t know when the input had stopped. (It’s pretty annoying because the joystick handles it just fine)
If i wanted to attach a mouse axis movement to set a boolean-flagged action, it’s broken unless I set the boolean to false each frame, which is suboptimal.

By the way, the inputmanager’s SetAxisDeadZone method forgets to mention that it affects the mouse aswell. Unpleasant surprise when I found there wasn’t an onAction call for every onAnalog call per mouse motion event. Sharing a deadzone value can be problematic I’d imagine.

Anyone have some experience with this?

But what is the point of your question? You already know the answer: You have to rewrite your input handling.

If you want to process Mouse and Keybord event different, they must have different action names.

Analog and Binary (Action) are different listeners, you have to use them according. If you want KeyBoard to have a flat 1.0 or 0.0, this is a binary action (onAction) not a Analog one.

To me it doesn’t make any sense to have delta values for keyboard analogue calls, so I figured I’d ask around if there’s a better solution than rewriting my input handling altogether. It’s a lot of work for what seems to be a bad design choice of the engine. I’m sure there’s some sort of explanation for why it is done this way and I wanted to make sure I’m not missing an easy workaround.

The mousemotion issue I’m curious whether it’s a bug or limitation.

A joystick has a center, so it’s logical that when it returns to center it could be considered “off” again. A mouse has no center and so any decision JME made on that front would be arbitrary and probably wrong in as many cases as it was right. (Right for you, wrong for someone else.)

JME handles the basics and when those aren’t enough it gives you RawInputListener so that you can do fancier stuff if you choose to. For example, I used this interface to implement an entirely new input mapping scheme for the Lemur GUI. I wanted keys and joystick axes to be more homogenous. So you can use them interchangeably as either analog axes (for buttons) or buttons (for analog axes) and get similar results. (You could take a look at it, Lemur is a pretty small dependency.)

Even mine doesn’t handle the case of trying to map a mouse axis to a button style event, though. I’m not actually sure what it would do without trying it. But honestly, I don’t even know what I’d use that for in my game because the analog version would work fine for me in most cases where that matters. In fact, much of Lemur’s input mapping was designed to go the other way… so I could treat WASD like joystick axes for movement and didn’t have to have two sets of listeners.

If you could provide an example use-case of what kind of button you’d want to map to a mouse axis… and by that I mean what it actually does in the game… then maybe I have more comments/advice.

It do, you just need to implement the right listener .

Thank you for the replies.
Very good point about mouses not having a center.
I actually use both the action/analoglistener aswell as the raw input one, I redirect the raw input into binding keys in the menu or typing in text fields, or the developer console.

Truth be told I didn’t have a strong case to make mouse motion act like a button, my game being top-down view, the initial idea was to try moving the player character with mouse movements. I didn’t particularly think it would make a great control scheme (it’s actually terrible), but since I’m offering rebindable controls, I figured “hey, whatever floats the player’s boat”.

After giving it some thought, i did come up with a better use for the X axis on the mouse, to turn the camera left and right around the player, as if it was some sort of TPS shooter, and instead of using the cursor to aim, the character would always aim “away from the camera”. It’s something I’ll still look into, but considering I was already doing camera rotation in a loop, I could just aswell do it in the onAnalogue method using TPF instead of having a boolean for it. It’s not like it would be cheating to press multiple keys to turn the camera faster, either.

Right now my game totally gets away with not having great support for stupid control schemes, later down the road I’ll probably get around to having a different listener for keyboard, mouse and joystick, though you might imagine I hate having triple the lines of code with small difference between them. :stuck_out_tongue:

Since we’re already talking about input, has anyone tried the joystick rumble recently? I don’t personally own a controller so I had to ask a friend to help me out, but it doesn’t seem to work for him. He’s technically using a PS3 dualshock 3 type controller, but he has it go through XInput to simulate an xbox 360 controller.