Gamepads,Full-screen mode and Camera control

I’m currently developing a game that uses gamepads. After a bit of tweaking I got the sensitivity of the camera control set to acceptable levels so that moving the PS4 joystick moves the camera. However, I’ve discovered that if I play the game full-screen, the sensitivity goes through the roof, and the slightest movement of the joystick causes the camera to turn massively in that direction.

I’m not sure what I can change to fix this. Obviously I’ve got no code along the lines of “if (fullScreen) { goBananas(); }”. The code is pretty much taken from and uses AnalogListener(). The only thing I can think of is that the framerate is playing a part. When I get an input from “public void onAnalog(String name, float value, float tpf);”, do I need to use “tpf”? I thought I read somewhere that “value” was already pre-multiplied by this.

Of course, any other suggestions are more than welcome. :slight_smile:

Thanks in advance!

Are you using vsync? If you’re getting different framerate in non fullscreen than fullscreen then not using tpf can be the cause of many different problems. I’m just not sure if input is one of them.

I’ve never used the vsync option before (I’m not really sure what it does) but I’ll give it a try to see if it makes a difference. Thanks for the suggestion.

VSync limits the game framerate to your monitor refresh rate or a fraction of it (so for a 60Hz monitor, you get 60 FPS if your machine can handle it, otherwise 30, 15…).

1 Like

Thanks for the info. I’ve not tried it yet (at work etc…) but don’t think this is the answer. Looking at the code, “value” is pre-adjusted by the tpf by InputManager.

Yes, I think mouse movement does that and it’s dumb. Gamepads should not be doing that, I think… but who knows, JME inconsistently self-multiplies tpf sometimes.

High frame rates mean very small tpf which can cause math to be weird. So turning on vsync for full screen may help you. It’s an option in the settings dialog that pops up at app startup.

Note that Lemur’s InputMapper does not premultiply anything by tpf and also provides per input sensitivity scaling. (InputMapper can be used even if you don’t want to use the rest of Lemur.)

So then you could properly use tpf in your movement code and also set sensitivity differently for joystick than for mouse, etc…

Lemur wiki:

InputMapper javadoc:

Lemur gem on using the input mapper:

1 Like

Thanks, I’ll have a look at that. I’ve discovered that the “demo first person control” code from the JME tutorials works fine, even on full screen. The main difference between that and mine is that I’ve got 4 seperate cams/viewports, and also a much lower FPS (about 22 when running full-screen). Maybe one of those is to blame, but at least I’ve got something to investigate, and I know it is possible to get smooth cam movement with a gamepad.

I’ve discovered that it is the frames-per-second that is the problem. If I add a simple Sleep() to the demo BetterCharacterControl in order to reduce the framerate to ~<30, the gamepad control become very erratic, alternating randomly between moving slow then fast. Also, moving the joystick to the maximum extent in any direction turns the camera slightly more slowly than having the joystick at ~80% extend. However, mouse control is still fine.

I just need to work out how to fix this (or at least increase the FPS of my game). Any suggestions welcome though. :slight_smile:

Did you try multiplying with tpf?

I tried dividing the value by the tpf, since it was already multiplied. Unfortunately it didn’t make much difference, apart from slowing down the turning when the fps dropped.

Are you using this gamepad successfully with any other games? The erratic behavior (fast then slow when fps is roughly the same) almost sounds like it’s not calibrated.

The gamepads work fine on a PS4, and also generally using JME at higher framerates, >~100fps. The problem seems to be that the turn rate is different depending on the framerate (especially noticable at low framerates), and at lower framerates the turn rate slows down slightly as the joystick reaches it’s maximum extent (i.e the fastest turn rate is when the joystick is at approx 80%).

Does anyone else have a gamepad that they could try and recreate this problem with? Or alternatively, does anyone know of a small JME game that I could download and test to see if I have the same problem with that? Maybe it’s my crappy PC…

So it definitely sounds like tpf isn’t being incorporated correctly. I’ve never used gamepads (or done much with input devices in general - I spend most of my time on game backend/engine dev) so I’ll leave specifics to someone here with more experience with gamepads & jME. However, the “80% behavior” sounds like a calibration issue to me. Every time I’ve used a joystick on a computer I’ve had to calibrate it at the driver level to get good input on computer games, and that kind of behavior happens frequently without good calibration (and input is often very unsteady/jerky). I’m really just guessing here, but my speculation is that consoles are performing some sort of auto-calibration on the fly as the controller is used. I don’t see how you could get could input otherwise. That could explain why your gamepad works fine with your PS4 but not your computer.

I use gamepads all the time on my PC and I don’t have to calibrate them really.

If it were me, I’d print the values as they came out of the method’s parameters to see what they were doing.

…then again, I use Lemur’s InputMapper which specifically doesn’t premultiply anything by tpf because that’s silly.

That being said, if OP wants to try Lemur’s Gem #1 (linked above) to see if it has the same behavior, it might narrow down what’s happening.