High Dpi issues on old Games / Engines

[Quackerjack]

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
 

Spoiler

void CInput::GetMouseDelta( int nSlot, float inmousex, float inmousey, float *pOutMouseX, float *pOutMouseY )
{
// Apply filtering?
*pOutMouseX = inmousex;
*pOutMouseY = inmousey;
}

//-----------------------------------------------------------------------------
// Purpose: Multiplies mouse values by sensitivity. Note that for windows mouse settings
// the input x,y offsets are already scaled based on that. The custom acceleration, therefore,
// is totally engine-specific and applies as a post-process to allow more user tuning.
// Input : *x -
// *y -

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

Spoiler

// Apply filtering?

if ( m_filter.GetBool() )

{

// Average over last two samples

*pOutMouseX = ( inmousex + m_flPreviousMouseXPosition ) * 0.5f;

*pOutMouseY = ( inmousey + m_flPreviousMouseYPosition ) * 0.5f;

}

else

{

*pOutMouseX = inmousex;

*pOutMouseY = inmousey;

}

// Latch previous

m_flPreviousMouseXPosition = inmousex;

m_flPreviousMouseYPosition = inmousey;

}

//-----------------------------------------------------------------------------

// Purpose: Multiplies mouse values by sensitivity. Note that for windows mouse settings

// the input x,y offsets are already scaled based on that. The custom acceleration, therefore,

// is totally engine-specific and applies as a post-process to allow more user tuning.

// Input : *x -

// *y -

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

Edited March 14, 2023 by Quackerjack

[Quackerjack]

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

Edited March 15, 2023 by Quackerjack

[TheNoobPolice]

“To prove csgo is affected by windows registry settings with raw input enabled, all you have to do is enter bogus windows registry settings then disable raw input in game”

Flawless logic 

[Quackerjack]

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

Edited March 15, 2023 by Quackerjack

[RedX]

On 1/24/2023 at 10:03 AM, justtypingokok said:

Ok, so please answer my simple, exemplary question. I use 400 dpi, 2.6 sens, CS:GO of course. rawinput1 and all that needed stuff. I wanted to switch to 1600 dpi (and 0.65 sens obv) multiple times, but I just felt that my aim is off and im not confident about my movements. It wasn't caused by dpi deviations (cause irl 360 distances matched) and wasn't caused by shitty mouse (modded fk2 with g305 internals). My question is: is it really me having it hard to get used to the different way of my screen moving with 1600 etc, or... is it what you are trying to describe? Cause 0.65 x 0.022 doesnt look like a lot of decimals, so I should be fine. Also, why do you suggest using mouse-sensitivity website for that, when we can do simple calculations ourselves? (1600x400 -> 2.6/4)

Just a FYI,

Even if you had perfect conversion between between DPI / Sensitivity; Mouse sensors perform differently at different DPIs, and at different velocities.

IE:

400 DPI @ 2 Windows Sensitivity = 800 CPI
800 DPI @ 1 Windows Sensitivity = 800 CPI
1600 DPI @ .5 Windows Sensitivity = 800 CPI
3200 DPI @ 0.25  Windows Sensitivity = 800 CPI

 

For instance with the above table for a G304:
at 400 CPI, 10 IPS, it's 419.74 CPI = 839.48
at 800 CPI, 10 IPS, it's 837.57 CPI = 837.57

at 400 DPI
10 IPS, 9.33 offset = 18.66
50 IPS, 16.54 offset = 16.54

at 800 DPI
10 IPS, 9.2 offset = 18.4
50 IPS, 10.93 offset = 10.93

Going higher IPS, and higher DPI, depending on the mouse the differences can get much more dramatic. 
There usually a 'sweet spot' where the mouse seems to have the least amount of error. 

 

[justtypingokok]

12 godzin temu, RedX napisał:

Just a FYI,

Even if you had perfect conversion between between DPI / Sensitivity; Mouse sensors perform differently at different DPIs, and at different velocities.

IE:

