[Addressed] Mouse polling issues with view roll

[0mnicydle]

Woah OK, never mind what I said, I shouldn't have been posting while waiting for my second vaccine dose lol. The thing I was noticing with the timescale changed was how awful changing directions becomes. It's laggy and jerky to change directions with the mod at i_timescale .2 (this could be an exaggerated form of the input lag people complain about), and fine without the mod at the same time scale (talking actual Tilt++). And actually changing the time scale doesn't affect the mouse input in any way without the mod, where with the mod it changes your turn speed/sensitivity and just generally messes it all up (drunken doomguy).

But the jitter on a constant speed turn I usually see with the mod, no it's actually maybe harder to see now at .2, so sorry for the misleading comment.

Try i_timescale 2 (or higher) however. I feel it becomes even more apparent. If you still don't see it I'm really at a loss, unless your mouse isn't really in 1000Hz mode (125Hz looks pretty much as bad as the bug). Or you know, there is some crazy reason why there is no issue for some configurations... which seems unlikely based on my limited understanding of the conversation.

EDIT/ Actually, you know what I'm gonna do later? I'm gonna make a vid, and see if I can still see it in the vid, and if I can I'll post it and see if you can see it there too.

[StroggVorbis]

Okay, so I get jitter as well, with both TiltTestA and TiltTestB. Don't notice any difference between them.

i7-4790K
16GB DDR3
GTX 970
Logitech G502
Lioncast LK15
Windows 10 x64
GZDoom g4.6pre-225-gc1c4066c7

[0mnicydle]

Nash, here's the video I said I'd try to make. Now it's a video, so it's not going to be perfectly synchronized to your monitor to begin with, but I can still clearly spot the difference in smoothness with TiltTestA test on and off here and that's all that matters. The first few moments are tilt deactivated, and then you'll see the message pop up in the upper left when I enabled it.

https://drive.google.com/file/d/1SdD5aL ... sp=sharing

/EDIT if the video doesn't play in your browser, try using the download button in the upper right

[Nash]

Nash, here's the video I said I'd try to make. Now it's a video, so it's not going to be perfectly synchronized to your monitor to begin with, but I can still clearly spot the difference in smoothness with TiltTestA test on and off here and that's all that matters. The first few moments are tilt deactivated, and then you'll see the message pop up in the upper left when I enabled it.

https://drive.google.com/file/d/1SdD5aL ... sp=sharing

/EDIT if the video doesn't play in your browser, try using the download button in the upper right

Wow, okay, well yeah it looks nothing like that for me.

Anyway, we already know what's causing this so I think the testing doesn't matter anymore.

[0mnicydle]

Gotcha. But at least now we know your eyes work Though I hope this doesn't mean the rabbit hole goes even deeper if the issue is only present on certain configurations and not others, but I'll leave you all to it. I'm just happy it's being looked at finally.

[mjr4077au]

For anyone interested in testing, I have a branch here with a working fix for this issue: https://github.com/mjr4077au/gzdoom/tre ... rateAngles. Activate it by setting cl_nointerpactorangles to 1 in the console.

Very early stages and not overly tested, but would welcome feedback before I present anything. Tested with the test files in initial post.

[0mnicydle]

OK well, this is a huge improvement! I can confirm this does indeed fix the problem for me. Very exciting!

I also discovered something while testing this that might explain why some people see the jitter and others don't: A few days/weeks ago I changed my default fps cap from the in-game option of 120 to a custom setting of 140, in order for it to be an even multiple of 35 based on some discussion I saw on the Discord server about smoother monster movement. When I first tested this new build the jitter wasn't present regardless of the cl_nointerpactorangles setting. I was like, "was there another change made that applies regardless of this setting?" So I went back to 4.6 and still I could no longer manifest the issue. I was seriously like, wtf! It was then that I remembered I recently changed my fps cap, and setting it back to 120 allowed the jitter problem to manifest once more. So it seems if your framerate is an exact multiple of 35, you won't get jitter. That being said, I do believe I could detect some very slight input lag even at 140fps with cl_nointerpactorangles false that disappears with cl_nointerpactorangles true, though I don't think I would have noticed it if I wasn't specifically looking for it.

Thank you so much to everyone who is working to resolve this issue!

[Nash]

Omni: I'd be interested to know your experience playing BoA with mjr4077au's branch, with the tilting code enabled in BoA. Or perhaps Tilt++ with some stock maps.

[0mnicydle]

