TheNoobPolice

This is incorrect and just misinformation. All you need to do is enable Raw Input and ensure the in-game accel is off (m_customaccel = 0, which isn't related to the windows accel whatsoever). My motivation for pointing this out, is that a lot of fairly naïve newcomers to gaming lurk on forums like these to get info and this sort of thing is totally confusing and just completely wastes their time. Given I know for a fact you do not need to enter those launch args to get unsmoothed / unaccelerated / unfiltered mouse input - you can see exactly what those params do in the code I posted and exactly how Raw Input is being called. You can also see in this very thread a video where DPI Wizard is sending different counts distance values at different input cadences and there is no smoothing on the output as the movement frame-by-frame is identical and it ends up at exactly the same spot (so no accel either). I know you are not experiencing any smoothing at all with m_rawinput = 1 because I know it does not exist (unless you deliberately go out of your way to enable m_filter = 1) So I am genuinely curious what your motivation is to pretend otherwise. Like is it just a "I want to be right" or are you genuinely gaslighting yourself into thinking that unless you mess about in the registry there is some mystical effect on your mouse input? MarkC registry stuff is 13 years old and hasn't ever been relevant to Raw Input games. All it ever did is make it so when "Enhance Pointer Precision" checkbox is enabled in windows mouse settings, the cursor output is the same as with it disabled. You can just untick the box in windows mouse settings for the same effect, or enable Raw Input where the checkbox doesn't affect input anyway. There is probably about 3 titles in existence where it was necessary to avoid forced windows accel, none of which anyone is playing now and/or have since been updated to use Raw Input anyway.

Why are you doing any of this? That launch arg just calls the WinAPI SystemParametersInfo() Get/SetMouse which is how applications control the windows mouse / EPP values if they want to, and it's storing existing values that it then first checks on init. So in other words, you are manually editing values in the registry to some value you think is going to do something for you, and then asking the game to call that and store it in a variable to use on init. I am not surprised if it breaks something with the cursor. https://github.com/ValveSoftware/source-sdk-2013/blob/master/mp/src/game/client/in_mouse.cpp#L262 The default Windows setting is to have EPP enabled, maybe why the convar m_mousespeed has been chosen to be set to default = 1? but this doesn't affect Raw Input in any case. None of those relate to the function for the raw input mouse event accumulator which overwrites the *mx / *my variables with raw input data if m_rawinput = 1 https://github.com/ValveSoftware/source-sdk-2013/blob/master/mp/src/game/client/in_mouse.cpp#L331 The order the functions are checked / applied is then here - you can see for GetMouseDelta() function the first two args are the passed-in raw input deltas. https://github.com/ValveSoftware/source-sdk-2013/blob/master/mp/src/game/client/in_mouse.cpp#L663 It checks for it's own filtering convar at that point - which defaults to 0 at the top of the file in case you were also worried about that, before passing out the output https://github.com/ValveSoftware/source-sdk-2013/blob/master/mp/src/game/client/in_mouse.cpp#L368 All you need to do in CSGO is set m_rawinput 1 and m_customaccel 0 if you don't want to use either the in-game accel or Windows EPP / WPS settings. There's no reason to enter any other convars or worry about anything else. It matters not one jot that Enhance Pointer Precision is enabled or not (m_mousespeed = 1) when the game is calling Raw Input.

Yes to be clear it is common and good practice to expose the system cursor for menus and that's not what it is important here. Otherwise, you get that Doom Eternal effect where if the user has a lower WPS setting than 6/11 the cursor will be way too fast for the user compared to their desktop

CS 1.6 != CSGO. Why are you talking about a different game now? If you enter some convar that changes the way mouse is handled then you are possibly overwriting how it gets mouse input. I'm not familiar with that game and the only code I have perused is this https://github.com/ValveSoftware/source-sdk-2013 that CSGO is built on. I guess 1.6 is not since it was released ten year earlier. Like I said, if the game is actually calling Raw Input (which CSGO does) then those settings don't have any effect.

There's basically three ways games can get mouse input events; Raw Input, Direct Input (deprecated) and Windows Mouse. If you call GetRawInputData() or GetRawInputBuffer() (two API's variants of the same fundamental thing) it is physically impossible for those registry settings you mention to have any effect, as the (x,y) packet is obtained beneath user space, and before those functions even occur. In other words, those settings could only affect a game where Raw Input was "enabled", if the "Raw Input" object in the GUI / convar was just flat broken and basically wired to nothing so it was just calling windows mouse. This is not the case in CSGO and it is easily demonstrated it functions correctly. It would also be completely incompetent and I don't think I've seen that ever. The reason a new DPI can feel different even when normalised to the same degree/count is only because of: 1) The mouse sensor is not perfect and has a different % DPI deviation at different settings. Sometimes this can be quite significant and is very common. 2) Assuming you compensate by lowering the sensitivity after increasing DPI, you get a lower minimum angle increment, which can make very slow movements feel smoother / different. 3) If the game actually does have errors in it's sensitivity formula at certain values. There is no voodoo with this and it is easily tested. CSGO does not have any errors as per DPI Wizard's earlier post. 4) Placebo. None of that is anything to do with mouse sensitivity. Monitor refresh rates, eye tracking in motion vs stationary, screen resolution or anything else etc. Nothing I have said is out of date or behind the times - there are no developers making their FPS mouse sensitivity calculations incorporate factors relating to eye tracking of moving vs stationary objects in the current year lol. That is all just la la land. The sensitivity functions in a game will point your crosshair / camera to the exact same point in the game world even if you turn the monitor off or don't even have one connected, so there is obviously no link to that. You are almost talking as if you think the turn increment in the game has to be a division of a pixel size / distance or something? Suffice to say it doesn't. There is also no "jitter" in the game math for calculating sensitivity, it's just numbers and math is math. Any timing jitter occurs at the mouse firmware side and it's interface to the operating system due to realities of Windows timing I mentioned before - that is also not a function of screen resolution / monitor refresh rate anyway. One last point before I am done with this silly thread about things that are already completely understood lol. Any digital function has a finite resolution, and if you so wish, you can zoom into it close enough and find errors. If you blow those errors up into a big enough image on your screen it can look like something significant, and we can create a story about it for x,y,z reasons, but it's effectively just a non-existent problem. I can view an audio wave at 96khz that was original sampled at 192khz and when zooming I can see artefacts of the resolution that are not there in the 192khz source. Does this mean 96khz is awful and all our audio needs to be minimum 192khz? Of course not, even 48khz is totally fine. Because apart from those "audiophile" tosspots who insist on paying a grand per meter of cable that is soldered using the tears of a Swan and insulated with Albatross feathers, it's all just bollocks and complete unnecessary. I get the feeling that if we already had 100,000hz mice, 800 PPI screens, 10,000hz refresh rates, and 10,000FPS gaming, you'd still just be zooming-in and taking screenshots on your website saying "these microseconds are not enough, my new mouse API removes cursor micro-stutter to within the nano second! Look at the jitter your cursor has!" The masses are asses though and no doubt there's always some plonker to sell "magic beans" to, so I wish you good luck convincing them with that

