Raw input not working?

[Snowiez]

I have an issue where small or slow mouse movements are not being registered. At best, this can just feel like a small amount of acceleration but at worst it can make precise aiming at distance impossible, especially when scoped in. I think this is a problem that everyone experiences, but is worsened by having higher fps so might not be that noticeable at the default fps cap. DPI or polling rate could also come in to play but with my testing, the only thing that helped was making polling rate very low.

I thought raw input would fix this, but when switching between the modes and restarting, nothing seems to change at all.

[aldehir]

@Snowiez can you provide the following information?

• Max FPS
• In game sensitivity
• MouseX and MouseY speed found in User.ini under MouseX= and MouseY= properties
• Mouse X/Y multipliers under WinDrv.WindowsClient in UT2004.ini.
• Mouse DPI
• Mouse Poll Rate

This is unlikely related to input mode and most likely a result of how the engine translates mouse input into its coordinate system. High FPS makes it obvious, as you're experiencing.

[Snowiez]

• 480
• 0.15
• 1, 1
• 1, 1
• 6400
• 8000

I have since halved my dpi and doubled in game sensitivity. This helped a lot with the dropping of inputs when not scoped in but aiming still feels a bit off.

If this is unrelated to input mode as it seems, would it be possible to fix as a different patch?

[aldehir]

Unfortunately I don't think patching this is within the realm of possibility, at least not in a compatible way.

From what I can tell, the issue is most likely because rotators in UE2 are represented as integers between [-65535, 65535]. So your inputs, after scaling, are truncated and likely the cause of your input loss.

Here is a table showing how a single mouse increment is processed. I added entries for sensitivities of 0.15, 0.3, and 0.6. The last two columns represent the rotation change incurred at 90 fov and 30 fov (max zoom).[^1]

FOV	Frame Time	Min Mouse Points	Speed	Axis Change	Sensitivity	FOV	Min FOV	Input Change	Min Input Change	Rotation	Min Rotation	Effective Rotation	Effective Min Rotation
480	0.002083333	1	1	96	0.15	90	30	14.4	4.8	0.96	0.32	0	0
480	0.002083333	1	1	96	0.3	90	30	28.8	9.6	1.92	0.64	1	0
480	0.002083333	1	1	96	0.6	90	30	57.6	19.2	3.84	1.28	3	1

Notice at sensitivity = 0.15, the effective rotation is 0. This is exacerbated when zoomed in, as your sensitivity is scaled down by 30 * 0.01111. It is not until sensitivity = 0.6 that a single mouse increment produces a rotation change at max zoom (30 FOV).

My suggestion is to drop your DPI to 1600 and use a sensitivity of 0.6. I understand wanting to use high DPI, as it makes it more likely to saturate the 8 KHz polling rate, but unfortunately we're hitting the limits of the engine's capabilities.

There's also the potential loss of floating point precision, as your inputs are scaled by your frame time (aka delta time) throughout processing. It should cancel out in the end, but when dealing with small numbers the math gets iffy. If I had to guess as to why it is worse at higher FPS, it's most likely because of floating point precision. A higher sensitivity will help with that.

[^1]: This table only represents a single mouse increment, and not the case when faster movement is performed. During faster movement the input system aggregates your mouse increments for that tick before truncating.

[aldehir]

I want to correct myself on the FPS comment. Loss of precision is possible but likely not significant. It's more likely a result of processing less mouse events per tick. At 480 fps and 8000 KHz Polling, you should see 8000/480 or ~16 mouse events per tick at most. It will be much less during smaller mouse movements. You can use stat hardware to see the # of mouse events per tick.

[Snowiez]

That's a shame. Thank you for detailed explanation.

[zenakuten]

UTComp has custom code that uses 32 bit for rotators for player rotations. This has been ported to a few 3SPN versions also (SoL, UFC, and TUS have this).