Quackerjack

On 4/2/2021 at 10:39 PM, DPI Wizard said:

Well, Battlefield 2... It has the same issues.

Out of curiosity, are we talking about Windows acceleration or did the game itself program acceleration? The former would be easy to solve

12 hours ago, DPI Wizard said:

He is moving the mouse to keep the bot in the center. This is an effect of polling rate vs FPS, if you limit the FPS to 125 Hz it will look a lot smoother.

You are right locked fps to 125 stops the stutter. 
Back in days everyone was using 125hz polling rate since it was default. Also games with higher fps than 125. It’s funny I never noticed the stutter back then. 
I wonder if you guys noticed stutter with 125hz in the past.

Can someone explain why the models stutter with 125 hz? Even if you don’t move the mouse.

no bf4 uses vertical fov not horizontal. You have to put 73.74 in the game files to achieve 106.26 horizontal ingame for 16:9

Or just put 74 in the options menue, you can see the horizontal fov right next to it then

5 hours ago, sonorciff said:

So in my case, I can set the following values, and never need to touch scalar_1 through scalar_7, right?

mouse_use_per_scope_sensitivity_scalars "0"
mouse_zoomed_sensitivity_scalar_0 "1.004245"

Yes.

13 hours ago, sonorciff said:

So even if every value is the same, it is still needed?

If you want 0% mdv or mdh in apex legends you don’t have to change anything it’s the basic value 1.000000 or in your case (fov rounding from the game) 1.004245. And no you don’t have to set this value for all scopes. In this case it doesn’t matter. 

12 hours ago, Chief Blur Buster said:

I've been lurking the last while, but chiming in again:

Ideally, m_rawinput 1 makes it all moot.

For the most part, this recent discussion is probably a way to figure out how to make non-rawinput behave as good as rawinput.

However, make sure it's not caused by only the Pointer Precision setting.  That's one of the biggie interferer of slow-vs-fast flicks during non-rawinput mode. Especially on high-pollrate mice.  It's now a best practice to turn that goddamn setting off, even for Windows desktop use -- lest my desktop muscle memory starts  unconsciously interfering with my game-flick muscle memory. 

It really means the opposite, a "Worsen Pointer Precision" setting, on high Hz displays using high pollrate mice -- so even for Desktop use, DONT USE THAT SETTING if you're a high-Hz user or a high-poll user -- full stop.  The algorithm seems fine on your everyday DELL/HP 60Hz office monitor using the included 125Hz USB mouse on an Optiplex tower or boilerplate Lenovo laptop.... but, throw in your gaming Hz or gaming mouse, and it all becomes a big mess -- it's a great demo of really bad mouse mathematics.

I've even seen 2x speed mouse pointer differences with Pointer Precision setting.  You can easily notice it in Desktop by using an 8000Hz mouse running at 240Hz+ refresh rates. Use your mouse software to switch pollrate between 500Hz vs 1000Hz vs 2000Hz vs 4000Hz vs 8000Hz, and you will see that screen flick distance changes for the same hand-flick inch, due to how the mathematics in Microsoft's Pointer Precision behaves -- it becomes gigantic when it comes to comparing 1000Hz vs 8000Hz.   It even worsens more with higher poll and higher Hz (360Hz+). Ugly.  

Try it yourself: Turn that setting off, and turn off pointer acceleration in all mouse settings.  Now, flick the mouse 2 inches, observe how far pointer goes for 1000Hz vs 8000Hz. Same flick distance. Now turn on the setting. Flick 2 inches, observe how far pointer goes for 1000Hz vs 8000Hz. Massive difference (over 2x difference) in onscreen distance.  Turn the setting off, and 125Hz-vs-8000Hz is same flick distance, without weird effects.  So, don't even use the setting for desktop mouse pointer use if you're a high-Hz + gaming mouse user.

So for rawinput=OFF use cases, I deem "Pointer Precision" it the biggest interferer in mouse muscle memory in the escalating refresh rates and poll rates.  The Microsoft Pointer Precision algorithm is really wonky and produces very heavily non-linear behaviors.  It doesn't let you preserve muscle memory across per-application poll rate profile (e.g. using 2000Hz-8000Hz in games that don't overload with it, and using 1000Hz in other games)

I simply mention this, as changing multiple settings at once, can cause incorrect blame to be assigned.  Also re-verifying the enablement of rawinput is important; as configuration settings don't always "take" on the first try, e.g. forgetting that game already running in background, when you're doing hundreds of passes in benchmark work duty, when a tester intern hired by some youtuber is doing hours of boring repetitive tests of different settings -- hey, it happens...

So -- to doublecheck everything -- Is this possible that the pointer errors is completely attribute to the "Pointer Precision" algorithm?  Or do still clearly see issues that can be definitively traced to CS:GO side?   