Hand-waving in full effect I see.... The reason 8khz doesn't work a lot of times is nothing to do with "mouse mathematics" or floats vs double precision of sensitivity variables. It is because of how games acquire input themselves. A game like Valorant only works with 8khz when it calls GetRawInputBuffer() to hold the inputs until an arbitrary buffer size is filled when the engine is ready for the input. If any app just gets WM_INPUT messages "as they come" as per a standard read of Rawinput, then unless it's pipeline is so trivial that it is only doing something like updating a counter, then it will most likely fall over with inputs spamming-in haphazardly every ~125us. The symptom is dropped packets, negative accel and / or just maxed CPU usage and stuttering. None of this is anything to do with sensitivity calculations being superior / inferior. Windows is also not a RTOS and is objectively bad once timing gets tight, it becomes extremely expensive to try and do anything accurately at these kind of timings. This is not going to change as it's a fundamental of the Windows environment. The only reason low DPI can work with 8khz in some games where high DPI doesn't, is because the DPI is nowhere near saturating the polling rate and you're getting much lower input cadence. Set your mouse to 8khz and 400 dpi and move at 1 inch per second and your update rate is 400hz (obviously) and is therefore no longer "8khz" as far as the game is concerned. This is nothing to do with the DPI setting itself, which the game has no knowledge of or interaction with as DPI Wizard already said. Most simulation loops of in-game physics, enemy positions - things like whether a crosshair is over an enemy etc will run at 60hz, maybe a really competitive FPS would run higher, and maybe they poll mouse input faster at 2 or 3 times the frame rate of the game, with the textures / graphics rendering running at the actual frame rate obviously. Usually though, you would register event callbacks from input devices which are then passed to a handler / accumulator that is then called once at the start of each frame. In other words, it does not matter if you are sending 8000 updates a second to the OS, because a game will just buffer them all and sum the total mouse distance to be called at the start of each render frame anyway - it makes no practical difference to your crosshair position whether you do this work in the firmware of the mouse at 1khz, or whether a game does it instead at 8khz. The only important factor is that the polling rate is greater than or equal to the highest frame rate of the game at a minimum. If you think using 8khz is giving 8000 discrete rotational updates of your crosshair a second, and for each of those positions an enemy location is being calculated for whether said input would be over a target or not (i.e something meaningful) then you are mad. Once we get into the future where performance improves, it is also not inevitable this will change - rather the opposite. We have, for example the precedent of "Super Audio CD" and "DVD Audio" in the audio realm which were both large increases in resolution vs CD quality on a factual basis, yet both failed as standards precisely because that level of resolution is not required for the user experience - instead, users actually gravitated towards lower resolutions (compressed audio formats) and smaller file sizes for easier distribution. Point being - if such technological improvements were available to game engine developers to do more complex computations within a smaller timeframe, they will not be using such resource to update the crosshair position more frequently. There are many things such as higher animation fidelity, better online synchronisation systems, more complex physics, rendering improvements etc which would all be much higher priority and more obvious quality gains. Either yourselves or Razer's 8k marketing team moving a cursor on a desktop and posting pictures of "micro stutter" is not going to make any user see a problem. This is unlike the actual micro-stutter that occurs in 3D rendering due to frame-cadence issues, which are readily apparent to even the uninitiated user. There is no one using a 1000hz mouse on a 144hz display and going "geez, I really hate these micro-stutters on my desktop cursor, I can't wait for that to be improved!". In short, you are inventing a problem and then trying to sell a solution / idea of a solution, and your argument effectively boils down that anyone who disagrees just doesn't have the eyes to see the problem, when the truth is no problem exists in the first place, and your solution would not even solve it if it did. Mouse report rate does not need to be synchronised to monitor refresh rate or game frame rate etc whatsoever, and insisting it would improve anything is fundamentally misunderstanding how the quantities of each are handled and how they interact with one another. Games will always render frames at arbitrary intervals because each frame has infinitely variable parameters all which require an arbitrary amount of resources, and mouse input polling on Windows will always be haphazard timewise and always has been due to the fundamental design of the operating system. Moreover, once the timings get down to a millisecond or so then there is no value to anyone in any case. No one is going to care about turning G-sync on if the monitor can run 1000hz (this is effectively the "Super Audio CD effect") and any "improved" mouse API that presumably could send decimal distance values to the OS instead of the standard (x,y) packet of integers with remainders carried to next poll, would also achieve nothing of value to anyone over existing systems that are stable, extremely well understood and established.

