Vertical mouse look jumps multiple pixels at once

[ciscon]

Unlike horizontal mouse look, vertical mouse look jumps multiple pixels each step.

Background

Version of Crispy Doom: b26157a

Operating System and version: Debian/Linux Testing

Game: All

Observed behavior: Vertical mouse changes view by multiple pixels each step.

Expected behavior: Change view by one pixel at a time.

[fabiangreffrath]

Have you tried adjusting vertical mouse sensitivity in the menu?

[ciscon]

it's not sensitivity, it's the amount at which it jumps when calculating viewangles/pitch (i'm guessing). setting it to an extremely low sensitivity and moving it from one y position to another results in a large jump as opposed to the much smaller one you'd see when doing the same thing horizontally. changing things like MLOOKUNIT just change the rate at which it happens (ie sensitivity).

[fabiangreffrath]

Hm, any ideas code wise?

[ciscon]

i've been looking over it but i'm not all that familiar with the code, perhaps it's snapping viewy to the lower screenheight, or the lookdir stuff? it just kind of seems like it's not interpolating where the viewy stuff is like the viewx stuff, at least not to the same degree. i definitely see how width/x stuff is treated differently than height/y though some of it is obviously being used to calculate other things only being derived from position/viewangle, which makes sense.

[ciscon]

it appears if we change pitch to float/double in r_setupframe it mitigates the problem somewhat, though it's still jumping a few pixels it's definitely far less, probably due to the difference in width/height etc, or just that while the intermediate calculations are now more accurate the end result/lookup is not, which is probably fine. of course with that done, now the floor/ceiling textures update more accurately until when it "used" to snap the vertical movements to, at which point it all snaps back to the less accurate position, so i'm sure "something" there would need to be updated as well.

[ciscon]

i see, it looks like the vertical plane stuff has never done the interpolation stuff, if you skip that logic for setting pitch and just set it the same way it's set when uncapped is off, you get the old/broken behavior (so i'm not quite sure why there is currently different logic to calculate pitch when it's uncapped). plus, the floor/ceiling planes are updated less often, which seem to be the points at which the plane rendering blips a bit when getting more vertical change updates by changing pitch to be a double. i'm wondering if since the horizontal stuff was working and paid attention to, that's why there are things like xtoviewangle/viewangletox mapping things and whether or not something like that is needed for y, or if there'd just be an easy enough way to retain the old plane update behavior while keeping the number of y updates, as even when it blips a bit, it's still infinitely better.
it's still not being done exactly the same as the horizontal stuff though, that's pretty obvious, it's just "better". you can tell we're still stuck at whatever the scaled vertical resolution (or something like that) is, especially if you change high resolution rendering off, you'll still see horizontal movement update at very small intervals while vertical movement is still in larger jumps.

[fabiangreffrath]

I read from this that it boils down to the fact that we don't properly interpolate vertical angles between tics, right?

[ciscon]

that would appear to be the issue