I will certainly test some more later, including in BoA, but I can say I've seen enough already in stock Doom that Tilt++ has finally taken its rightful place in my autoload!

[0mnicydle]

Oops, I just noticed something... It seems Steve's flashlight mod isn't working properly with this build, regardless of cl_nointerpactorangles setting... The spotlight is stuck facing in one direction.

viewtopic.php?t=59429

[Nash]

Oops, I just noticed something... It seems Steve's flashlight mod isn't working properly with this build, regardless of cl_nointerpactorangles setting... The spotlight is stuck facing in one direction.

viewtopic.php?t=59429

Don't worry; it's already been brought up.

In case it wasn't clear; this is a proof of concept branch and is in no way "ready". It's in its very early stages. Quite a bit more work needs to be done before it can be considered ready for GZDoom.

(matter of fact, probably don't try playing BoA with this build for now, as that mod most likely has a crapton of non-player actors calling angle changes which won't work with the POC build)

[0mnicydle]

I gave this build a try in BoA, both the 3.0 release and the current dev version, and this branch works a treat to get rid of the jitter and input lag there as well. However, and I'm guessing you already expect this, it does break the intended tilt effect on c3m5_c.

As an aside, I run BoA with a lower cap (60fps originally, but now 70) due to the generally poor performance of that game's maps, and the input lag with cl_nointerpactorangles false is much more pronounced and noticeable at lower framerates; this I would notice even without looking for it. I usually play Doom at high framerates so input lag was never my main complaint with the tilt mod, it was always more about the jitter. If I was stuck on a 60Hz monitor I'm sure I would have been one of the ones complaining about the input lag too.

[mjr4077au]

Please give it a try now with the latest commit. An oversight on my part meant angle/pitch/roll changes weren't applying to non-players.

[0mnicydle]

Please give it a try now with the latest commit. An oversight on my part meant angle/pitch/roll changes weren't applying to non-players.

Awesome, Steve's flashlight mod is working now!

BoA enforced tilt on c3m5_c still is not, but I assume this fix was not intended to address that since this pertains to the player. Also it seems this may only apply to the current dev version of BoA--it looks like the 3.0 release is still working as far as I can tell. I do remember they made some changes to their tilt script specifically aimed at addressing the topic issue...

EDIT/ Also I just want to clarify the issue I'm seeing on BoA c3m5_c dev build... The best thing to do is to turn mouse look off and center your view. Once the sloping effect kicks in, if you do a 360 it will look like your aim is moving up and down in a sine wave, whereas in 3.0 it just looks like your aim remains level as you turn around on a sloped surface.

EDIT/ In other words, if I look towards the front of the ship it looks sloped down, towards the back sloped up, but if I turn to the sides it looks like I'm on a flat surface... it's a very disorienting.

EDIT/ Actually I finally understand the trick that's supposed to be at work here I think... When you look towards the front of the ship they move your aim up to make it look like the surface is sloping down, and move it down when you look towards the rear to make it look like it's sloping up, and at the same time they are applying view rolls and moving your aim back towards center as you look to the sides, so everything has to kind of happen at once in concert to complete the illusion, and in the current dev version of BoA, in this branch with cl_nointerpactorangles true, the view roll aspect of this trickery isn't kicking in.

[mjr4077au]

Awesome, Steve's flashlight mod is working now!

Yay!

BoA enforced tilt on c3m5_c still is not, but I assume this fix was not intended to address that since this pertains to the player. Also it seems this may only apply to the current dev version of BoA--it looks like the 3.0 release is still working as far as I can tell. I do remember they made some changes to their tilt script specifically aimed at addressing the topic issue...

They might be best to revert whatever they've done to try and counteract it. I've approached this in the most compatibile way possible to prevent modders having to redo anything. If this was all grass-roots, I'd probably have an AddRoll() method in addition to the current SetRoll() method call.

EDIT/ Actually I finally understand the trick that's supposed to be at work here I think... When you look towards the front of the ship they move your aim up to make it look like the surface is sloping down, and move it down when you look towards the rear to make it look like it's sloping up, and at the same time they are applying view rolls and moving your aim back towards center as you look to the sides, so everything has to kind of happen at once in concert to complete the illusion, and in the current dev version of BoA, in this branch with cl_nointerpactorangles true, the view roll aspect of this trickery isn't kicking in.

I'll try to pull their code and do some testing. Just for awareness, I'm generally unfamiliar with GZDoom's code unlike Raze so this might take some time. Its hard to shoe-horn stuff in like this to a widely used engine in a compatible way, which is what we're seeing now.