If there was an objectively correct way to set it up, it wouldn't be an option in the menu. The developer would just set it internally to what is "correct". It's entirely user preference and just functions as a fine-tune aiming sensitivity slider, where the values represent a percentage of screen space instead of a coarse linear percentage of degrees / count. The same values / methods exist on this website so you can have the same feel and conversion approach from one game to another. You don't need to stick to any specific numbers, you may find 131.05% is perfect for you and not 133% for a given scope. It's all completely arbitrary.

A gish gallop of nonsense. Blurbusters have a history of making extremely simple premises sound extremely complex and use sophistry and hand-waving to make sure that no one who ever actually could de-bunk it, would ever have the time or inclination to. I mean where do you start with this: "At 60Hz using a 125Hz mouse, fewer mouse math roundoff errors occured(sic). But at 500Hz refresh rate and 8000Hz mouse, especially when multiplied by a sensitivity factor, can generate enough math rounding errors occurs in one second (in floats) to create full-integer pixel misalignments!" Utter drivel I'm afraid.

If you do want to change the FOV instead of the sens, you should bear in mind you are nearly always more limited by FOV options in games, especially if you like the upper end of them. But with a calculation you can work out the new FOV needed to match focal length on the new screen size instead of changing sens... You can do newFOV = 2 * (arctan( screenSizesRatio * tan( ( oldFOV * π / 180) / 2))) * 180 / π so if the oldFOV was 90 degrees on the 24 inch, and the screenSizesRatio is 27/24 = 1.125..... we then have: newFOV = 2 * (arctan( 1.125 * tan( 1.5708 / 2 ))) * 180 / π so newFOV = 96.73 degrees on 27 inch

