Wed May 12, 2021 9:38 am
I have been getting reports of camera roll functions messing with mouse input somehow. A common description is that mouse looking feels "jerky" or "input lag".
I am unable to detect these issues across the variety hardware I'm using (all completely different computers, different mice, etc). Even on my current mouse, which has a 1000hz input rate, paired with a 144hz monitor. I'm not experiencing these issues people are reporting.
Please test these two files loaded one at a time (don't load both), and WITHOUT other mods (don't want other mods interfering with this test). You should also disable your autoloads (tick the "disable autoload" checkbox at startup, or start gzdoom.exe with -noautoload for advanced users.
Load up the mods in any of the Doom games, then press your +use key (the key you use to open doors, activate switches etc) to toggle view tilting on or off. Let me know if you detect any mouse input jitter with the thing ON vs OFF.
Let me know if there is any difference at all between Test A and Test B.
You do not have the required permissions to view the files attached to this post.
Wed May 12, 2021 10:04 am
Hey thanks for looking into this! I tried each one (-noautoload) and I can't really discern a difference. They are both stuttering when enabled, and fine when disabled.
Wed May 12, 2021 10:53 am
Btw, I really hope this can be fixed because I'd absolutely love to add this to my autoload stack. I have this weekend ritual of using Github Desktop to check all the projects I'm interested in (building GZDoom, Raze, DOSBox etc...) and your Tilt++ repository has been on my list for ages now just waiting for the day I can finally use it
/EDIT Oh and the problems for me predate when I started building my own GZDoom, and just to be sure I just pulled the latest off DRD and yeah, no change.
Thu May 13, 2021 12:04 am
You should probably also post your INI file so we can rule out any kind of settings changes that might provoke this.
Fri May 14, 2021 12:38 am
I will test it later today once I'm back home.
Fri May 14, 2021 2:59 am
This is exactly the kind of use case that
i_timescale was meant for.
Have you tried a value like
Fri May 14, 2021 3:21 am
We've determined where the problem might come from.
A_Set[View]Angle/Pitch/Roll (yes, all three are affected; not just roll, as per original report) activates the CF_INTERPVIEW flag for 1 tic if SPF_INTERPOLATE is passed to the scripts, and this is tripping the view interpolation for some reason.
For mods that only call such functions once in a while (like weapon mods with recoil), the effect is probably less felt, but for a mod like Tilt++ which calls A_SetViewRoll every tick, it manifests as "input lag" or "view jitter" to players who are sensitive to it.
However, it seems that not everyone can feel this side effect. As I've said in another thread - it is invisible to me. And apparently, to the ~10k people who're using Tilt++. Additionally, I have changed computers and hardware several times throughout the years and in none of my hardware combinations have I been able to detect this problem. But I'm acknowledging that the problem exists and shouldn't be dismissed.
Here are some snippets where phantombeta suggests what can be done about it. I'm putting this here so it doesn't get lost.
Fri May 14, 2021 4:01 am
Sounds like almost if not exactly the same problem I reported some time ago.viewtopic.php?f=2&t=61422
Fri May 14, 2021 4:11 am
Sounds reasonable Normally, mouse axis polling is done at render frame rate and not interpolated. If you now add you own axis changes on top of it it will surely create interference if you want them interpolated.
We had massive issues with similar effects in Raze because the games add their own view shaking effects that simply do not work right if the mouse polling is decoupled from the tic rate - think Duke's vieq squashing effect on hard landing as an example.
In some cases the problems were bad enough that we had to temporarily revert mouse to synchronized input.
Since Roll is not affected by mouse input - only yaw and pitch is - it should be solvable, but for the other two axes it will probably require a major rework of the input code.
I'd suggest to get mjr4077au into this discussion because he has done most of that work on Raze and may have better ideas how to address it.
Fri May 14, 2021 4:37 am
I think the easiest solution actually might be to allow the function that changes the third axis to be run when running CF_PREDICTING. This might mean the function itself has to be run in a limited scope.
It would be easier if CF_PREDICTING was run on temporary data, instead of operating (as far as I know) a direct copy of the actual game sim data. This complicates things a lot more than it ever should.
To facilitate this, one possibility might be to make the input handlers virtual, and allow for ZScript code to change the player view as it deems necessary for such purposes.
Fri May 14, 2021 6:16 am
I don't think that would help at all, In multiplayer the unsynchronized mouse input is completely disabled so whatever you do in the prediction code will never be subjected to what happens here.
Also changing ZScript won't help any bit. What you got here is two conflicting paths of input for the same variable and you got to find a way to make them coexist.
Fri May 14, 2021 9:46 am
Thank you Graf!!
Btw, i_timescale .2 with the tilt mod active resulted in a hilarious "drunken doomguy" effect
/EDIT it definitely makes the little "brick walls" you hit more apparent though. If the idea was to make the issue more perceptible to Nash, I think it should...
Fri May 14, 2021 10:09 am
I've tried playing with 0.2 timescale. Nope, still no jitter detected. It feels the same with or without mods, at 1.0 timescale or 0.2.
Fri May 14, 2021 10:20 am
Curious what your inches per 360 is. I’m at 8”. If you move your mouse at a constant speed over let’s say 12”, you don’t notice any interruptions? I’ll try the timescale thing again when I get back to my computer to make sure I’m not talking out my ass, but pretty sure I was hitting these big snags with the timescale set.
Powered by phpBB © phpBB Group.
phpBB Mobile / SEO by Artodia.