stabbyIf a user has Raw Input disabled, then their mouse movement is being determined by the Windows Desktop mouse cursor, which operates pixel by pixel on a 2D plane. Pixel Skipping certainly exists for the Windows mouse cursor, and will occur if the user has their Windows sensitivity set higher than default. If Raw Input is disabled, and the Windows mouse cursor is experiencing pixel skipping, the problem will correspondingly manifest itself in TF2 (i.e. "exist").
TF2 does not use windows desktop pixels for the rotation counts (no game should).
Depending on the ingame sensitivity the minimum step that corresponds to the number of counts in one desktop pixel could be 1 ingame pixel or 13.245 ingame pixels or 0.0045212 ingame pixels.
Also if if corresponds to 1.1 ingame pixels then you will simply turn in 1.1 pixel increments, without skipping any pixels in between.
Pixel skipping doesn't exist.
stabbyMost users choose to enable Raw Input, which does not utilize the Windows cursor, so this is a bit of a moot point--but the question in the OP is a practical one with a definite answer, and the problem "pixel skipping" presents is relevant to it. I believe what he is asking is "What is the highest in-game sensitivity setting in TF2 that will not limit the granularity of my rotation?"
Iirc the source engine uses float to represent angles. That means if we pretend that exponents and signs don't exist just the full precision of the 24 bit mantissa requires 16,677,216 counts per 360. At 12,000 DPI (and that's not really a thing, just multiplication and some fancy DSP footwork) that's ~1398.1 inches per 360. So about 116 and a half feet or about 35.5 meters for a full turn. And that's the lower bound, it's actually much higher.
stabbyThere has to be a concrete answer to this; like an actual number that can be given based on the user's DPI, display resolution, and settings like accel/FOV/m_rawinput. Saying simply "don't use anything stupid" strikes me as lazy and unhelpful. There's an actual answer to this actual question.
See above. There is an actual answer and for the source engine it's utterly useless.
stabbyThe "2.7182" number comes from me doing the following with the equations I found courtesy of this site and its "Useful DPI Calculator":
Here are the relevant equations:
Real Sensitivity ("i"): 360 / (m_yaw * DPI * TF2sensitivity)
Useful DPI: (pi * Horizontal Resolution) / (i * tan(FOV / 2))
Here's what I did with them:
1) I inputed my settings into the "Real Sensitivity" calculator:
360/(.022 m_yaw * 9050 DPI * 1.3 TF2sensitivity) = 1.3908743190511148
I won't check the actual numbers.
But setting the sensitivity via DPI? Come on.
stabby2) I calculated the useful DPI for a 1920 resolution, 90 degree FOV, and ~1.3" Real Sensitivity
(pi * 1920) / (1.391 * tan(90/2)) = 4336.738274819446
3) I calculated the TF2sensitivity that I would need to use to keep my "Real Sensitivity" the same if using "Useful DPI":
360 / (y * d * s) = 1.3908743190511148
360 / (.022 * 4336.738274819446 * s) = 1.3908743190511148
s = 2.71286834
2.7128 is the sensitivity that corresponds to a maximum useful DPI with a horizontal resolution of 1920 and an FOV of 90.
So are you using 4336.738274819446 DPI now? If yes I'd like to know how you set that.
If not then it's not "pixel perfect". With 9050 DPI and 1.3 ingame sensitivity you'll instead turn by 0.47919759942756309392265193370166 center pixels per count (all other pixels are different). Literally unplayable.
Now imagine what would happen with 2.8 ingame sensitivity. 1.0321179064593666638334041648959 pixels per count. LITERALLY UNPLAYABLE.
stabbyBy all means, critique my math, the equations/the site I'm working with, or how I'm approaching the question. My hope is that the OP's question can actually be answered, not that I'm right.
The question is pointless and the answer is useless.
No mouse will allow non-integer DPI steps anyway, but if you can't set that then one count will translate to something like 1.0004 pixels of 0.9997 pixels, making the limit even more arbitrary and pointless.
It just has to opposite effect because non-native DPI steps fuck up everything.