I wouldn't ever use stretched as I don't buy into the idea that it is helpful, so it is entirely up to you. Maybe other R6S seige or CS:GO players have more insight for what is best with that setup. Your horizontal sens is (16/9) / (16/10) faster than your vertical at screen centre so you could scale your vertical sens * 1.111 or your horizontal * 0.9 to match them. To be honest 0% matching from native in the source game to stretching in the target game makes a mockery of "focal length matching" , since the only movements that can be matched are strictly along one axis only and a human basically never moves "along" an axis, but continually over a combination of both. Even when you think you are moving purely horizontally, you are not. People tend to think of mouse input just as x and y but it's better thought of as a 2d vector with a given distance in any 360 degree direction, and when you stretch you distort that vector. If you apply a different component multiplier as above in the traditional manner to compensate the opposing axis' distance difference, you further shift both the angle and diagonal distances in other ways than you are used to. So your best bet is a very rough approximation of "matching" for your particular setup.

In MW 2019, I don't think it was a true dual render (mostly because that is expensive) rather just a visual magnification function, and the area within the scope was given a focal length scaled sensitivity (in other words, slowed down by the difference in magnification, which is why the velocity at the edges of the scope didn't match up to the areas around it of course. So the tracking velocity would have been the same with and without the magnification which makes sense to me (regardless of whether the user scaled the "outer" ADS FOV by 0% or not). If they have done something different for this game I'd be rather surprised as it seemed like a good solution.

ok, but since your R6S is stretched, you still need to pick either a vertical or horizontal match, as in this instance they will be different