400 DPI @ 2 Windows Sensitivity = 800 CPI
800 DPI @ 1 Windows Sensitivity = 800 CPI
1600 DPI @ .5 Windows Sensitivity = 800 CPI
3200 DPI @ 0.25  Windows Sensitivity = 800 CPI

 

For instance with the above table for a G304:
at 400 CPI, 10 IPS, it's 419.74 CPI = 839.48
at 800 CPI, 10 IPS, it's 837.57 CPI = 837.57

at 400 DPI
10 IPS, 9.33 offset = 18.66
50 IPS, 16.54 offset = 16.54

at 800 DPI
10 IPS, 9.2 offset = 18.4
50 IPS, 10.93 offset = 10.93

Going higher IPS, and higher DPI, depending on the mouse the differences can get much more dramatic. 
There usually a 'sweet spot' where the mouse seems to have the least amount of error. 

 

nah im adjusting it by moving on 50cm mousepad ingame to match the same stopping point on the wall

[Quackerjack]

---

 

Edited March 29, 2023 by Quackerjack

[Quackerjack]

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:

Spoiler

Csgo mouse code:

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:

Spoiler

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.

 

 

 

 

[Quackerjack]

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.

 

 

[DPI Wizard]

5 hours ago, Quackerjack said:

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.

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

[Quackerjack]

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?
 

 

 

Edited May 28, 2023 by Quackerjack

[DPI Wizard]

7 hours ago, Quackerjack said:

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?

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.

[Quackerjack]

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.

 

 

[Chief Blur Buster]

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?   

Edited May 29, 2023 by Chief Blur Buster

[Quackerjack]

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.

 

Edited May 29, 2023 by Quackerjack

[TheNoobPolice]

On 29/05/2023 at 08:29, Chief Blur Buster said:

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)

The only reason for your observations is because the Windows Enhance Pointer Precision (EPP) algorithm works on distance not speed.

The original documentation for the function (which was first designed for Windows XP) is here and there is a further accurate breakdown of the small changes applied for Windows 7 here. It has not been changed since.

You'll see there is no mention of dividing by the time between each actual poll time (i.e to find input speed) with this algorithm, because it does not happen. There is nothing inherently wrong with this approach -  in fact, with a mouse that has significantly variable polling stability (as even many "gaming" mice can often have), it will produce more stable gain through the transfer function and is undoubtedly the best approach for an office mouse use case. 

It should then be obvious though why 8000khz doesn't accelerate as much as 1000hz  - if someone is travelling in a car at a steady 10 km/h and only reports how far they have travelled after 1 hour, then the reported distance is 10 km (obviously). If the report is every millisecond, however, it would be just 2.8 millimetres every time.

If one samples any movement more times a second but doesn't divide by the time between the samples, then the distance each sample is smaller. If we base the input to somefunction() only from distance per report while we move at speed, then of course a higher report rate has a smaller input to somefunction().

The same thing applies with EPP. Since the sensitivity scale factor is derived from distance only, then if one was at 8000hz polling rate and 400 DPI, one will never experience any acceleration at all unless moving the mouse at least 20 inches per second or faster, as that is the required hand speed at that DPI & polling rate to get a single input with at least "2" counts in it in order to trigger a higher sensitivity on the acceleration curve (whereas if the user had only 500hz and a much higher DPI like 3200, then the sensitivity will begin accelerating at just 0.16 inches per second).

So this is the only reason why EPP scales differently as you change polling rate and it's intentional by design. It is nothing to do with worsening precision of the desktop cursor and it is not a poorly designed function technically. The only issues with it are that it is not adequately user configurable for power users via the interface, and there is no visualisation for the end user of how the cursor sensitivity scales without doing some math (which while not rocket science, is not the garden variety either).

[RedX]

On 5/29/2023 at 1:49 AM, Quackerjack said:

https://www.reddit.com/r/Diabotical/comments/ffbjss/robustness_of_diabotical_mouse_input_more/

It's an interesting test, but I wonder if there are other factors they're not considering like mouse clicks and mouse movements might be read at the time. Weapon attributes like cast time could effect where a shot is fired. Some games interpret input between frames. Or how a human can't go from x+0 to x+125 in a single step.

