Jittery/choppy cam movements when both mouse and keyboard input present

Whenever there’s both mouse and keyboard input present, camera movements appears to be jittery/choppy.

For example, pressing and holding any key and moving the mouse around makes it seem like mouse DPI drops every once in a while.

It seems to be consistent, too. It will move smoothly for two seconds, then will be jittery for 2 seconds. Doesn’t happen if you just move the mouse alone or just use keyboard to navigate.

First I thought it was due to camera position being updated from the simpelUpdate loop, but holding any other random key on the keyboard seems to reproduce the effect as well.

Now is this a known issue or am I just imagining things?

I hope I’m not imagining this because this guy describes something similar, but the thread seems to have gone nowhere.

Any feedback will be greatly appreciated!

What version of JME/SDK are you using?

I used to get this problem a while ago, it crops up every now and again (mainly when using physics) . But for the most part, it seems to have sorted itself out

I was using build jME3_2012-09-02.

How did the problem sort itself out for you? Should I update to an even later build?

Does this also happen on the JME tests?

Unfortunately, it does. Every test I tried so far.

It’s somewhat a minor issue, but a noticeable issue non the less.

Try loading a test, hold down any key on the keyboard and start making circles with the mouse. It will be smooth for 2 seconds, then will start jittering slightly for about two seconds, then smooth again for 2 seconds, then jitter again… And so on. Try doing this with a key pressed, and then try to just look around using the mouse.

Linux or windows?

Windows 7.

Just realized I forgot to mention a very crucial detail - disabling vsync gets rid of the problem.

I cannot reproduce it,

what jdk version you are using? what cpu ram graficcard ect.?


Intel core i7 920, 2.67ghz

NVidia GTX 680


Make sure to have vsync enabled.

It’s almost like mouse DPI dropps for 2 seconds, on and off. You might be reproducing it, but can’t notice right away. It affects the feel of controls though.

If you hold the left shift key for two seconds does the stupid Windows accessibility dialog pop up? If so then try turning that off (which is annoyingly obtuse if I remember right).

It’s a long shot but I’m just thinking of things that would kick in after 2 seconds that doesn’t seem to affect the rest of us.

Nah, it’s not the accessibility thing… It goes away once vsync is disabled. And it’s like this: exists for 2 seconds, disappears for 2 seconds, then comes on again, then goes away… Repeat forever.

I wonder if you guys are not noticing it cause it’s a rather minor effect.

It really is a feel issue, not a major bug or anything like that.

It becomes noticeable in comparison, after playing some fast paced online FPS games. Like, you know how when you constantly strafe and move your mouse for your weapon to point at the same spot? That’s when it’s noticeable.

So I don’t think it’s a JME problem. From opengl.org:

"My rendered objects lag behind the mouse cursor, but only when Vsync is enabled!" You probably have several frames queued up in the GPU. You may want to consider calling glFinish.

Other game engines seem to have similar problem.

So is there a way to call that?

Reduce the number of pre-rendered frames in your GPU’s control panel. Calling glFinish() reduces performance, you should never use it.

And can I adjust the number of pre-rendered frames from within JME?

@cephei said:
And can I adjust the number of pre-rendered frames from within JME?

jME3 has no control over this. If the user chooses incorrect settings in their GPU's control panel, then its their fault.

So default settings are incorrect?

This is a problem in your system, and has nothing to do with jME3 or other engines. I have a NVIDIA card with latest drivers, the default settings work just fine for me.