Chromium mouse bug

Hey, everyone

I’m creating a FPS game for a game jam and I noticed a bug that appears to be present only in Chromium-based browsers.

Tutorial: FPS Movement

Using Chrome, Edge, or any other Chromium-based browser, at random while you’re turning the camera, the camera will jump back in the opposite direction a huge amount. I first noticed this happening in my game after following the tutorial, and after testing the tutorial in the browser for a bit I noticed it happens there too.

I’ve outputted the “mousemove” event to the console, and I’ve found that while turning in a direction I will get integers from 1 to 10 outputted for event.dx (or event.dy, it happens for both) like normal or however fast the player is turning in a smooth line, and then suddenly it will jump in the opposite direction to an extreme number from -50 to -450 or 50 to 450 on average.

It’s extremely unpredictable when it happens, so you do have to be patient for it to replicate, but when it happens it can happen as much as 3 times in a row. I’m sure it’s not gimble lock because I’ve outputted those values to the screen and I’ve confirmed it’s the mousemove event itself that’s outputting the crazy numbers.

The problem does not seem to be present on Firefox, as I was unable to replicate it between my game, the tutorial, and another user who happens to be participating in the same game jam as me using PlayCanvas. I brought it up with the other user and they said they had thought their mouse was bugging out, which was my initial reaction too before seeing that Firefox does not output a gigantic leap in values at random.

I’ve tried to code around it by ignoring frames that have a ridiculously high absolute value event.dx or event.dy, but unfortunately the jump can be pretty low too like a normal player mouse movement and it’s not a great fix.

Any ideas why this might be happening?

Thanks!

Hi @ArooBaito,

I vaguely remember some users having a similar problem in the past, I may be wrong though.

But in this case I am unable to reproduce this on Chrome (latest) on Windows. There is no jumping no matter the movements I try.

It took me a long time to notice in that particular tutorial because all 4 of the walls look so similar, even with the shadows cast. I’ll create a video of the problem, a fork with a different environment, and the debug outputs.

Although it is subtle and you have to be playing the game for a bit before it happens, it seems like it’d be very detrimental to the user experience for precision-oriented games.

@commention Have you noticed any issues like this in your games?

Thank you, I appreciate the response in any case! I’ll have the demonstration stuff up this weekend, I’m just trying to get all the art out of the way for the project first.

I’m guessing it’s related to the high DPI mouses, my friend was having similar things, I didn’t see anything like this before. TBH there are tons of reports on my game that is similar to this one but I couldn’t reproduce any of them. I believe it’s all related to the high DPI mouses.

2 Likes

Isn’t it just the gimbal lock issue? I think the tutorial has it.

As I stated earlier, it’s not gimbal lock. Coding a reset to the Euler angles has no effect, and when logging the mousemove event, you can see it’s the input itself causing the issue.

One thing to try is to do it in pure HTML to see if it’s a Chromium based bug without PlayCanvas.

I wonder if it’s a polling rate issue with the mouse. What mouse are you using?

I think PlayCanvas just uses the raw values from the browser mouse event.