For me its definitive a csgo issue that happens with no other game on my pc. I googled this up since 2014 stopped playing and came back to csgo and noticed it right away. There so much topics on the internet about this issue on csgo and a lot said that is input lag which was proven wrong:

or this:

Note: I had this problem before i saw this topics i googled it later in order to fix it.

Till today nobody knows for sure whats going on. And i wonder now if some users just have this problem and some not cause DpiWizard said it works fine for him and i highly trust his statements. But then still for me its hard noticeable.

Yes accel should and is off with useforcedmparms and m_mousespeed 0 + rawinput on.  I also have no acceleration on the default settings just an heavy mouse it feels like its delayed or muddy at micro movements.
 

In css source I feel no delay on small precise mouse movements in csgo I do. 
 

The only big change in the mouse code I found is this: 

In the activate mouse for,

csgo: https://github.com/perilouswithadollarsign/cstrike15_src/blob/master/game/client/in_mouse.cpp

void CInput::ActivateMouse (void)
{
    if ( m_fMouseActive )
        return;

    if ( m_fMouseInitialized )
    {
        if ( m_fMouseParmsValid )
        {
#if defined( WIN32 ) && !defined( USE_SDL )
            m_fRestoreSPI = SystemParametersInfo (SPI_SETMOUSE, 0, m_rgNewMouseParms, 0) ? true : false;
#endif
        }
        m_fMouseActive = true;

        // re-center the mouse if we're controlling the camera with it, otherwise just reset the cursor
        if ( GetPerUser().m_fCameraInterceptingMouse || cl_mouseenable.GetBool() )
            ResetMouse();
        else
            g_pInputSystem->ResetCursorIcon();

        g_pInputStackSystem->SetCursorIcon( m_hInputContext, INPUT_CURSOR_HANDLE_INVALID );
#if defined( USE_SDL ) || defined( OSX )
        int dx, dy;
        engine->GetMouseDelta( dx, dy, true );
#endif
        ClearStates();

css: https://github.com/ValveSoftware/source-sdk-2013/blob/master/sp/src/game/client/in_mouse.cpp

void CInput::ActivateMouse (void)
{
    if ( m_fMouseActive )
        return;

    if ( m_fMouseInitialized )
    {
        if ( m_fMouseParmsValid )
        {
#if defined( PLATFORM_WINDOWS )
            m_fRestoreSPI = SystemParametersInfo (SPI_SETMOUSE, 0, m_rgNewMouseParms, 0) ? true : false;
#endif
        }
        m_fMouseActive = true;

        ResetMouse();
#if !defined( PLATFORM_WINDOWS )
        int dx, dy;
        engine->GetMouseDelta( dx, dy, true );
#endif

        // Clear accumulated error, too
        m_flAccumulatedMouseXMovement = 0;
        m_flAccumulatedMouseYMovement = 0;

        // clear raw mouse accumulated data
        int rawX, rawY;
        inputsystem->GetRawMouseAccumulators(rawX, rawY);
    }

Edit: I added a screenshot do you guys also have the command cl_mouseenable on 0? Somehow it says default is 1 but when i try to change it says the command is unknown?

Also i want to add this: https://www.reddit.com/r/Diabotical/comments/ffbjss/robustness_of_diabotical_mouse_input_more/

So maybe its related to fps and thats why its different.

8 hours ago, DPI Wizard said:

I tested both the smallest amount of movement (1 count) and full 360 distance, they're all absolutely the same. I don't have the equipment to test latency in millisecond accuracy other than by feel though, so if it's i.e. 20 ms vs 25 ms I wouldn't know. But if it's significant I would definitely detect it by hand. I would definitely know 25 ms from 100 ms etc.

So if this tweak does improve it from say 25 to 20 ms (note, these are just random numbers put up by me), it's probably worth it, but as far as I can tell there's no discernible difference.

A caveat though: These tweaks might for all I know affect some hardware/software/drivers differently, so if your setup has an issue, this might solve it.

Thank you, this tweak with -useforcedmparms returns back to the old engine behaviour (goldscr) if you leave  the m_mouseaccel1/2 and m_mousespeed values on default.

if ( CommandLine()->FindParm ("-useforcedmparms" ) )
    {
#ifdef WIN32
        m_fMouseParmsValid = SystemParametersInfo( SPI_GETMOUSE, 0, m_rgOrigMouseParms, 0 ) ? true : false;
#else
        m_fMouseParmsValid = false;

It makes sure to use the spi_getmouse function from windows. Which on default is coded as this in the goldsrc engine:

originalmouseparms[3], newmouseparms[3] = {0, 0, 1}

 See: https://www.drdobbs.com/windows/some-things-ive-learned-about-win32-game/184410376#l4

The first two 0 stands for the mousethreshold1/2 and the 1 for the mousespeed. With this csgo will turn mouse acceleration as on but get by passed with m_rawinput 1 so there is no acceleration in game but on windows and the game menu. (see cs 1.6 which behave exact like that)

Csgo Vanilla is therefore coded as m_fMouseParmsValid = false and the false is referring to 0.0 for the mousethresholds. The m_mousespeed i assume is also set to 0.0 atleast the console accept this as the lowest value.

static ConVar m_mousespeed( "m_mousespeed", "1", FCVAR_ARCHIVE, "Windows mouse acceleration (0 to disable, 1 to enable [Windows 2000: enable initial threshold], 2 to enable secondary threshold [Windows 2000 only]).", true, 0, true, 2 );
static ConVar m_mouseaccel1( "m_mouseaccel1", "0", FCVAR_ARCHIVE, "Windows mouse acceleration initial threshold (2x movement).", true, 0, false, 0.0f );
static ConVar m_mouseaccel2( "m_mouseaccel2", "0", FCVAR_ARCHIVE, "Windows mouse acceleration secondary threshold (4x movement).", true, 0, false, 0.0f );

So the new code should look like this:

originalmouseparms[3], newmouseparms[3] = {0.0, 0.0, 0.0}

This shows how windows handle the spi_setmouse function, in this you see that the params [3] have set to 0, 0, 0 so windows set the linearmousescale:
 

void WIN_UpdateMouseSystemScale()
{
    int mouse_speed;
    int params[3] = { 0, 0, 0 };

    if (SystemParametersInfo(SPI_GETMOUSESPEED, 0, &mouse_speed, 0) &&
        SystemParametersInfo(SPI_GETMOUSE, 0, params, 0)) {
        if (params[2]) {
            WIN_SetEnhancedMouseScale(mouse_speed);
        } else {
            WIN_SetLinearMouseScale(mouse_speed);
        }
    }
}

Thats why i suggested to set -useforcedmparms and m_mousespeed 0. And with this you changed how the game handles the mouse input and in theory it should change the mouse input.

I agree with m_rawinput 1 all that shouldnt matter right? It should bypass the windows settings.

Since you said you dont feel any difference i need to read more about rawinput cause for me the change in small mouse movements is noticeable before the mouse felt heavy and delayed.

2 hours ago, DPI Wizard said:

In CSGO, right? Tested it now, everything is exactly the same with or without these settings.

Yes in csgo. The cm/360 stays exact the same. But the perceived sensitivity for small movements become noticeable „faster“, directer. Like it’s easier to track targets or adad spammers.
 

I appreciate that you test it wizard  What did you test exactly?
 

Feedback desired:

For ppl who still feel that csgo has an heavy input,

Try -useforcedmparms with m_mousespeed 0.

Source engine forces their hardcoded mouse parameter to false.

With useforcedmparms you use the mouse parameters and m_mousespeed 0 sets the enhanced pointer precision off.

static int restore_spi;
static int originalmouseparms[3], newmouseparms[3] = {0, 0, 1};

#ifdef WIN32
		m_fMouseParmsValid = SystemParametersInfo( SPI_GETMOUSE, 0, m_rgOrigMouseParms, 0 ) ? true : false;
#else
		m_fMouseParmsValid = false;

The default settings are mouseparmsvalid false.

Now you are able to compare mouse behaviour without restarting the game.

To set the mouseparms to false (default) just enter m_customaccel1 0.0, m_customaccel2 0.0 and m_mousespeed 0.0.

Compare with small movements like circles and micro adjustments.

update:

Yes iam still on this and now people say even in CS2 the recoil compensation feels different to csgo which makes me wonder what they changed. Note: The recoil pattern is still the same so a change in the mouse behaviour must be the cause.

In CSGO you have the ingame commands:

m_mousespeed: Controls the enhanced mouse pointer precision

m_mouseaccel1/2: Controls the accel Threshold 1/2

m_rawinput: Should bypass all Windows mouse settings

With -useforcedmparms in the launch options this ingame parameters (except rawinput) are in use. (Note even without -useforcedmparms people notice a different beetween m_mousespeed 1 and 0)

See this code:

if ( CommandLine()->FindParm ("-useforcedmparms" ) ) { #ifdef WIN32 m_fMouseParmsValid = SystemParametersInfo( SPI_GETMOUSE, 0, m_rgOrigMouseParms, 0 ) ? true : false; 

Now m_mousespeed 0 should turn the mouse acceleration (enhanced pointer speed) off. But my previous test with all smoothmousecurves set to 0 showed this is not the case, your mouse pointer dont move at all and that means csgo still force mousespeed 1. If you start a new game now via the ingame console the command m_mousespeed 0 overrides mousespeed 1 and your mouse start working again.

This shows that the source engine still has their hardcoded mouseparameters (0 0 1). Both 0 refer to the accel Thresholds and the 1 to the mousespeed. And additionally csgo add this parameters as ingame commands.

So first we want to make sure that all ingame mouseparameters are not in use. This can be achieved by doing this:

1. Step: -useforcedmparms in the launch options

2. Step: m_mousespeed 0 in console

3. Step: m_mouseaccel1/2 0.0 in console (make sure its 0.0 not 0)

4. m_rawinput 1

Fore more info:

static ConVar m_mousespeed( "m_mousespeed", "1", FCVAR_ARCHIVE, "Windows mouse acceleration (0 to disable, 1 to enable [Windows 2000: enable initial threshold], 2 to enable secondary threshold [Windows 2000 only]).", true, 0, true, 2 );

static ConVar m_mouseaccel1( "m_mouseaccel1", "0", FCVAR_ARCHIVE, "Windows mouse acceleration initial threshold (2x movement).", true, 0, false, 0.0f );

static ConVar m_mouseaccel2( "m_mouseaccel2", "0", FCVAR_ARCHIVE, "Windows mouse acceleration secondary threshold (4x movement).", true, 0, false, 0.0f );

if ( CommandLine()->FindParm ("-useforcedmparms" ) ) { #ifdef WIN32 m_fMouseParmsValid = SystemParametersInfo( SPI_GETMOUSE, 0, m_rgOrigMouseParms, 0 ) ? true : false; 

Second we want no engine mouse parameters. This can be done by this:

Add next to the -useforcedmparms launch options:

-noforcemspd (dont set the coded mousespeed value)

-noforcemaccel ( dont set the coded thresholds values)

Fore more info:

if ( CommandLine()->FindParm ("-noforcemspd" ) ){m_rgNewMouseParms[ MOUSE_SPEED_FACTOR ] = m_rgOrigMouseParms[ MOUSE_SPEED_FACTOR ];

if ( CommandLine()->FindParm ("-noforcemaccel" ) ){m_rgNewMouseParms[ MOUSE_ACCEL_THRESHHOLD1 ] = m_rgOrigMouseParms[ MOUSE_ACCEL_THRESHHOLD1 ];
												  m_rgNewMouseParms[ MOUSE_ACCEL_THRESHHOLD2 ] = m_rgOrigMouseParms[ MOUSE_ACCEL_THRESHHOLD2 ];

And now you ask why? I use rawinput so windows dont affect my sensitivity. I can tell you this is not true. Test it yourself, move your mouse in slow small circles and shoot some bots with large and close flicks without the steps above.

Now do the steps i suggest to you. You will see how the sensitivity feels different.

Check this topic out. Drimzi gives in this a formular to calculate new fov or new sens.

One more queation Default sensitivitys are working good for 800 DPI mouse or 1600 ? Becouse for example if defaults are good working on 800 DPI mouse it means while i was 27 inch 1080p i was also ising 800 DPI for gaming but now 4K on desktop need 1600 dpi does it means default sensitivitys in games will be fast for me ? And i need to half them ?

You can use this site: https://www.admiralbumblebee.com/general/2017/12/08/Transfer-mouse-CPI-settings-to-a-different-resolution-device.html or the calculator to get your new dpi for the desktop. Than use  the calculator to change the sensitivity to your new dpi.

As i Understand i need to Half the sensiti ity in every game becouse i have now 1600 DPI on mouse , for games 55 inch or 27 inch does not means anything am i right ? And one moee question i was using windows 115% scaling on 1080p now on 4K i am using 150% scaling what does it means ? 

If you go from 800 dpi to 1600 dpi you usually have to half the sensitivity. But do this with the calculator cause on some games halfing the sens doesnt work. Adjust the sens to the monitor size is preference. Some ppl feel the need to do some dont. The windows scaling affect the windows desktop sensitivity not ingame afaik.

---

Please @TheNoobPolice i appreciate your knowledge. But at some point you have to start test things.

When enhanced pointer precision is disabled in windows the smoothmousecurves are not in use. With all smoothmousecurves set to 0 you can see this. Your mouse still working.

Csgo should also use the windows settings with m_rawinput 0. But somehow you cant move your mouse with smoothmousecurves set to 0 and NO enhanced pointer precision activated.

I run in a bug which set csgo sens to 0.000010 so this is not the prove sadly

And finally to prove csgo is influenced by the smoothmousecurves use the Curve0.reg and type ingame m_rawinput 0. Now you cant move the mouse even when enhance pointer precision is disabled so the smoothmousecurves shouldnt take any effect.

Note: In CSS you can perfect use the mouse with rawinput 0.

That means csgo is still using the smoothmousecurves even if m_rawinput 1 is set.

I cant wait till you test this @DPI Wizard

Csgo sensitivity details update.

Many users have given feedback that the sensitivity in csgo is different than in other source games. There were many suspected reasons such as m_pitch 0.022000 is different from 0.022, m_rawinput is bugged, your electricity has a probem up to settings in windows and bios.

Here is the csgo mouse code: https://github.com/perilouswithadollars ... _mouse.cpp
 

The issue is that Csgo uses mouse filtering from windows by default even when m_rawinput 1 is set.  In previous cs versions you had an intern filter called m_filter.

Here is the mouse code from cssource: https://github.com/ValveSoftware/source-sdk-2013/blob/master/sp/src/game/client/in_mouse.cpp

The only way to disable filtering from windows is to disable all smoothmousecurves to 0. I always wonder why this curves arent set to 0 when enhanced pointer precision is turned off.

Warning: Don't enable enhanced pointer precision when all values from the smoothmousecurves set to 0.

I created some reg files for this how you can test it:

Curve0 is the fix to set all smoothmousecurves to 0

CurveXPFix is the old mouse fix which disabled mouse acceleration on windows xp.

CurveWin10Default to restore the default curve if you dont like it.

You will see that all options feel different ingame.

Remember: If you change the reg. file you have to restart your pc or logout user.

Curve0.reg CurveXPFix.reg CurveWin10Default.reg

35 minutes ago, TheNoobPolice said:

You literally just pasted a huge quote from him where he is talking about that exact thing and you have mentioned repeatedly about changing the "smoothmousecurves to 0" which is "the MarkC fix" . No one needs to do that anymore, at all. Like ever. It's a decade out of date. People changing SmoothMouseXCurve and SmoothMouseYCurve in the registry aka MarkC fix as a routine habit on Windows installs are simply copy/pasting decades-old internet advice. Doing so may even break things if people mess with stuff they don't understand. Raw Input is there for a reason.

Off-topic. I never said anything about cs source or 1.6. Its also completely irrelevant to anyone playing csgo, which is the entire point of the discussion from the statement "CSGO has 100% FAIL sensitivity". False. It doesn't. If you wanted to talk about cs source or 1.6 and their specifics you could have started a thread doing so.

Fix what? There's a reason the entry on this website says only this for CSGO:



And it doesn't also say ensure you have smoothmousecurves set to 0 and all those launch arguments you mention. Because it is not required.

But up to you man, if you want to ignore the relevant game engine code directly shown to you, ignore a video in this thread showing the input is not smoothed or accelerated by the owner of this website you are subscribed to, and instead go by  "a lot of people feel"....then good luck. I've tried to help you with this to make you see the game is fine but if you insist on inventing problems that you then have to work around there's nothing anyone can do about that.

MarkC fix doesnt change the smoothmousecurves to 0 if it would do that you wouldnt be able to move your mouse when a game set the EEP on.

I literally discribed all steps how you can see that windows influence the sensitivity. I also linked sources that shows that the engine is responsive for this hardcoded values and that there are still hardcoded values.

As i mentioned csgo is based on source which is based on goldscr which is based on halflife engine. And all have the inhert bug that sets mousespeed 1. Thats why i mentioned css and cs 1.6 here. I also never said this game has mouse acceleration. I said windows affect the sensitivity cause this hardcoded number mousespeed 1 is set in the engine.

Also ccs uses launch options by default and csgo dont use them. Both games have the options rawinput btw. And yes the reason why css has defaulted launch options is because it wasnt released with m_rawinput which was added later.

So its not false. If you would tested it (i think you dont even play csgo) you would see iam right. I mean it doesnt hurt to try it out and set the launch options. And again its not about right or false. Its for the ppl to get a responsive mouse in this bugged game.

And in my post i said i used the smoothmousecurves for testing. I dont think that they are necessary if -usedforcedmparms -noforcemspd and -noforcemaccel is set. I just left them to 0. But setting smoothmousecurves to 0 was needed to show that csgo dont use the launch options by default.

47 minutes ago, TheNoobPolice said:

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.

Its not if you would tested it by yourself. I never talked about m_customaccel, its clear that this is an command to activate acceleration from the game.

Also if you say m_rawinput 1 ignores all that this doesnt hurt if anyone gonna try it. 

You cant deny that cs source use the launch option by default and csgo not with my testing above.

I never said use markc mouse fix? Why you talk about that? Do you even read and try things?

And the insinuation that i do this for gaslighting or to be right is a bad joke. I do this cause a lot off people feel that the sensitivity in csgo is off and i want to share the way how to fix this.

Quoted from MarkC:

-noforcemspd (or no launch options) means: Do not force EPP ON. If EPP is on on the desktop, it will still be on in-game. (Do not force EPP ON does not mean the same as Force EPP OFF.)

-useforcedmparms means: Force EPP to the m_mousespeed ConVar. Since m_mousespeed is always = 1 (a bug), EPP is then forced ON. No existing option forces EPP OFF.

This is half true: If useforcedmparms is set and m_mousespeed 1. (default windows regedit) no EPP is on with m_rawinput 1. If you set rawinput 0 EPP will be set! When now on this setup m_mousespeed 0 is used the EPP is off with no matter what rawinput is set to.  So you can set it to 0.

And here comes the bug:

When useforcedmparms force EPP to the m_mousespeed ConVar u should be able to move the mouse in csgo with smoothmousecurves set to 0 and m_mousespeed 0. And you should not be able to move the mouse in cs source with useforcedmparms and m_mousespeed 1.

Back when Windows 95 and 98 were as good as it got, Windows Control Panel allowed you to set the "mouse speed" using a 7 position slider. There was also a system function : SystemParametersInfo(SPI_SETMOUSE, ...) so that a program could set the same. The Windows 95/98 "mouse speed" slider was not like we have now: it actually set acceleration. Accel was calculated using two threshholds. At one mouse-speed threshhold the pointer-speed would suddenly double, and at the next threshhold the speed would suddenly quadruple. At the left-most 'Slow' setting, there was no accel and pointer response was 1-to-1. As you moved the slider to the right, accel is turned on and the threshholds were changed so they cut in earlier. There is a graph showing the sudden changes here: Windows pointer speeds (translated from Japanese) Internally, the accel was controlled by a parameter called 'MouseSpeed' and the threshholds were called 'MouseThreshold1' (the doubling one) and 'MouseThreshold2' (the quadrupling one). When MouseSpeed=0, no accel was applied. When MouseSpeed=1, only the doubling threshhold was used. When MouseSpeed=2, both threshholds were used. See here: MS TechNet>MouseSpeed. Needless to say, the sudden jumps when the accel kicked in and the pointer speed suddenly doubled or quadrupled was not good for game play. The developers of Quake had a fix to the accel problem: They called the SystemParametersInfo(SPI_SETMOUSE, ...) function to try and turn accel off. On Windows 95/98/2000 their fix worked! But it had a hidden problem. They set the accel threshholds to double at a threshhold of zero (MouseSpeed=1, MouseThreshold1=0). They should have set the accel to not double at all (MouseSpeed=0). On Windows 95/98/2000, with Quake setting MouseSpeed=1, MouseThreshold1=0 there was no accel felt, because ALL mouse input was doubled, so response was linear. Why did Quake choose that setting? Maybe they read this MS article: How to disable mouse acceleration. That article says to set MouseSpeed to 1 or 2. They say 1 or 2 because the user can already use the Control Panel to set MouseSpeed=0, but for some users that makes the mouse too slow, so MS suggest 1 or 2 in their article. In Windows 2000, mouse pointer speed was changed. The existing accel was moved from the 95/98 slider to a new 'Acceleration' section, with 4 option buttons: None, Low, Medium, High. The new replacement pointer speed slider was an 11 position slider (and internally known as 'MouseSensitivity'). (Things get dangerous here, because now the Windows MouseSpeed setting controls acceleration, and the MouseSensitivity setting controls speed!) Quake using MouseSpeed=1 to 'disable' accel was a problem waiting to happen when Windows XP changed the way it handled accel. Windows XP does not use the threshholds, but instead has a checkbox: 'Enhance pointer precision' (EPP) to turn accel on. They mapped the new EPP checkbox to the existing Windows 95/98/2000 MouseSpeed accel setting. Now when Quake tries to disable Windows accel by setting MouseSpeed=1, MouseThreshold1=0, it instead turns accel ON! At this point people freak out and CPL comes to the rescue with the CPL Mouse Fix and then later Cheese with a much improved mouse fix and Aion/Anir with his accelfix and wcafix... Valve use the Quake engine for their new HalfLife/CounterStrike 1.6 games and inherit the problem. What do they do to fix it? For compatibility reasons, they don't fix it, they just a add an option to work around it. They add a -noforcemspd launch option to NOT set MouseSpeed=1. They add a -noforcemaccel launch option to NOT set the MouseThresholdN values. They DO NOT add any option to disable accel, or fix the Quake code that tried to disable accel; the user must disable EPP themselves. Valve create the Source engine which inherits the problem. What do they do to fix it? They make -noforcemspd and -noforcemaccel the DEFAULT options; By default Source games do not set MouseSpeed to anything. For compatibility reasons, they add a new option -useforcedmparms which reverts to the older HalfLife engine behaviour. - MarktheC, creator of MarkC Mousefix

And again a mistake, when source set by default the noforcemspd and the noforcemaccel why you cant move the mouse in csgo with mousesmoothcurves set to 0?  But infact you can move the mouse in cs source! Cause Csgo dont has this launch options by default and so this mouse parameters set in the engine affect the sensitivity.

If you follow the steps i mentioned you can cleary see this is true, no placebo, testable and provable.

In short, if you want a 1:1 unsmoothed sensitivity in csgo (same goes for apex legends) you have to set: -useforcedmparms (allows the use of noforcemspd and noforcemaccel), -noforcemspd, -noforcemaccel in the launch options. Use m_rawinput 1 and m_mousespeed 1.

And to be 100 percent sure set all smoothmousecurves to 0 (i dont know if this is than still necessary i changed the smoothmousecurves for testing and leaved it to 0)

https://github.com/ValveSoftware/halflife/issues/1793 yes this is 1.6 again but still today people claim that they have acceleration even with m_rawinput 1.

And still there is something wrong in csgo.

I just downloaded cs source to compare to csgo which is the same engine.

When all mousesmoothcurves set to 0 and -useforcedmparms is set in csgo you cant move the mouse.

When all mousesmoothcurves set to 0 and -useforcedmparms is set in source you can move the mouse.

And i dont change this values arbitrarily. Mousesmoothcurves set to 0 means no acceleration would be apply.

https://forums.blurbusters.com/viewtopic.php?f=10&t=8482&start=10

1 hour ago, justtypingokok said:

I haven't analysed nor tested anything here, but just from the first glance - yea, you might feel some differences starting from the welcome screen cause you do realize that actually MENUS in cs:go are not affected by rawinput? Same applies for ingame buy menu. So if you change windows multiplier for example, you will feel the difference in menus, but not in aiming ingame. So that might change some of your theories, just adding it here for now.

You are absolutely right on that point. I just mentioned it so people see that there things begin to change and everything is setup correctly. Still questionable is that you cant move your mouse in the menu when smoothmousecurves set to 0, -useforcedmparms is in use and m_mousespeed is set to 0. Which should not activate the hardcoded mousespeed 1 from the engine. It is also clear why you can not move the mouse with this setup. The hardcoded number mousespeed 1 is forced and with smoothmousecurves zero you get 1*0= 0 mousespeed.

The thing is csgo (source engine from 2004) is based on the goldscr engine from 1998 which cs 1.6 is on. Extra info goldscr engine is based on the quake engine which always had the bug with the hardcoded mousespeed 1 and thats why the cpl fix,markc etc came. (this hardcoded number was never fixed till today in source its hardcode mousespeed 1).

And csgo is using by default mouse parameter -noforcemspd and -noforcemaccel. These commands tell the game to not set the windows MouseSpeed (enhanced pointer precision) and to not set the mouseThreshold 1 and 2. You can see this in the ingame commands from csgo m_mousespeed, m_mouseaccel1 and m_mouseaccel2.

Valve says that m_mousespeed 0 is accel off, m_mousespeed 1 is accel on and m_mousespeed 2 is accel on with the use of the thresholds. Questionable why m_mousespeed 1 is the default here.

If you set all smoothmousecurves to 0 and use the launch option -useforcedmparms you arent able to move the mouse. Even if you set m_mousespeed to 0 in csgo which should mean noforcemspd (noforcemousespeed) you cant move the mouse so that means m_mousespeed cant be set to 0. In order to make your mouse work again you have to set additionally -noforcemspd in the launch option.

So why there is a command m_mousespeed in the game which is set by default to 1 and cant be disabled? And also we know the engine is still responsive to mouse parms even when raw input is set? That means m_mousespeed 1 calls the smoothmousecurves from windows in a strange way and can just set to 0 when all smoothcurves are set to 0.

28 minutes ago, TheNoobPolice said:

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

I disagree with your first sentence. If you set the smoothmousecurves to 0 (restart pc to take effect) and open cs 1.6 you are not able to move your mouse even rawinput 1 is set. Same happens when you use -useforcedmparms in csgo.

1) agree

2) agree

3) You didnt test it i guess it

 

3 hours ago, Chief Blur Buster said:

How many mice have you tried at 1600?  

1600 may have very well been fine in a specific same game engine in the 1024x768 60Hz era, but remember the resolution race concurrently with the refresh rate race, amplifies differences between 800 and 1600, by making flaws more human-visible on today's esports-standard 1080p 240Hz.  Things are even more visible in the 1440p 360Hz LCD or 1440p 240Hz OLED era.  I currently have 240Hz OLED prototypes here, too. 

This leads to a very apparent mysterious observed real-world-user migration to a sweet-spot DPI for older game engines (to our aghast dissapointment).  It's easier to feel differences now with the fluctuating mouse report rates from 0 to 1000 and down back to 0 as you move with mouse varying speeds through the dpi points of your current dpi setting.  The more number of refresh cycle opportunities, the frames per second opportunties, COMBINED with the higher resolution (= bigger onscreen pixels per inch of mouseturn movement = easier to see varying step distances, depending on fixed/moving objects or fixed/moving eye gaze). 

And remember, even if you do 100fps at 240Hz, those 100fps visually round off more accurately to the correct refresh cycle, in relative-time mousetime:photontime than it did on 100fps 60Hz.  Given you've forced a 16.7ms granularity AND 16.7ms of motion blur that throws a fog screen at mouse problems or mouse setting problems or other relevant refresh rate race variables. 

Today, thanks to higher resolutions and higher refresh rates, there is less of that "fog" now on displays and on current GPUs than there was in 2006.  For you, 400dpi may have very well been less than 1 pixel step per mouseturn movement at yesteryear sensitivity settings at yesteryear computer resolutions, but when we're facing tomorrow's 4K esports in its monstrous eyes, those step distances become bigger shark bites now.  The same degree of mouseturn is way more pixels at the same framerate too. 

Yes, now with today's powerful GPUs, you can spew more framerate to compensate for those coarse mouseturn or pan step distances, but any problems in that, can still manifest itself in multiple ways, such as more rapid buildup of math rounding errors (in specific games), especially in engines that never were originally tested at framerates of a future decade.  And also that, high frequency jitter creates extra display motion blur that throttles differences between Hz (e.g. 240Hz-vs-360Hz).  There's multiple concurrent and simultaneous problems that occur at the same time, and it's hard whac-a-mole all of them out. 

(That's also part of the reason of the microsecond timestamps mandated at sensor level in the proposed HD Mouse API, to punch through all the noise inside the chain, whether be cable packet jitter or performance fluctuations in the system, etc).  We just know that laboratory prototype displays need it, even if we don't need it for current esports displays.  Today's lab refresh rates are tomorrow's esports refresh rates, after all.

It really amplifies the problems of the refresh rate race and the resolution race, so the claims of "solutions looking for a problem" is just "Humans cant see 30fps-vs-60fps" garbage speil at this stage, dead horse in current researcher circles on my end, while other communities are still fiercely debatey mcdebateface continuing to debate, as we look from a distance.  But we are, indeed, willing to learn from your other amazing skills, because researchers like me aren't esports atheletes ourselves, as a nuts-and-bolts role in the display engineering industry.  But I'll unceremoniously do line-item callouts, walking away after dropping my microphone.

Many are quite terrible at high DPI but the newest sensors have become really good at 1600 and so, the blame by some of us has begun shifting further up the chain (aka game engine).  It takes only one math weak link and I suspect that people I talked to is only speculating where it is, but right now more esports-industry researchers have begun blaming the engine for weaknesses that only shows up in the current refresh rate race.  I wish we could all come to the same songsheet or agreement, mind you. 

Mind you, I haven't personally looked at the leaked CS:GO source code to Sherlock-Holmes the bleep out of it, but I bet someone else in the world is itching to.

I don’t lie, I tried more than 20 from 2014 - 2021 than I stopped. (indcluded more than 10 different mousepads soft hard and hybrids) 

Atm iam on the pulsare xlite v2. I only played csgo and some apex legends during this time. Since 2 months now iam playing Kovaaks. And noticed the mouse feeling is so sharp and direct. So I think there is smth wrong in csgo.
 

But let me tell you after disabling all mousecurves in the regedit like I mentioned in my post before the wonky feeling went away for me in csgo. Iam 100 percent sure the smoothmousecurves affects the mouse in csgo. This would also explain why people notice differences in mouse behavior between different windows versions. 

Here is a theory about the mouse sensitivity in csgo. The source engine is based on the halflife engine, which has fixed mouse parameters like mousespeed 1. I think csgo still enables thes mouse parameters, although m_rawinput 1 should bypass them. A halflife modder has already confirmed this:

SamVanheer commented on Jan 16, 2019
The engine handles the raw input cvar, but the game is responsible for those command line parameters. Even if raw input is turned on it will still apply those settings, which affect how the OS processes mouse input before the engine handles it.

MarkC:

They make -noforcemspd and -noforcemaccel the DEFAULT options; By default Source games do not set MouseSpeed to anything. For compatibility reasons, they add a new option -useforcedmparms which reverts to the older HalfLife engine behaviour.

Easy test: Set in regedit smoothmousexcurve and smoothmouseycurve all to zero and use the launch options -useforcedmparms, now you cant move your mouse in csgo even with raw input. But wait why not set m_mousespeed 0 so csgo dont use the windows accelcurve? .... Dont work even with m_mousespeed 0 which tells windows not to use the smoothmousecurve settings you cant move your mouse.

Same happens in cs 1.6. Without launch options you cant move your mouse when smoothmousex-ycurve is set all to 0. So m_rawinput doesnt bypass windows.

In short: Set in regedit all mousecurves to 0. Restart your pc, and enjoy the first time csgo with right mouse input. You will feel it right on the start in the welcome screen that the mouse is super responsive now.

@DPI Wizard

@TheNoobPolice

@Chief Blur Buster

@MacSquirrel_Jedi

Sources:

https://www.hltv.org/forums/threads/391206/m-mousespeed-1-or-0

https://forums.blurbusters.com/viewtopic.php?t=9769

https://github.com/ValveSoftware/halflife/issues/2087