I don’t exactly know how FlyByCamera is supposed to be working, but if it finds a Z axes on a joystick, it binds cam rotation to it. However, on most of modern gamepads Z axes are actually shoulder triggers and the right stick is “rx” and “ry”. This results in camera spinning endlessly if gamepad is connected to the PC unless you somehow manage to stabilize it by pressing both triggers exactly half the way.
I could submit a PR which fixes it, but I’m not sure what would happen to flight joysticks with that fix. I’m also not sure how that would work on other controllers. I tested it with both Xbox 360 wired controller and with Xbox One S Wireless controller and both produce those results.
I should probably also mention that I’m on linux, however last time I tried it on Windows it produced the same results if I remember correctly.
EDIT: And if I do take time and make a PR, I’ll make chase camera support gamepads as well.
I bought 6 or 7 different joysticks and created mapping for them in the default JME mapping file. That was used to setup the TestJoystick app that is in the standard JME test suite. So for all of my game controllers here (and some I already had) the two joysticks worked properly.
It’s only X-box joysticks that seem to have the problem. I guess microsoft likes to look around at the way everyone else is doing things and then flip them the bird and do it their own incompatible way… but whatever.
If you look at the ID of your joystick and the values you are getting in the test joystick app, it is theoretically possible to remap the Z axis to the right joystick. If it works then you can even submit a patch for that game controller’s config in the joystick properties file.
Hmm, okay then.
It would be great if there is a way to detect if the gamepad is xbox based so we don’t have to remap every single gamepad separately.
I’ll get to work as soon as I can find the default mapping file.
I mean, in the end, you absolutely will never ever get away with releasing a joystick based game without giving the user the ability to remap it.
FlyCam is a horrible class. It’s only single use is for temporary apps and quick demos. Any real app will create their own first thing, most likely. If for no other reason than that flycam is controlling a camera instead of a game object. It’s totally backwards for most games.
Between those two things, creating proper mappings for whatever knock-off xbox gamepad clones might be out there is just about having useful initial defaults.
Eventually, I want to take on this issue and provide an appstate (or two) that eases things for developers and users… but if you don’t want to use Xinput (there are bindings for Java), this is the way.