I think you misunderstand me. Pixel skipping exists on the Windows Desktop, and the mouse input in TF2 is based on the Windows Desktop cursor if m_rawinput is '0'.

No, I use 9050 DPI. I was showing my math with what you're referring to, in order to demonstrate where the 2.7128 number was derived from.

The question has been answered, I think. You wouldn't *want* to have the highest in-game sensitivity, you might simply want to know whether to use your mouse's lowest or highest native DPI step, and lowest might put you above that "highest" sens.

Correct--and *because* DPI is irrelevant to the question, we should be able to provide a definite numerical answer (if we know resolution and FOV).

Once we've established what the "maximum in-game sensitivity" for a given FOV/resolution is, an individual can then adjust their DPI around whatever that sensitivity value may be to achieve their preferred inches/360.

There has to be a definitive point at which "anything" becomes "stupid".

If 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").

Most 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?"

There 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.

The "2.7182" number comes from me doing the following with the equations I found courtesy of this site and its "Useful DPI Calculator":
https://funender.com/quake/mouse/index.html

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

2) 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.

With an FOV of 106 (instead of 90), using the same math, that number changes to ~3.6, which it would seem is corroborated by HOI's findings:

With my own setup of a 2560 horizontal resolution and 106 FOV, the number does in fact happen to come out to ~2.70.

By 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.

It sounds like his primary point is that if the competitive community were kinder it could have been something more. That seems super reasonable to me.

Causes crashes for me in casual now, as well. The file I was using before the installer was a thing still hides the gun (but not gun arm) and is stable to use, though. I can't remember where exactly I clicked to get it, so I'll just reupload it for anyone that needs it:

https://www.dropbox.com/s/g3wng4qpqrq7qru/xyzspyviewmodel.vpk?dl=0

I couldn't check out what degu uploaded because zippyshare.com wanted me to install something I didn't want to in my browser to download :(

Looking good!

What's the best way to share custom configs with you?

dsp_enhance_stereo 0
dsp_spatial 0
dsp_facingaway 30 (or 0)

snd_spatialize_roundrobin 0

Sorry, I was sleepy and copy & pasted a section from my custom.cfg then forgot to remove 'dsp_water 0' and 'dsp_room 0'...would you mind elaborating on what the others do, exactly? Any effect that is intended to produce 3D sound from a stereo source is problematic for proper output to something that's doing the same thing, but yep, delay and reverb are the main things used in surround sound virtualization and you don't want those being applied on top of each other.

If you don't mind, I'll go ahead and dive into the "spatialization" section of your comp preset here:

//dsp_enhance_stereo 0 // Disable spatial DSP effects and delays
//dsp_enhance_stereo 1 // Enable for slight increase in sound quality, most
                       // noticeable on multispeaker systems

My understanding is that this effect is that "snd_surround_speaker 0;dsp_enhance_stereo 1" is the equivalent of setting sound to "Headphones" in the game options menu--basically TF2's own crude headphone surround sound virtualization (Miles3D, specifically, if I understand correctly).

//dsp_slow_cpu 0 // Use enhanced positional effects
//dsp_slow_cpu 1 // Disable initialization of enhanced spatialization

I'm assuming these "enhanced positional effects/spatialization" are designed for 2 channel output

//snd_spatialize_roundrobin 1 // Spatialize sounds every 2 frames, less performance benefit.
//snd_spatialize_roundrobin 3 // Spatialize sounds every 8 frames (2^3) using round-robin algorithm.
                              // Pretty reasonable performance benefit, but delay in spatialization.
//snd_spatialize_roundrobin 0 // Spatialize every frame

I'm not sure how the "sound travel" part of "Spatializing" (you define it as "sound travel and volume falloff") accounts for speaker count, but yeah it seems you'd want it to happen every frame if at all.

//dsp_room 0 // Disable automatic DSP
//dsp_room 1 // Enable automatic DSP. Big performance hit

Curious about what "automatic DSP" is, seems possibly relevant

//dsp_facingaway 0 // Disable the facing away DSP effect
//dsp_facingaway 30 // Use a DSP effect for sounds you are facing away from

Is it known what kind of effect is applied here? Seems important

//dsp_speaker 50 // Administrator effect
//dsp_speaker 0 // Disable administrator effect

Ditto

//dsp_spatial 40 // Spatial effect for positional audio
//dsp_spatial 0 // Disable spatial effect

Could you explain the significance of "40", and what disabling this does exactly, please?

//dsp_db_mixdrop 0.7 // Use enhanced volume scaling

What's being enhanced?

Thanks, I know it's a lot for a pretty niche thing. Really appreciate your time.

snd_surround_speakers 7 // or 5 for Windows 10, it seems
dsp_enhance_stereo 0
dsp_slow_cpu 1
snd_spatialize_roundrobin 0
dsp_speaker 0
dsp_water 0
dsp_spatial 0
dsp_facingaway 0
dsp_room 0 

Thanks, very interesting....I wonder why there is no 7ch command. I'm also curious what all DSP effects are being applied in the first place, aside from sound placement stuff.

JarateKing knows more than me

I myself have changed some values for this purpose, though I'm on Windows 7 using Out of Your Head for 7.1 surround virtualization. Here's what I use, but testing this stuff is a pain and I'm not sure about all of these...the general idea is to get rid of all spatialization effects that are intended for stereo output. Would be very interested in some thoughts:

snd_surround_speakers 7 // or 5 for Windows 10, it seems
dsp_enhance_stereo 0
dsp_slow_cpu 1
snd_spatialize_roundrobin 0
dsp_speaker 0
dsp_water 0
dsp_spatial 0
dsp_facingaway 0
dsp_room 0 

On a different note, one thing I've noticed about the network settings is that "rate" and "net_splitpacket_maxrate" are set to match. All of the competitive servers I've played on recently have had "rate" capped to >100000, but "net_splitpacket_maxrate" uncapped, so the values end up mismatching (1048576 splitpacket/100000 rate, for instance). Not sure how important it is those values match, but you might want to consider innovating a safeguard of some sort or reducing the values below 100000 in the comp preset.

It would be cool if you integrated ytrium's viewmodels mod (which involves preloading and is probably what he's talking about).

