Pointer lock issues in Chrome (again!)

[MCArth]

I'm having issues with pointer lock in chrome (not in firefox/other browsers).

The elements being printed above are inputs.state.dx and inputs.state.dy.

I don't know the details of the previous bug existing in chrome version 63 (with a bugFix function in camera.js), but this bug seems to only affect dx, and be a large jump in the direction you're currently moving your mouse (both unlike the previous bug, based on your bugFix function!)

I've fixed this in my own fork like so:

function bugFix2(state) {
    const newDx = state.dx
    if (newDx > lx > 0 && newDx-lx > 150) {
        state.dx = lx
    }
    else if (newDx < lx < 0 && newDx-lx < -150) {
        state.dx = lx
    }
    lx = newDx
}

let lx = 0

(called in applyInputsToCamera)

Of course this also affects users who accelerate their mouse very fast - but I can't notice it even when attempting to do so!

I'm on the latest chrome build 88.0.4324.104 and a recent windows version 1909 18363.1316.

[fenomas]

Hi, thanks for letting me know. Was there any special trick to reproducing the issue you saw? It doesn't seem to be happening for me in Windows, on the same chrome version - at least not from just randomly swinging the mouse around.

I guess I should take out the bugfix code you mentioned, as it's now pretty ancient!

[MCArth]

Honestly, no. It's been happening to me for a few weeks and I got around to looking into it. It happens in other games on chrome as well.

If we're on drastically different windows versions, it may be a windows related bug, as it was previously. Apart from that, I don't really have any ideas.

[fenomas]

Agreed, looking at the old issue linked in the bugfix code, it could definitely be tied to windows revisions. Anyway though I can't reproduce it, I could tweak the current bugfix code to catch the case you're seeing.... it would probably be safe to ignore any dx value that's more than N times larger than the previous couple of values, I guess.

By the way, I think there's an issue in your workaround - code like if (a < b < c) is a nasty gotcha in JS. The first comparison gets evaluated and then converted to a number for the second comparison.

console.log(5 > 10 < 1)   // true!

[MCArth]

That sounds like it would work!

I appreciate the call out with the bug - I saw my IDE didn't give me an error and figured the behaviour was the same as some other languages! (silly mistake with JS bool evals, I know)

[fenomas]

Hi, I pushed a fix to #develop which should hopefully cover this. Can you have a look?

[MCArth]

Seems to work well - messed around for a few minutes and haven't experienced any janky camera movement. Cheers!

[MCArth]

Hi andy, recently noticed I ended up using 100 instead of 400 like so:

    var badx = (Math.abs(dx) > 100 && Math.abs(dx / lastx) > 4)
    var bady = (Math.abs(dy) > 100 && Math.abs(dy / lasty) > 4)

and the issue is still noticable with 400 like it is in the noa source.

In theory this could start infringing upon normal user mouse movement, so makes sense if you leave it in - but it hasn't been noticable in bloxd

[MCArth]

(feel free to close again, just reopening so you see this)