So we’re trying to move our game from the plugin over to WebGL.
Our game is an FPS, which means the cursor is locked and hidden while playing.
For some reason, the mouse axes are a lot more sensitive in WebGL than they are the editor/standalone/plugin - our character turns a lot faster in the WGL build than everywhere else.
I set up an empty test project, and all it does is lock the cursor and display the mouse movement deltas and tracks the maximum absolute delta. Playing it in the editor yields results in the 5-10 pixels per frame. In the browser, somewhere in the 30-70 range. I haven’t changed any of the input settings, this is a brand new test project.
I’ve attached the project zipped up for anyone to try it and see. The results also differ a bit between browsers (I tried FF and Chrome), so I can’t even just multiply/divide by some predetermined number to ‘normalize’ the sensitivity.
I was thinking of just making a normalized movement speed when there is mouse movement at all (rather than check how much movement), but I believe that will prevent players with gaming mice from being able to cycle their DPI on the fly, which we’d rather not do. Is this a bug? Intended? Beyond Unity’s control?
Side note: Upload says max 4MB but I tried uploading the zipped project with the build which was 3.2MB and it said too large. So build not included…
This problem is present since the beginning of your webgl export.
The mouse feeling is completely different when you test on the editor and webgl build.
First, the sensitivity is around 2 time faster in a webgl build than on the editor (look like the GetAxis do not have the same value in the editor than webgl build).
Secondly, it’s the feeling when you play an fps game in a webgl build compared to the editor or the old unity web player. It’s horrible to play an fps game now on a webgl build because of the sensitivity problem and also because when you make a quick movement with the mouse the feeling is so bad. In my fps game (unity web player version) the mouse feeling is normal and we can play fluently. When i switch to the webgl version (exactly the same code) the mouse feeling is so bad.
It’s the case for all fps game released with unity webgl. I have tested a lot of webgl fps game build with unity and everytime it’s the same, the mouse feeling is bad.
Here : http://www.asr-games.net/testing/mouse/ you have a simple build using the unity standard assets (FirstPersonCharacter). Everything work but the feeling when you move your character and move your mouse is bad if you compare it from the editor.
Simply test on the editor and see how much you need to move your mouse for a 360 degrees and do the same on the webgl build here http://www.asr-games.net/testing/mouse/
Normally, if you have to move your mouse 2/3 centimeters on the editor, you should only need around 1 centimeters for doing the same movement on the webgl build. Also, you can check the mouse feeling by making some fast movements and see the difference bettween the editor/webgl build.
Yeah, we can scale the mouse movement but even with that, the mouse movement/acceleration do not feel like in the editor or like previously by using the unity web player.
It’s not easy to explain if you are not a regular first person shooter player.
At the first view, everything seem to work perfect and it’s the case, it’s working but the precision/accuracy is so hard if you compare it from the editor or desktop version.
As exemple, some of my players who continue to play my game with the unity web player are not able to play the same way on the webgl even with the same code.
First because of the sensitivity difference between the editor/ WebGL build (repoduced by the unity staff)
And also because of the precision/accuracy or mouse acceleration problem.
I don’t know if the bad feeling mouse acceleration problem come from unity or from the web browser but something is wrong somewhere.
For anyone looking for a workaround, values returned by Input.GetAxis(“Mouse X”) and Input.GetAxis(“Mouse Y”) are exactly twice as large in WebGL. A movement of one pixel returns 0.05 in the editor and 0.1 in WebGL. This does not seem to differ between browsers. So simply halve the value for your WebGL build.
I have noticed this long time ago and i divide by 2 the input but it’s still more faster and the feeling is terrible compared to the editor or old Web Player.
I tried solving this mouse sensitivity problem by adding a slider (for mouse sensitivity scaling) in my ‘Controls Menu’, which enables the user to choose their preferred scale factor. This solution works in my stand alone build, I can even set to zero and there will be no mouse movement (as expected), but this solution does NOT work in my webgl build and currently I do not know why? If I set the sensitivity to zero, the mouse shouldn’t move at all, but it still does and at the same fast annoying speed. Does Unity handle static variables differently in webgl than it does in the editor or stand alone? It shouldn’t…
Hello,
I had the same issue, im not sure if it has to do with the screen size when you export it to WebGL. My workaround was a bit dirty but since it was just a quick prototype it worked. Hopefully you might be able to do something similar.
Basicall I ended up clamping the mouse delta from -1 to 1 and then multiply the value for my desired speed. That way the webGL version behaves in the same way that the Unity version.