Keep up the great work, mastercoms

So what's up with cl_pred_optimize exactly? I see you've set it to '0' on this one due to a bug with '2'?

I'd also be curious where the '0.02273' value for cl_interp is coming from

-dxlevel 90 makes pyro flames visible for me (not vis with 95). Was -r_emulate_gl responsible?

I seem to experience strange hitches with "net_queued_packet_thread 0"--what are the supposed benefits?

It has no performance impact, so I wasn't really referring to any one config.

Fine to play it extra safe though. This seems like a meticulous endevour for you, so I thought you might appreciate some input

Since the setting determines how soon sounds play after their corresponding event, I think it is a relatively important value to get right.

0.1 is very conservative, as would make sense for a default.
0.08 is safe for nearly all, 0.05 is about as low as you can hope to go without experiencing sounds being cut off. I'd recommend you default it to .08 and comment a safe experimental range of 0.05 to 0.1.

Fun fact: you can use a tiny tweak called TimerResolution to shave off enough DPC latency to manage .05 instead of .08 on some setups http://www.mediafire.com/file/28bs8awx9f7qn3h/timer_resolution_service.rar

Totally forgot to do this, my bad. Here are the 'timedemo' benchmarks:

No affinity setting (cores 0-7 for all applications): 
75.3 average FPS,  5.7 variability, 53.3 seconds

Affinity "offloading" (cores 0;2;4;6 for tf2, 1;3;5;7 for all other applications): 
78.9 average FPS,  5.6 variability, 50.8 seconds

Just a +2.5 fps boost, but it's there. Used to give bigger gains (+10ish) and resolve micro-stuttering issues (I haven't played enough without PL to know if I still gets stutters without) due to Core0 maxing out (somehow disabling core0 caused the CPU load to be distributed more evenly between cores)

I wasn't streaming when doing these benchmarks, only previewing in OBS Studio, so maybe it's smaller than expected because OBS wasn't eating as much CPU. OBS Classic only had CPU Encoding available back then too, and I use NVENC Encoding now, which puts most of the load on the GPU. I also was using an older processor when benchmarking back in the day, so maybe that's it, too.

Sure, I'll share a benchmark comparison when I get a chance.

Re: preloading, so my own "custom/stabbyHUD" folder then (root of /cfg folder). Thanks.