I think my issue with the fork is that in fullscreen I did not move the mouse far enough. If you are basing the input on how far the horizontal movement is proportional to the total width, then the same amount of mouse movement in the smaller window translated to a bigger input. In fullscreen I was simply not moving the mouse far enough. I pulled it back up and moved the mouse from end to end in fullscreen and was able to get the handle to start moving. The default viewport size felt a bit small, so I did not really like playing it without fullscreen.
Viewing post in Switching Off jam comments
The code for the input was just “InputMouseMotion.relative * weigh”.
I took viewport into account too but overall it works the same on both “modes”.
In my tests the fullscreen were easier but I didn’t tested the web version, I just “deployed” to match the jam requirements (I mostly took optimization into account rather than tweak the gameplay settings).
Anyway, the game wasn’t meant to be played out of fullscreen so in a way it’s totally a bug (I tried using both axis on InputMouseMotion cause the player could get confused if the motion were supposed to be up-down or left-right; I just used both so any input like randomly moving the mouse very fast would have the same effect and not just left-right which was harder even while I was developing).
Also, the viewport is small cause I couldn’t get the godot 3.x “downscale” effect on 3D so in a way it was meant to improve performance but also to “look” like PS1 artstyle. I took “256 * 5 / 4” x “224 * 5 / 4” as a rule for the resolution but since 512x480 was “too laggy” because it lacked optimizations I just kept that lower (on 512x480 the fork is visible but that was a cheap way of picking performance x quality – I wanted a PS1 look so PS2 resolution was “too good” for the design I had in mind, I’ll probably use 800x600 in the future since it’s more standard but still as pixelated as 512x480).