You would need to figure out what you want to do as your source and targets are most unusual. Your Overwatch Hipfire FOV is far more "zoomed in" than your R6S ADS is. Not an issue in itself, but you also have a stretched aspect ratio for R6S, but NOT for Overwatch which means you also have a different "focal length scaled" sensitivity when moving vertical vs horizontally, so you would either need to pick which one to use in the conversion method selection, or use one and then add the vertical hipfire modifier in R6S to balance the difference - but this will then change the angle of diagonal mouse inputs (I don't use any y/x ratios to change vertical sens now as don't like how it changes angle, rather use a bias function I added to Custom Curve to do so but that's a whole other discussion).. You then have the screen size change to factor in, and whether or not you are at all concerned about the R6S hipfire being matched to anything whatsoever, which you don't seem to be. So I don't think there is any advice I can give you now, because I fundamentally don't understand why you would set the games up like they are personally.

The reason is because you matched your R6S ADS to Overwatch hipfire by focal length, but your R6S Seige hipfire is a different FOV than Overwatch

I believe this is an example where the UI / graphics guys just make a visual representation for normie users that is going to be the easiest to somewhat understand. if they showed 16:10 vs 16:9 with a different width when they both say the same width number "16" it would look wrong to such a user, and the alternative of showing the resulting ratios of 1.6 vs 1.78 would probably be more confusing for them. I wouldn't worry too much about the menu UI representations of things.

Because you asked this: So I showed you what your hipfire sens settings would be if you wanted to keep your ADS "focal length scaled" from what you are used to on 24", and also then scale the hipfire by focal length from that new ADS sens. Since the way the sens variables are implemented in R6S is effectively a car crash of circular dependencies, you have to change different variables to get the same result. But really, what you are doing doesn't really make any sense to do that anyway, because I didn't realise your old hipfire sens on 24" wasn't matched by focal length anyway to your old 1.0x zoom, because you massively reduced the ADS sens to 38. In other words, you were previously using 76% of focal length scaling for your ADS: https://www.mouse-sensitivity.com/?share=0dd5017571bb8a58de48b3acfc8b5e6e i.e So basically, all you need to do is set as per these values on your new monitor and to hell with the hipfire sens, cause you were never using anything other than an arbitrary value anyway and it doesn't seem like you really care about that.

Actually, there may be a difference even if you match the 360 distance for the final value, because for “Gradual” it depends at what point they also scale using the specific scope slider, and whether the relative monitor distance transition is a procedural loop, or if it is pre-calculated, stored in a variable, scaled by the specific scope’s slider, and then that returned value applied time-linearly over the ADS animation duration for any weapon, (or at the start of it or the end for instant / after) I assumed the former as that is how BF does it, but actually, if you allow the user to select the transition type, it makes sense to do the latter. In other words, I don’t think it’s clear whether the gradual, instant or after option includes the ADS scope multiplier value, or whether that applies only to the monitor distance multiplier, and the scope value is always a post or pre-scale. Since I would only ever use a scope multiplier of 1.0 it never occurred to me. It is not easy to test without seeing the code, as when you are fully zoomed in it is all the same. So I guess for this aspect, you are reduced to “set by what feels best”.

https://www.mouse-sensitivity.com/?share=2a98fd582651a0b38942350c62ea8dab

It's a case of picking your poison, because if you match the focal length scaled sens of 27" ADS to 24" ADS, then your hipfire with 27" is no longer matched by focal length unless you change it. In other words, whilst actually playing the game; your sens will slow down more when you aim than it would do with a focal length match to hipfire. You could then choose to adjust your hipfire sensitivity so that it is also matched by focal length, but this then means your 360 / navigation movements (180 turns etc) are a different distance than before on 24". It's my experience this is often more problematic than just adapting to a different velocity at screen centre. Up to you though, you just have to choose what you want to be matched and what you want to change. You could also do what I did and what philheath is suggesting, and use a 24" unscaled resolution and just benefit from the pixel density and any other stat improvements on your new monitor without any sensitivity adaptations required. I would give it a try before dismissing it as I think it is a good solution especially for competitive shooters where you may have already built-up a good level of play on a given setup.

No, you shouldn't assume that. Games only have a monitor distance coefficient when there is this formula used: ADS Sens Multiplier = atan(tan((ZoomFOV*pi/180)/2) * Coefficient) / atan(tan((HipFOV*pi/180)/2) * Coefficient) The only games that do this are Battlefield and CoD to my knowledge, and both use the vertical FOV for this scaling. 0% is not really a coefficient (multiply anything by zero and you get zero) rather just the focal length scaling formula, although the result is practically identical to some small coefficient value like 0.001 i.e this vs this yields the same result to 6 decimal places, and there are indeed a lot of games that use focal length scaling. There are also other simplifications that end up with similar results to various coefficient values. Many games use simply a linear (ZoomFov*pi/180)/(HipFov*pi/180) which is the same as a coefficient of 1 unless you use different FOV measurements for each. For example, Doom Eternal does this but using the 16:9 horizontal FOV (therefore equivalent to 178% vertical coefficient), and CS:GO also does this but using the 4:3 based horizontal FOV. This is why CS:GO's sens scaling is said to be the same as BF USA / CoD Relative 133% default coefficient , even though it doesn't actually use the same formula or a coefficient at all. It just does ZoomFOV/HipFOV (see line 556) where the FOVs are the 4:3 based radians instead of vertical degrees. There are also countless others than either use fixed multipliers so don't scale at all from hipfire FOV changes, or other calculations based off e or pi or anything else you could think of. In any case, the best use for this type of scaling is really for ADS / zoom within a game from whatever your hipfire sens is. You are pretty much always better off using a hipfire sensitivity that works optimally for type of navigation movements you need to do in a given game. It would probably be a bit silly to insist on using the same hipfire sens in Quake as is optimal in CS:GO, given the completely different aiming movements required, and between similar games but where the FOV cannot be exactly matched then 360 distance still probably makes the most sense for hipfire so your navigation is familiar to what you are used to.

The reason for the difference is due to the definitions of sensitivity and which one someone favours to recommend matching. DPI Wizard is referring to the 3D sensitivity in the game world - the "game sensitivity". Changing monitor size does not change the distance per count. If 1 count from the mouse = 0.0066 degrees turned in-game (i.e OW yaw value) then changing your monitor size doesn't change that. What Drimzi explains in the thread is effectively the 2D sensitivity within screen space, from the 3D projection of the game onto your monitor. Here, at any given FOV, a change in screen size will result in a different "pixels worth" of distance travelled in 2D "on your screen" at the crosshair. Because we perceive sens visually as the 2D image displacement (there is a non-visual perception also, such as the learned movement required for "off-screen aiming" - 180 degree turns, 90 degree flicks etc), this could be thought of more mathematically correct as "the sensitivity" and this is what "focal length scaling" preserves and why the calculator's output produces different values for your new screen size. Although gamers are used to "360 distance" as sensitivity, this is not really correct and is really a misnomer. The sensitivity of any function is a unitless ratio of the output to the input. If my input is 2 and my output is 3 of "something", then such a transfer function has a sensitivity of 3/2 = 1.5. The way we express sensitivity as a distance, is by framing it against a physical constant such as a DPI value (real-world distance along a flat 2D plane) against a yaw value (virtual 3D-world angle change), but you could replace the latter with the image velocity at screen centre which would also take into account the screen size and FOV. I actually agree that using focal length as the constant for sensitivity measurement makes more sense than using virtual degrees per count since we all play games on 2D displays, but I doubt the current convention will ever change. Anyway, bottom line is that I think your initial hunch was most likely correct for you, and your path of least resistance as far as adapting to your change in screen size is to not make any changes to your settings.

You have not specified what conversion method you are using, but assuming you are using 0% or some other monitor distance (as there would be no difference on 360 distance) then because the target screen is larger there is a different perspective, and this is what the calculator is compensating for with any monitor distance. The physical distance to the edge of a 24" screen is only 89% of that of a 27" screen. You don't have to match this, you can totally ignore the factor by setting both screens to the same size in the calculator. You will find your sensitivity feels different in some way regardless of what you do. There is never "true 1:1" matching between different FOV's or screen sizes as an absolute statement, only a "pick what aspect of conversion want to be 1:1". I am not sure what you mean by saying "everyone knows 1:1 sens is 37.89%" as this cannot be true for all definitions of "matched sensitivity". When I moved to a larger screen temporarily, I made an unscaled resolution that was 24" for 1st person shooters (with black bars) and then just used the 27" for the desktop and 3rd person / controllers games. If you do want to use the full 27" size for everything, then my advice would be to just adapt to the new focal length, you may find your brain just figures this out for you and it feels "the same" very quickly without any changes. You could do the opposite, and match the new 27" ADS focal length / monitor distance to your 24" hipfire sensitivity, but then the hipfire on 27" is going to be more sensitive vs ADS than it used to be, by a factor of 27/24 = 1.125x

At no point did you say anyone explained it well. You literally just said this: Now you're just playing fast and loose with the terms. If you don't know enough about something to offer any attempt to explain it yourself whilst simultaneously criticising the quality of other's explanations...then you don't understand it. I think that'd be fairly clear to pretty much anyone. Considering I've never had a conversation with you before in my life to my knowledge, I'll ignore the creepy bit and just skip to the part about being civil. If you think someone just having a giggle about your obviously silly comment is not being "civil" then you're going to be in for a rough time. I will give you one tip though, best not to make your first contributions to any community of zero value besides criticising those who are in fact contributing to it. A better way would be to say "I really find these explanations difficult to understand and there's gaps in my knowledge, could someone try explaining it a little simpler for me?" Besides that I won't be saying anything else on the matter, as Brandolini's Law will no doubt become more and more in effect.

"I don't understand this, but you're explaining it wrong" Nothing like reviving a two-year-old thread just to say the explanations within said thread suck. Thought I'd seen it all but apparently not lol

Then it does not matter as there is no transition in which to apply a timing to