In the case of a real fast swipe, your going to be seeing 6ms+, or 10ms+ behind. And your click isn't going to register instantly. So in a real swipe, would you really expect to be seeing dead center before the click? Like wouldn't you be seeing before dead center? 

 

Mouse tester agrees with The Noob Police
800 at 1000Hz

7500 at 1000 HZ

7500 at 4000 HZ

 

Personally, I think Windows UI for mouse settings is kind of dated. It obfuscate information making it needlessly less functional. Users should be able to easily see, and set the multipliers for mouse sensitivity. As more people use higher DPIs, they're is going to be an increased need more granular control of mouse sensitivity settings. If they're worried about confusion, they could always hide it in an advanced button, or something. It would also be nice if it acutely showed PDI * sensitivity = ePPI.

 

Edited June 1, 2023 by RedX

[TheNoobPolice]

13 hours ago, RedX said:

Multiple points…

 

I think you’re right - from what I remember Diabotical has a multi-threaded option get mouse input, and the only reason to do that would be to get more frequent updates for e.g clicks vs for deltas and then coalesce at the start of each simulation frame. I feel like it’s not going to really make a difference in a real-world situation to anyone’s experience other than when testing with scripts though. Mouse movement data itself is just a serial stream so there is no point trying to multi-thread the acquisition of movement data.

And I agree that the UI aspect of all Windows mouse settings definitely needs improvement. There is also still a legacy bug with the scale factor when EPP is off and the multiplier is above 1 (some error with carrying remainders or extrapolation issue as the output is inaccurate - didn’t bother to reverse engineer what exactly, just can see that it’s incorrect).

I think it’s fine to have a slider with discrete notches for easy-mode, but no reason to not allow for manual input of float values also to allow scaling of DPI to any value without needing 3rd party kernel-mode filters. There should also be the option to adjust sensitivity by direction (vertical, horizontal, diagonal etc) by either individual component or whole vector built into the operating system, if for nothing else but adequate accessibility and for power users.

Anyway, last point is they’re some of the tightest distance plots I’ve ever seen you’ve just posted. Do you have a Razer motion sync sensor by any chance? I can only create plots that look that good if I write a smoothing function to put the mouse input through…

[RedX]

On 6/1/2023 at 12:14 PM, TheNoobPolice said:

Anyway, last point is they’re some of the tightest distance plots I’ve ever seen you’ve just posted. Do you have a Razer motion sync sensor by any chance? I can only create plots that look that good if I write a smoothing function to put the mouse input through…

I'm using a razer viper 8k. Which is a focus+ sensor, and has Motion Sync. The sensor seems to have better tracking in general, including at faster speeds. I haven't herd of any mouse smoothing issues with it.. 

I'm also using dedicate a USB 3.0 controller just for the mouse to reduce latency. (something I picked up from the BlurBuster forum) I've also made many of the suggestions in Calypto 8k latency guide to try and reduce system latency. I could probably do more, but I haven't lobotomized windows. 

But I haven't gotten to buttery smooth 8k. It might be a limit of my CPU, but I still have a few things to try. 

It might be interesting to try that test with q3a, and then trying to ask John Carmack about the results. 

Edited June 4, 2023 by RedX

[randomguy7]

On 6/3/2023 at 6:16 PM, RedX said:

I'm using a razer viper 8k. Which is a focus+ sensor, and has Motion Sync. The sensor seems to have better tracking in general, including at faster speeds. I haven't herd of any mouse smoothing issues with it.. 

I'm also using dedicate a USB 3.0 controller just for the mouse to reduce latency. (something I picked up from the BlurBuster forum) I've also made many of the suggestions in Calypto 8k latency guide to try and reduce system latency. I could probably do more, but I haven't lobotomized windows. 

But I haven't gotten to buttery smooth 8k. It might be a limit of my CPU, but I still have a few things to try. 

It might be interesting to try that test with q3a, and then trying to ask John Carmack about the results. 

just remember that motionsync only works on 4000 hz and below

Edited June 5, 2023 by randomguy7