Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account


Photo

Any way to cannibalize the Windows 2000 mouse driver?

- - - - -

  • Please log in to reply
57 replies to this topic

#26
ownage11

ownage11

    Newbie

  • Member
  • 13 posts
  • OS:Windows 7 x64
  • Country: Country Flag
Thank you jaclaz, I'm looking on it right now.

Edited by ownage11, 04 June 2012 - 11:03 AM.



How to remove advertisement from MSFN

#27
jaclaz

jaclaz

    The Finder

  • Developer
  • 13,994 posts
  • OS:none specified
  • Country: Country Flag

Thank you jaclaz, I'm looking on it right now.
if I used to play with MouseThresHold1&2 where exactly I need to change if I want to get the same effect?

No idea, try re.reading this thread starting from:
http://www.msfn.org/...post__p__994279
and see if you can find a suitable setting.

The referenced MS article:
http://technet.micro...y/cc978664.aspx
seems to me clear enough, though I'll have to to re-read it and MarkTheC posts several time to be able to add a tentative to the spreadsheet. :unsure:

jaclaz

#28
jaclaz

jaclaz

    The Finder

  • Developer
  • 13,994 posts
  • OS:none specified
  • Country: Country Flag
I had a look at the issues, and found quite a bit of info :w00t:
There are a couple nice articles here:
http://www.codinghor...lling-rate.html
http://www.codinghor...n-displays.html
http://www.codinghor...ballistics.html

latter one misses some "key" images, taken from a MS article that was - obviously - lost somewhere in the cloud :( (but that is linked to by MarkTheC) the official MS term is "archived" ;)
http://donewmouseacc...ration-fix.html
http://msdn.microsof...e/gg463319.aspx

The original MS article is however available through the Wayback Machine, even if some images are present in one version of the page and not in another, by "adding up these two":
http://web.archive.o...al.mspx?pf=true
http://web.archive.o...al.mspx?pf=true

The whole concept of "mickeys" is fascinating :unsure:

The codinghorror article links to a (lost ) mouse rate measurement tool that I anyway found ;) and that is attached (just in case).

And another interesting source:
http://www.cybergame...d-Polling-Rate/

So, it seems that the matter is even more complex than what MarkTheC posted (a tip of the iceberg? :ph34r:) and it also seems that most of the 125 Hz vs 500 Hz poll rate is - to say the least - UNnonoticeable by any "normal" human being :unsure:.

It will take me some time to digest the infos (and hopefully understand them), in order to provide a "bettered" spreadsheet.


jaclaz

Attached Files



#29
ownage11

ownage11

    Newbie

  • Member
  • 13 posts
  • OS:Windows 7 x64
  • Country: Country Flag
Thanks for everything jaclaz. Everything is alright using MarkC builder and finally got work well. :)

Edited by ownage11, 04 June 2012 - 11:00 AM.


#30
jaclaz

jaclaz

    The Finder

  • Developer
  • 13,994 posts
  • OS:none specified
  • Country: Country Flag

Thanks for everything jaclaz. Everything is alright using MarkC builder and finally got work well. :)


Thanks my sock! :realmad:
NOT only you are not going to post EXACTLY WHAT you did so that it could be useful to other people, but you also edited each and every of your posts :w00t: in such a way that most of the thread posts would lose significance :(.
Thank goodness I have the habit of quoting at least relevant parts :whistle: .

jaclaz

#31
bphlpt

bphlpt

    MSFN Addict

  • Member
  • PipPipPipPipPipPipPip
  • 1,796 posts
  • OS:none specified
  • Country: Country Flag
Yes ownage11, please post exactly what you ended up doing so that anyone who wants to duplicate your results won't have to start over from scratch.

Cheers and Regards

Posted Image


#32
MarktheC

MarktheC

    Newbie

  • Member
  • 16 posts
  • OS:none specified
  • Country: Country Flag


This is exactly what I did ... WHOOPEE! it works!

Not exactly useful for anybody else :-(

For the benefit of everybody else, the MarkC Fix Builder CAN'T directly create a fix that emulates W2K Low, Medium, or High accel.

[EDIT: Now it does and can!]
It only builds curves with a constant sensitivity (usually 1-to-1, but can be any arbitrary number, but CONSTANT for all mouse inputs, rather than the step-wise accel W2K has.

If one were clever, one might be able to use it as a tool and build a curve piecewise.

¡As a theoretical exercise!, this REG file *SOMEWHAT* approximates W2K: MouseSensivity="10" (6/11), MouseSpeed="2", MouseThreshold1="4", MouseThreshold2="12" (AKA Windows 2000 "Medium" setting), when used on Windows 7 with DPI=100%(96), and when used with the SAME mouse polling rate as you had on Windows 2000, 125Hz or whatever:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Control Panel\Mouse]

"MouseSensitivity"="10"
"SmoothMouseXCurve"=hex:\
00,00,00,00,00,00,00,00,\
00,60,01,00,00,00,00,00,\
00,50,02,00,00,00,00,00,\
00,a0,03,00,00,00,00,00,\
00,40,07,00,00,00,00,00
"SmoothMouseYCurve"=hex:\
00,00,00,00,00,00,00,00,\
00,85,07,00,00,00,00,00,\
00,4b,19,00,00,00,00,00,\
00,4c,4f,00,00,00,00,00,\
00,98,9e,00,00,00,00,00
... it assumes that you have the same mouse polling rate on Windows 7 that you had on W2K.

Up to 4 it gives 1-to-1 like W2K would. After 12ish it gives × 4.0, like W2K would.
Between 4 and 12, all that can be done with the limited number of Smooth curve points available is a somewhat linear increase from × 1.0 to × 4.0, somewhat averaging × 2.0 over the range...

Edit Note1: This curve now *approximates* a standard Windows 2000 accel curve: namely "Medium".
Edit Note2: Soon to be released! Curves that very closely match ALL Windows 2000 accel settings : Low, Medium, High.

Edited by MarktheC, 30 October 2013 - 05:11 PM.


#33
MarktheC

MarktheC

    Newbie

  • Member
  • 16 posts
  • OS:none specified
  • Country: Country Flag
This curve approximates W2K "Low" accel, MouseSensivity="10" (6/11), MouseSpeed="1", MouseThreshold1="7", MouseThreshold2="0"

Windows7_MouseFix_TextSize(DPI)=100%_Scale=1-to-1(2-to-1@9)_@6-of-11.zip

If anybody used W2K Low Accel, and has the same mouse polling rate and mouse DPI now on Windows 7 as they did on W2K, please try it and let me know how it goes.
(The "2-to-1@9" is deliberate and a compromise due to W2K/Windows 7 differences...)

@jaclaz: Good spreadsheet!
(Unfortunately, starting with Excel 2007, Excel no longer lets you grab and move a chart point.)
A suggestion, plotting Y/X (rather than Y) on the vertical axis makes for easier to read curve charts: The Y axis then becomes: "Gain" aka "Control Display Gain", the multipier factor applied to the X value to give the Smooth Y value.

#34
ownage11

ownage11

    Newbie

  • Member
  • 13 posts
  • OS:Windows 7 x64
  • Country: Country Flag
Thanks MarkC,
jaclaz and everybody in this topic, edited it for good ! after all there's also a way to make it close to what you used in Win2000, just got it work by the builder of MarkC using the XP combine with my custom settings in Windows 7

Edit: But seems like mark created for me the best one :)

Edited by ownage11, 05 June 2012 - 08:05 AM.


#35
jaclaz

jaclaz

    The Finder

  • Developer
  • 13,994 posts
  • OS:none specified
  • Country: Country Flag

@jaclaz: Good spreadsheet!
(Unfortunately, starting with Excel 2007, Excel no longer lets you grab and move a chart point.)
A suggestion, plotting Y/X (rather than Y) on the vertical axis makes for easier to read curve charts: The Y axis then becomes: "Gain" aka "Control Display Gain", the multipier factor applied to the X value to give the Smooth Y value.


Hey, I was waiting for your reply! :)
I am working on a new spreadsheet, taking into account some other parameters (actually I already have a spreadsheet with what I think are a "good approximation of the Win2K curve) but I am making quite a few "discoveries" (not in the sense of anything "new", only about something in the "XP ballistics article" and in the way the thingy has been implemented that simply make NO sense - to me at least).

The data are (the general idea being that the 1:1 curve is a 100% slope - your .vbs produces on my machine a 102.4% slope for XP/VIsta and a 100% for Windows 7:
(they look VERY unlike the ones you posted till now :w00t:)

Windows Registry Editor Version 5.00
;Windows7 Test Settings @96 dpi Win2K None
[HKEY_CURRENT_USER\Control Panel\Mouse]
SmoothMouseXCurve=hex:\
00,00,00,00,00,00,00,00,\
00,00,01,00,00,00,00,00,\
00,00,02,00,00,00,00,00,\
00,00,04,00,00,00,00,00,\
00,00,28,00,00,00,00,00,\

SmoothMouseYCurve=hex:\
00,00,00,00,00,00,00,00,\
00,78,05,00,00,00,00,00,\
00,F0,0A,00,00,00,00,00,\
00,E0,15,00,00,00,00,00,\
00,C0,DA,00,00,00,00,00,\


Windows Registry Editor Version 5.00
;Windows7 Test Settings @96 dpi Win2K Low
[HKEY_CURRENT_USER\Control Panel\Mouse]
SmoothMouseXCurve=hex:\
00,00,00,00,00,00,00,00,\
00,00,07,00,00,00,00,00,\
00,00,07,00,00,00,00,00,\
00,00,0C,00,00,00,00,00,\
00,00,28,00,00,00,00,00,\

SmoothMouseYCurve=hex:\
00,00,00,00,00,00,00,00,\
00,48,26,00,00,00,00,00,\
00,90,4C,00,00,00,00,00,\
00,40,83,00,00,00,00,00,\
00,80,B5,01,00,00,00,00,\


Windows Registry Editor Version 5.00
;Windows7 Test Settings @96 dpi Win2K Medium
[HKEY_CURRENT_USER\Control Panel\Mouse]
SmoothMouseXCurve=hex:\
00,00,00,00,00,00,00,00,\
00,00,04,00,00,00,00,00,\
00,00,0C,00,00,00,00,00,\
00,00,0C,00,00,00,00,00,\
00,00,19,00,00,00,00,00,\

SmoothMouseYCurve=hex:\
00,00,00,00,00,00,00,00,\
00,C0,2B,00,00,00,00,00,\
00,40,83,00,00,00,00,00,\
00,80,06,01,00,00,00,00,\
00,E0,22,02,00,00,00,00,\


Windows Registry Editor Version 5.00
;Windows7 Test Settings @96 dpi Win2K High
[HKEY_CURRENT_USER\Control Panel\Mouse]
SmoothMouseXCurve=hex:\
00,00,00,00,00,00,00,00,\
00,00,04,00,00,00,00,00,\
00,00,06,00,00,00,00,00,\
00,00,06,00,00,00,00,00,\
00,00,19,00,00,00,00,00,\

SmoothMouseYCurve=hex:\
00,00,00,00,00,00,00,00,\
00,C0,2B,00,00,00,00,00,\
00,A0,41,00,00,00,00,00,\
00,40,83,00,00,00,00,00,\
00,E0,22,02,00,00,00,00,\



If you are "around", I would like (in a couple of days) send you the draft of the new worksheet for your review (and check), in the meantime find attached the current (possibly incorrect/to be scaled) tentative to simulate the Win2K "behaviour".

If any of the actual peeps that need those curves would actually test and report, it would be a good thing.... :rolleyes:

If I may, both your .vbs and the data you posted is "beautified" by a [TAB] that prevents directly copy/paste in an Excel spreadsheet, it seems to me that even without it, the data is not "that much ugly" and it could be removed.
Besides, it would be nice if you could have the .vbs add a "comment" string, like I do in the spreadsheet, so that you "keep" the file name even when you copy and paste just the data in it.

I don't understand the way you build your new "Win2K - like" curves :ph34r: , I added the plot of your posted "Windows7_MouseFix_TextSize(DPI)=100%_Scale=1-to-1(2-to-1@9)_@6-of-11" to the attached spreadsheet, it seems to me like a zig-zag, can you spend a couple lines to explain the reasoning behind it?

I didn't know about the "news" in Excel 2007, I guess the good MS guys managed to ruin even it! :realmad:

I was thinking along the same line of thought as you do about the possibility of using a different X/Y graphic, but keeping everywhere the same "approach" as the "XP ballistic article seems to me more "natural", I will see after the checks, if there are even more alternatives.
In the meantime I invented a new "standard" :w00t: all graphs in the new spreadsheet will have:
  • "Full" X axis min 0 max 45 primary unit 5 / Y axis min 0 max 650 primary unit 50
  • "Detail" X axis min 0 max 9 primary unit 1 / Y axis min 0 max 130 primary unit 10
this way they will have the same H/W ratio, the second being a 5x magnification of the first.

@all
To repeat myself, I have NO idea if the provided data does in any way approximate the Windows 2K behaviour, please test them and report.

jaclaz

Attached Files


Edited by jaclaz, 05 June 2012 - 12:48 PM.


#36
ownage11

ownage11

    Newbie

  • Member
  • 13 posts
  • OS:Windows 7 x64
  • Country: Country Flag
Interesting, Good job Jaclaz,
Against I am srry if the Edited hurt to you and rest of the people, I was thinking is good idea cuz I've posted that the MarkC Builder isn't working with the W2K Feels,
And he already confirmed that. so my bad :(
Anyway you're all right we've to keep looking for the best & help eachother it's the most important after all i'm positive guy and would like to help !
to get back exactly the old Acceleration of Windows 2000, But trust me I'm not the one you are looking for that :)
I don't have any experience to edit the curve mouse/moves, Even thought you'r tools help to people and doing great job Keep it up.
Soz

Edited by ownage11, 05 June 2012 - 09:54 AM.


#37
jaclaz

jaclaz

    The Finder

  • Developer
  • 13,994 posts
  • OS:none specified
  • Country: Country Flag

I don't have any experience to edit the curve mouse/moves,

That's good :), as right now I *need* not anyone with those capabilities.

All I am looking for is someone (like you) that actually simply tests the curves I just posted and reports if they "feel" anywhere near the original Win2K behaviour.

You might understand how personally:
  • not being a gamer (and having NO idea how a Win2K "felt" in a gaming)
  • not havng a Win2K system handy (actually I am lieng :w00t:, I have one, but have no display that I can use with it)
  • not having a Windows 7 system handy

Just for the record, the last game I ever played was this one
http://en.wikipedia.org/wiki/The_Hitchhiker's_Guide_to_the_Galaxy_(video_game)
(now available to everyone):
http://www.bbc.co.uk...ame_nolan.shtml
but I used to have the original Infocom one, that looked like this:
http://pot.home.xs4a...nfocom/hgg.html

I have no way to test them, and even if I could, I would have not the right "feeling", the theory (as per MS documents) is - to say the least - "shaky" :blink: , the way I understand it might be - even severely - flawed :ph34r: , any kind of mistake could have made it's way on the spreadsheets and I additionally suspect that at least part of the "feeling" is subjective, there is a concrete possibility that a random number generator would produce "better" curves tham I can do right now :w00t: ....

Still just for the record, I tend to normally use this a RNG snippet :whistle: :
http://xkcd.com/221/

jaclaz

#38
ownage11

ownage11

    Newbie

  • Member
  • 13 posts
  • OS:Windows 7 x64
  • Country: Country Flag
Haha :D you are welcome, I will like to help you and checkout any of you'r tests.
And I'm sure we'll able to get the same result.

Running atm: 3 of the operation systems Windows XP 32bit SP2, Win7Ultimate64bit & Windows 2000 pro.

#39
jaclaz

jaclaz

    The Finder

  • Developer
  • 13,994 posts
  • OS:none specified
  • Country: Country Flag

(Unfortunately, starting with Excel 2007, Excel no longer lets you grab and move a chart point.)


I didn't know about the "news" in Excel 2007, I guess the good MS guys managed to ruin even it! :realmad:


.... the good news being that it can be-re-added through an add-on ;) :):

http://blogs.office....harts-mpoc.aspx

Overview

In Excel 2007, the ability to directly resize or reposition points on the chart was deprecated. This feature was sometimes referred to as "Graphical Goal Seek." For example, in Excel 2003 a user could click on a data point in a column chart twice which would surface handles that could be used to resize the columns. Over the last couple of years we have received a lot of feedback from customers indicating that this was a valuable feature for some scenarios. However, we were not able to react in time to roll this feature back into Excel 2010 but we are evaluating how to bring this back as a native feature in a future release. In an effort to restore this lost functionality, we have developed a sample Add-In that can be used in both Excel 2007 and Excel 2010.

In this blog post, I will provide the Sample Add-In for download and illustrate how to use this Add-In for manipulating points on your chart.


jaclaz

P.S.: just realized that I left a "link" in the mouseaccelW2k spreadsheet, I am updating the posted file, please re-download.

Edited by jaclaz, 05 June 2012 - 12:47 PM.


#40
MarktheC

MarktheC

    Newbie

  • Member
  • 16 posts
  • OS:none specified
  • Country: Country Flag

...I am making quite a few "discoveries" (not in the sense of anything "new", only about something in the "XP ballistics article" and in the way the thingy has been implemented that simply make NO sense - to me at least).

There are a some things that don't make sense in that XP Ballistics article.
If it *had* made reasonable sense, there would be no MarkC Windows 7 fixes! My fixes were a byproduct of the research needed to make sense of the errors in that article, and convince somebody that it was a real problem.

The data are (the general idea being that the 1:1 curve is a 100% slope - your .vbs produces on my machine a 102.4% slope for XP/VIsta and a 100% for Windows 7:
(they look VERY unlike the ones you posted till now :w00t:)

;Windows7 Test Settings @96 dpi Win2K None

I confirm that is a 1:1 curve.
But there is a twist.

Inside Windows it does the calculations with 48.16 fixed point numbers (48 bits to the left of the binary point, 16 bits to the right).
As the calculations are done, remainders occur and are discarded (because the result has bits past the last 16th binary digit).
Often these discarded remainders have no effect, EXCEPT when you reverse the mouse left<->right or up<->down, and there will be a one pixel error appear (MouseMovementRecorder will show a pointer movement 1 different from the mouse movement).

If:
- Smooth_X is the delta SmoothX value of the segment (SmoothMouseXCurve[i] - SmoothMouseXCurve[i-1])
(1.0 = 0x10000 = 65536)
- Smooth_Y is the delta SmoothY value of the segment (SmoothMouseYCurve[i] - SmoothMouseYCurve[i-1])
- DPI is 96 (or whatever)
- MouseSensitivity is "MouseSensitivity" from the registry
- MouseSensitivityFactor is =INT(MouseSensitivity*65536/10) (65536 for the 6/11, "10" position)

Then the final sensitivity (Windows 7) is:
Scaling=INT(INT(INT(Smooth_Y*INT(DPI*65536/150)/65536)*MouseSensitivityFactor/65536)*65536/(Smooth_X*3.5))/65536

Often (but not always) the value of delta SmoothX that gives a desired target scaling is:
Smooth_X = INT(INT(INT(Smooth_Y*INT(DPI*65536/150)/65536)*MouseSensitivityFactor/65536)/(Target_Scaling*3.5))

For the 1st segment of your 1:1 curve, Scaling = 65535/65536, ~0.99998, not quite 1:1
If you decrease your SmoothX from 10000 down by 1 to FFFF, then the scaling comes out at an exact 65536/65536.
(Or increase Smooth_Y a bit.)

;Windows7 Test Settings @96 dpi Win2K Low

Yes, 1:1, stepping up to 2:1!

But stepping up at what mouse speed?
You can test your curves on Windows XP or Vista. There will be the 2.4% difference you note (@60Hz monitor refresh rate), but that's close enough to get a general feel. Running MouseMovementRecorder.exe while testing will show the exact mouse speed threshholds a curve has.
If you try your Win2K Low curve, you should see it bumps up to 2:1 at 25 (rather than 7).

? The SmoothMouse?Curve values are nominally inches/second, NOT mouse counts/polling interval or pixels/whatever.
I'm guessing MS used Mouse CPI=450 (didn't a popular MS mouse have 450 CPI?) and polling interval 125Hz, to give a conversion factor of 450/125=3.6, rounded to 3.5:
To convert a SmoothMouseXCurve value to a mouse count ("mickey"), multiply or divide by 3.5.
The SmoothMouseXCurve corresponding to 7 is 7/3.5 = 2.0

Despite what any MS technet doc might say, the Win2K thresholds apply when the mouse moves strictly GREATER THAN the threshold.
So if MouseThreshold1 = 7, a 7 mouse movement will still be 1:1. 8 and higher will be 2:1
So you should add 1 to any Win2K threshold (add at least one...)

Windows XP/Vista/7 sort-of use the magnitude of the movement vector as the input to the curve lookup.
The calculation is:
Magnitude = Max(Abs(X),Abs(Y)) + Min(Abs(X),Abs(Y)) / 2
For example, a mouse movement of x=7, Y=3, counts as 7+3/2 = 8.5

In Win2K, a movement of x=7, Y=3 has each axis treated separately, so in the X axis, 7<=MouseThreshold1 and so still 1:1, and 3<=MouseThreshold1 so still 1:1.
x=8, y=3 would be treated as 8>MouseThreshold1, so 2:1 in the X axis but 3<=MouseThreshold1, so still 1:1 in the Y axis.

When building a Windows 7 curve, if the mouse moved X=7, Y=3, we might want to treat that as 1:1, because Win2K would treat that as 1:1 (in both axes).
But with Windows XP/Vista/7 magnitude calculation gives 8.5, and 8.5>7, so we apply accel based on the next curve segment.
To prevent that, I set the 1st segment SmoothX to ~8.75/3.5 (=2.5), so that 7,3 is 1:1 but 7,4 or 8,2 is 2:1
8.75 is a compromise setting.
Given these curves will be used by gamers, and much movement is left/right (?) rather than up/down, maybe 7.75 might be a better compromise.
7,0 and 7,1 would then be 1:1 (same as Win2K), but 8,0 would be 2:1...

Internally, Windows processes the raw curves. It calculates : (SmoothY[i]-SmoothY[i-1]) / (SmoothX[i]-SmoothX[i-1])
Because your SmoothX[1] and SmoothX[2] values are the same (7), that would be a divide by zero!
Windows checks for the potential divide by zero and instead stores 0 for both the re-calculated Y and X values.

There are 2 ways to handle the step up from 1:1 to 2:1:
- Use a very narrow segment, say SmoothX[1] = 7/3.5 and SmoothX[2] = 7.1/3.5 (to avoid the divide by zero)
- Just set both SmoothX[2] and SmoothY[2] to zero! :ph34r:

The first method has a short segment with a very steep slope, which can cause some strange behaviour...
The second relies on the inner workings of the curve lookup, and works better! It's a trick that works because of how the curve lookup works.

;Windows7 Test Settings @96 dpi Win2K Medium

Curve segment 1 starts out at 2:1, but it needs to start at 1:1

At 12 (actually 12*3.5, see above about dividing by 3.5) it steps to 4:1

To exactly match the 1:1, 2:1, 4:1 Win2K "curve", we really need 5 segments:
1) 1:1
2) A narrow, steep segment to step-up to 2:1 (or the zero trick)
3) 2:1
4) A narrow, steep segment to step-up to 4:1 (or the zero trick)
5) 4:1

Unfortunately, the SmoothMouse curves only have 4 segments (5 points, but 4 segments between the points).

What I did in the Threshold1=2, Threshold1=5 example curve was this:
1) 1:1
2) A wider segment to get between 1:1 and 2:1 (a slope, not a step)
3) A wider segment to get between 2:1 and 4:1 (a slope, not a step)
4) 4:1

This assumes that the user cares more about consistent 4:1 at high speeds, and can live with a variable curve between 2 and 5.
If they really need the consistent 2:1, then the slope from 2:1 to 4:1 will have to be variable...

;Windows7 Test Settings @96 dpi Win2K High

Similar comments as for Win2K Medium.

If you are "around", I would like (in a couple of days) send you the draft of the new worksheet for your review (and check).

I'll look forward to it. :yes:

If I may, both your .vbs and the data you posted is "beautified" by a [TAB] that prevents directly copy/paste in an Excel spreadsheet, it seems to me that even without it, the data is not "that much ugly" and it could be removed.

meh. :}

Besides, it would be nice if you could have the .vbs add a "comment" string, like I do in the spreadsheet, so that you "keep" the file name even when you copy and paste just the data in it.

That's a good idea. :yes:
When I next update my VBS tool I'll make that change (which likely won't be for a while, unless I decide to put a Win2K curve builder into the mix).

I don't understand the way you build your new "Win2K - like" curves :ph34r: , I added the plot of your posted "Windows7_MouseFix_TextSize(DPI)=100%_Scale=1-to-1(2-to-1@9)_@6-of-11" to the attached spreadsheet, it seems to me like a zig-zag, can you spend a couple lines to explain the reasoning behind it?


- Segment 1 goes from 0 to SmoothX = 2.5, corresponding to Mouse=2.5x3.5 = 8.75 (8.75 explained above as a compromise so that x=7,y=3 would still be 1:1)

- Segment 2 goes from SmoothX = 2.5 to 0, and is ignored by the Windows lookup (this is trick to avoid a short steep segment that can cause problems)

- Segment 3 goes from 0 to SmoothX = 5, corresponding to Mouse=5x3.5 = 17.5, BUT the exact number doesn't matter for the last valid segment, because Windows extrapolates the last valid segment forward. All that matters is the slope of the last segment. So it could be DeltaY=35, DeltaX=17.5 (as it is), giving 2:1 (DeltaY=35 after x96/150 factor applied), or could be DeltaY=2000, DeltaX=1000.

- Segment 4 is ignored because of the zeros (I think...! :blink: )

The fact that the last segment is extrapolated forward is a good reason NOT to display or plot the last point on any graphs: It is only the slope (direction) of the last segment that matters, not where it "ends" (it doesn't end, it is extrapolated forward).

With the curve lookup trick, and the extrapolation, my Win2K Low curve looks like this:
Attached File  Windows7_MouseFix_TextSize(DPI)=100%_Scale=1-to-1(2-to-1@9)_@6-of-11.png   20.41KB   11 downloads

Edited by MarktheC, 07 June 2012 - 06:00 AM.


#41
jaclaz

jaclaz

    The Finder

  • Developer
  • 13,994 posts
  • OS:none specified
  • Country: Country Flag
Very interesting info in your post :thumbup .
I will try and digest them.

There is a point in this:

Curve segment 1 starts out at 2:1, but it needs to start at 1:1

At 12 (actually 12*3.5, see above about dividing by 3.5) it steps to 4:1

To exactly match the 1:1, 2:1, 4:1 Win2K "curve", we really need 5 segments:
1) 1:1
2) A narrow, steep segment to step-up to 2:1 (or the zero trick)
3) 2:1
4) A narrow, steep segment to step-up to 4:1 (or the zero trick)
5) 4:1

Unfortunately, the SmoothMouse curves only have 4 segments (5 points, but 4 segments between the points).

that I can clarify immediately.
(as said the proposed curves need to be "scaled" :blushing: , as the intention was to render the "shape" of the curve, so the reason for the initial 2:1 was that of attempting to emulate as good as possible the Win2k for the "most used" part within the 4 segment limit).

One of the really "queer" things in the "XP ballistics" article (among many - if not plainly wrong - definitely incorrect or deceiving info) is the actual numbers of points (and conversely segments):
http://msdn.microsof...e/gg463319.aspx

The transfer function consists of five points. Four of the five points reside in the lower end of the mouse velocity spectrum. The velocities that go beyond the 4-inch limit are linearly extrapolated.


4. The lookup table consists of six points (the first is [0,0]). Each point represents an inflection point, and the lookup value typically resides between the inflection points, so the acceleration multiplier value is interpolated.


Now, even a single handed guy can count up to six (by touching his nose ;)) so HOW THE HECK they managed to wriite down such inconsistent info? :unsure:

Another thing, if really-really the graph and data are expressed in inch/s (something that I am starting to doubt GREATLY) and IF the "extrapolation limit" is set at 4-inch (should be 4 inch/s), all points up to n-1 should have X values below 4 (and this happens with the default curve) and any curve where the n-1 point is greater than 4 should have a n-1 to n segment that is ignored :ph34r:
And of course having the n point on 40 is pure nonsense, n could be fixed at (say) 5 and n-1 fixed to slightly less than 4 (and the original curve is around 3,86).


jaclaz

#42
MarktheC

MarktheC

    Newbie

  • Member
  • 16 posts
  • OS:none specified
  • Country: Country Flag

...so the reason for the initial 2:1 was that of attempting to emulate as good as possible the Win2k for the "most used" part within the 4 segment limit).

That's the problem with trying to emulate Win2K Medium or High accel: You have to choose a "most used" part and optimise for that, and the result is a compromise.

My Threshold1=4,Threshold2=12 attempt optimised for the 1:1 part and the 4:1 part but only crudely aproximated the 2:1 part.
Your Medium and High curves optimise for the 2:1 and 4:1 part, but ignore the 1:1 part.

One of the really "queer" things in the "XP ballistics" article (among many - if not plainly wrong - definitely incorrect or deceiving info) is the actual numbers of points (and conversely segments):
http://msdn.microsof...e/gg463319.aspx

The transfer function consists of five points. Four of the five points reside in the lower end of the mouse velocity spectrum. The velocities that go beyond the 4-inch limit are linearly extrapolated.


4. The lookup table consists of six points (the first is [0,0]). Each point represents an inflection point, and the lookup value typically resides between the inflection points, so the acceleration multiplier value is interpolated.

I totally missed the reference to "six" points!
There are obviously only 5.

What MS should have said is :

The transfer function consists of five points. Four of the five points reside in the lower end of the mouse velocity spectrum. The velocities that go beyond the 4th point are linearly extrapolated.

I can confirm that there is no "extrapolation limit", set at 4-inch (or any other number).
There is logic to extrapolate when in the last segment.

And of course having the n point on 40 is pure nonsense, ...

Yes, the last point could be anywhere (after the 2nd-to-last point that is).
Many mice, MS included, have an 8 bit USB data path, and can only return mouse movements between -127 and +127 (this is why overclocking MS mice helps avoid negative acceleration for large mouse movements).
127/3.5 = 36.28, maybe they rounded this up to 40, and decided it was good enough?
Windows extrapolates past the end of the last segment anyway, so it doesn't matter what the number is.

- Segment 4 is ignored because of the zeros (I think...! :blink: )

I narrowly escaped a problem there...

Segment 4 IS NOT ignored because of the zeros.

If the mouse moves faster than than the 2nd to last SmoothMouseXCurve value, then the lookup decides it is in the last segment, (regardless of the last SmoothMouseXCurve value is) and the last segment is used or extrapolated.
And the last segment, rather than pointing out and upwards, points back to zero!
No problem, it still has a positive slope! (negative number divided by a negative number is positive!)
It all works out in the end.

Edited by MarktheC, 15 June 2012 - 05:10 PM.


#43
jaclaz

jaclaz

    The Finder

  • Developer
  • 13,994 posts
  • OS:none specified
  • Country: Country Flag

4. The lookup table consists of six points (the first is [0,0]). Each point represents an inflection point, and the lookup value typically resides between the inflection points, so the acceleration multiplier value is interpolated.

I totally missed the reference to "six" points!
There are obviously only 5.

The sentence is particularly ambiguous. :unsure:
It can be read as if there are 5 "explicit" points (or if you prefer 5 values in the Registry key) and a sixth (implied) one set by design :ph34r: to 0.
I.e. it is possible that the curve is actually:
[0,0]
(0,0)
(0,430007935.1,369995117)
(1,25,5,300003052)
(3.86000061,24.0000305)
(40,568)

What happens if we set first "explicit" point to something different from (0,0)?
Like, as an example, to (0,0.215)? :blink:

jaclaz

#44
MarktheC

MarktheC

    Newbie

  • Member
  • 16 posts
  • OS:none specified
  • Country: Country Flag

The sentence is particularly ambiguous. :unsure:
It can be read as if there are 5 "explicit" points (or if you prefer 5 values in the Registry key) and a sixth (implied) one set by design :ph34r: to 0.
I.e. it is possible that the curve is actually:
[0,0]
(0,0)
(0,430007935.1,369995117)
(1,25,5,300003052)
(3.86000061,24.0000305)
(40,568)

Oooh, so tempting! If only it were true... :w00t:
But unfortunately it is not. 6 points (including a very sensible implied [0,0] as you suggest) would mean 5 segments, but there is only space for 4, and a loop of 4 calculations calculating slope and intercept for the curve segments :whistle: :ph34r:

What happens if we set first "explicit" point to something different from (0,0)?
Like, as an example, to (0,0.215)? :blink:

Strange things happen if the first point is not (0,0) - I wonder why MS even bothered storing it :wacko:

(0,+anything) would give a constant boost to any movement, so mouse movements of 1,2,3,4 (for example) might produce pointer movements of 4,5,6,7 (1:1 plus a boost of +3).
(0,-anything) might make small forward movements go backwards! So mouse movements of 1,2,3,4 (for example) might produce pointer movements of -2,-1,0,1 (1:1 plus a negative boost of -3). That would be confusing!

#45
MarktheC

MarktheC

    Newbie

  • Member
  • 16 posts
  • OS:none specified
  • Country: Country Flag

Internally, Windows processes the raw curves. It calculates : (SmoothY[i]-SmoothY[i-1]) / (SmoothX[i]-SmoothX[i-1])
Because your SmoothX[1] and SmoothX[2] values are the same (7), that would be a divide by zero!
Windows checks for the potential divide by zero and instead stores 0 for both the re-calculated Y and X values.


Sorry, upon closer inspection, the divide by zero is theoretical only, and does never happen, and setting two SmoothX values to be the same (as you did with both SmoothX[1] and SmoothX[2] = 7) is a valid way to get the "step-up", so continue as you were!

#46
jaclaz

jaclaz

    The Finder

  • Developer
  • 13,994 posts
  • OS:none specified
  • Country: Country Flag

setting two SmoothX values to be the same (as you did with both SmoothX[1] and SmoothX[2] = 7) is a valid way to get the "step-up", so continue as you were!

Good. :)
So, summing it up, the six points are only five, and since the first one is always [0,0] they are actually only four (and one of them set at [40,568] makes no sense and can be placed at (say) [5,n] allright.

I have some issues with this :w00t: :

- MouseSensitivity is "MouseSensitivity" from the registry
- MouseSensitivityFactor is =INT(MouseSensitivity*65536/10) (65536 for the 6/11, "10" position)

We have 11 Levels in the CP app cursor.
But we have at least 20 values in Mouse Sensitivity in Registry (from 1 to 20 or possibly from 0 to 20).
Since the good MS guys invented the "mickey" and more generally used units of measure in a very "vague" way, I feel authorized to introduce THREE elements:
MSCPL=Mouse Sensitivity in the Control Panel Levels
RMSV=Registry Mouse Sensitivity Values
ASOY=A Suffusion Of Yellow

The "conversion table is the following:

MSCPL 1 = RMSV 1
MSCPL 2 = RMSV 2
MSCPL 3 = RMSV 4
MSCPL 4 = RMSV 6
MSCPL 5 = RMSV 8
MSCPL 6 = RMSV 10
MSCPL 7 = RMSV 12
MSCPL 8 = RMSV 14
MSCPL 9 = RMSV 16
MSCPL 10 = RMSV 18
MSCPL 11 = RMSV 20

Using the control panel cursor you can only have these values in the MouseSensitivity key in the Registry, but all intermediate values are valid.
So you have a reversed table:

RMSV 1 = MSCPL 1
RMSV 2 = MSCPL 2
RMSV 3 = ASOY
RMSV 4 = MSCPL 4
RMSV 5 = ASOY
RMSV 6 = MSCPL 6
RMSV 7 = ASOY
RMSV 8 = MSCPL 8
RMSV 9 = ASOY
RMSV 10 = MSCPL 10
RMSV 11 = ASOY
RMSV 12 = MSCPL 12
RMSV 13 = ASOY
RMSV 14 = MSCPL 14
RMSV 15 = ASOY
RMSV 16 = MSCPL 16
RMSV 17 = ASOY
RMSV 18 = MSCPL 18
RMSV 19 = ASOY
RMSV 20 = MSCPL 20


The formula:

- MouseSensitivityFactor is =INT(MouseSensitivity*65536/10) (65536 for the 6/11, "10" position)

gives only a point (65536) of the diagram of conversion between MSCPL and actual MouseSensitivity Factor.
It would be logical that the "scalar set" to generate the family of curves is linear, i.e. that, using the "reduced" set of MSCPL you have:
MSF@MSCPL6=10*65536/10=65536
and:
MSF@MSCPL1=1*65536/10=6553
MSF@MSCPL2=2*65536/10=13107
MSF@MSCPL3=4*65536/10=26214
MSF@MSCPL4=6*65536/10=39321
MSF@MSCPL5=8*65536/10=52428
MSF@MSCPL6=10*65536/10=65536
MSF@MSCPL7=12*65536/10=78643
MSF@MSCPL8=14*65536/10=91750
MSF@MSCPL9=16*65536/10=104857
MSF@MSCPL10=18*65536/10=117964
MSF@MSCPL11=20*65536/10=131072

The results of a quick experiment lead me to think that this "scalar set" is non linear, and can be approximated with a quadratic expression.
Due to the obvious lack of precision of this early experiment and to the limited time I spent in half-@§§edly doing it, it is possible that the actual values are inaccurate, but the difference between a linear set and a function one is so evident that I have some serious doubts :unsure: .

I am attaching a small spreadsheet with the results of the experiment, definitely - due to the half-@ssed testing procedure - I have lost important precision in the "lower levels", but "higher levels" should be "accurate enough", and more than that the "general shape" if not the actual scale/parameters should be also "accurate enough".
I tried to manually rebuild a more "logical" diagram of the "family of curves", measuring the image in the MS article, and the "linear formula" seemingly does not fit :ph34r: .


jaclaz

Attached Files



#47
WinWin

WinWin
  • Member
  • 9 posts
  • OS:Windows 2000 Professional
  • Country: Country Flag
Wow, this discussion really opened up in the past week or two. There is some really good info here and it gives good motivation to attempt to write a program that can fine-tune such curves a million times better than what is in our defaults. MarkTheC and jaclaz gave a huge amount of insight on this. It seems we have all come across the same roadblock of "compromise" when looking for the best solution. MarkTheC seems to know exactly what is going on when making those curves, the whole caveat being the smooth portion of the curve. It seems that no matter which points you create, that the intermediate values will be smoothed much like a bezier curvea. This explains why some of these worked for slow movements or fast twitchy ones, but left something to be desired in between especially at points near that thresholdb and explains why exact values aren't achieved in the mouse movement recorder. (Thanks to MarkC for this.) Even though there isn't a perfect solution, there is a much better understanding of how things work and if I'm patient and smart enough, I'll eventually try to create a program that can better emulate different "curves" or "jumps".

For the time being I've been using Windows XP 64bit edition with MarkC's Mousefix builder 1.4 to achieve an exact 1:1 input and purchased a mouse that can change to any desired DPI on the fly and discovered simply doubling the other mouse's DPI gave back those perfect fast "twitchy" movements compromising the geared down slower ones with faster, jerkier ones. I discovered this to be better than having even a slight curve in between because it's not always predictable on a dime. This predictability is probably why I have become so attached to how it "jumps" with no curve in Win2k but no other subsequent OS; you know exactly where it is going to land every time. The good part is with a newer more responsive mouse, there feels to be a slight decrease in input latency which helps offset the slow jitter and over correction (Maybe 10ms or a frame or 2 at most) and the higher dpi makes it less noticeable. This seems to prove that in the evolution of tweaking the acceleration graph in subsequent versions of Windows OS that simpler is oftentimes the best solution. Again, great discussion, it really helped loads.


a Bézier curve (Wikipedia)

A bit how the "smooth" curve really behaves. (exaggerated for emphasis)
bPosted Image

#48
MarktheC

MarktheC

    Newbie

  • Member
  • 16 posts
  • OS:none specified
  • Country: Country Flag

It seems that no matter which points you create, that the intermediate values will be smoothed much like a bezier curvea. This explains why some of these worked for slow movements or fast twitchy ones, but left something to be desired in between especially at points near that thresholdb and explains why exact values aren't achieved in the mouse movement recorder.

The smoothing that happens just near a step point is subtle, and I argue better (a little) in XP/Vista/7 than it was in Windows 2000...

I presume you have tried one or more of the × 1.0 stepping up to × 2.0 curves, and saw MouseMovementRecorder show what looks like a single intermediate smoothed value, rather than a sudden step-up? MMR might show 8 as 1:1=8, then 9 as 1.5:1=13, then another 9 as 2:1=18, and then other values at 2:1.
The middle 9 = 13 or 14 looks like "smoothing", which didn't happen in Windows 2000, and therefore bad?

Not necessarily so...

(If instead you were using a 1:2:4 curve, where the middle 2:1 section was a slope increasing from 1:1 to 4:1, then what I say below WON'T apply, but if you were using a 1->2 curve, please keep reading...

(For the examples below, forget the REG curve that steps up at 9, and imagine one built to step-up at exactly the same point that Windows 2000 did: 8)

1) If you are sweeping up past the threshold and then stay faster 8 or faster, then the difference is only 4 pixels that occurs once only (as the threshhold is passed) and likely not felt or noticed.

2) Imagine instead you are moving the mouse at a constant speed (perhaps trying to track a target?)

Suppose that speeds happens to be right at the threshhold, right in the middle, and you are moving at (on average) 7.5 mouse counts per poll.
The mouse sends 7, 8, 7, 8, 7, 8, ...
Windows 2000 would apply 1:1 to each of the 7s and 2:1 to each of the 8s, so after accel, the pointer would be 7, 16, 7, 16, 7, 16...
So a mouse speed of 7.5 has pointer speed of (7+16)/2 = 11.5 pixels on average. Average gain is 11.5/7.5 = 1.5333 !
Even Windows 2000 has smoothing just either side of the step-up point.

I've built a graph showing the difference between W2K and XP/Vista/7 for a mouse moving at a constant speed:
Attached File  Windows 2000 Step versus XP Step.png   17.51KB   8 downloads
(X axis is (average) mouse movement in counts, Y Axis is (average) scaling applied)

Notice the transition between 7 and 8 is steeper with XP/Vista/7 than it is for Windows 2000.
As Windows XP/Vista/7 processes the 8s, it notices that IMMEDIATELY BEFORE the 8 was a 7, which was in the previous curve segment.
It reduces the accel to an average of the two curve segments, 1.5:1 for each 8.
As Windows XP/Vista/7 processes the 7s, it notices that BEFORE the 7 was an 8, which is in the next (or same) curve segment, and it does nothing special, just uses the current curve 1:1.
So after accel, the pointer would be 7, 12, 7, 12... and the pointer speed is (7+12)/2 = 9.5. Average gain is 9.5/7.5 = 1.267 !
The middle of the step is pulled down, making the transition steeper.

I think the steeper transition is better than the shallower transition.

3) Windows XP/Vista/7, the transition steepening can't be turned off, so there is no choice but to accept it!

For the time being I've been using Windows XP 64bit edition with MarkC's Mousefix builder 1.4 to achieve an exact 1:1 input and purchased a mouse that can change to any desired DPI on the fly and discovered simply doubling the other mouse's DPI gave back those perfect fast "twitchy" movements compromising the geared down slower ones with faster, jerkier ones. I discovered this to be better than having even a slight curve in between because it's not always predictable on a dime. This predictability is probably why I have become so attached to how it "jumps" with no curve in Win2k but no other subsequent OS; you know exactly where it is going to land every time. ... This seems to prove that in the evolution of tweaking the acceleration graph in subsequent versions of Windows OS that simpler is oftentimes the best solution.

You can't change your mind now! :lol:

I've just gone and applied much magic, and I now have 3 part curves where NO part needs to be a compromise.
There is a flat 1:1 section, a step up, a flat 2:1 section, a step up, a flat 4:1 section.
(These curves will closely match the Windows 2000 Medium and High accel settings.)
(They do have the "smoothing"/"transition steepening" as described above.)

When you used Windows 2000, did you use Low accel, or did you use Medium or High?

If you used Medium or High, would you like to try one of my "magic" curves?

Edited by MarktheC, 12 June 2012 - 04:58 AM.


#49
ownage11

ownage11

    Newbie

  • Member
  • 13 posts
  • OS:Windows 7 x64
  • Country: Country Flag
Thank you for the information really care deeply about how things worked in 2000,
I still got 2000 at the moment but on a Virtual machine,
I would like to give it a shot for you'r magic curves I'll check that out and give a report back.


By the way is the custom curves you made for me mark can have any useful fix? or it's the only option of that release? (Feels close)

Edited by ownage11, 12 June 2012 - 06:31 AM.


#50
MarktheC

MarktheC

    Newbie

  • Member
  • 16 posts
  • OS:none specified
  • Country: Country Flag

We have 11 Levels in the CP app cursor.
But we have at least 20 values in Mouse Sensitivity in Registry (from 1 to 20 or possibly from 0 to 20).
Since the good MS guys invented the "mickey" and more generally used units of measure in a very "vague" way, I feel authorized to introduce THREE elements:
MSCPL=Mouse Sensitivity in the Control Panel Levels
RMSV=Registry Mouse Sensitivity Values...

BTW, my MarkC Fix Builder allows the middle values to be used and entered as 2.5 3.5 4.5 etc., in the part that asks for what Pointer Speed Slider value to use.

Sorry, the way the MSCPL value affects scaling depends on whether the 'Enhance pointer precision' checkbox is ON or OFF.
(I should have said that, rather than assumed it.)

When EPP is ON, the scaling is MouseSensitivityFactor is =INT(MouseSensitivity*65536/10), which is a strictly linear function of MouseSensitivity.

When EPP is OFF, scaling is a piecewise function:
if (MouseSensitivity <= 2)
	MouseSensitivityFactor = MouseSensitivity / 32
else if (MouseSensitivity <= 10)
	MouseSensitivityFactor = (MouseSensitivity-2) / 8
else
	MouseSensitivityFactor = (MouseSensitivity-6) / 4

...and the typical pointer resolution is 400 mickey/inch.

They may have meant to say "pointing device resolution", but they mean "Mouse".
The term "Mickey" is an attempt to be clear.
I try not to use "dots", as in dots-per-inch to describe mouse resolution or mouse movement, because it can easily be confused with "pixel" (think of a monitor resolution usually measured in "dots-per-inch").
I use "mouse count", and CPI (counts-per-inch), and they use "Mickey" to make it 100% clear they are not talking about pixels.

Microsoft have stuffed up their example.
Note in YOUR calculations (with no "transformation"), that the one second of mouse movement was 375 counts (Mickeys/dots).
in YOUR calculations (with no "transformation"), that the one second of pointer movement was 225 pixels.
So which is it? 375 or 225?

Why would Microsoft suggest an example where on the MOUSE, there are 125 polling intervals every second, with 3 counts each interval, and then somehow assume that that corresponds to 75 refresh intervals on the monitor ALSO WITH 3 counts each interval?
That's just confused. The time intervals are of different lengths. How could there be the same number of counts (with no transformation)?
What do they imagine happened to the extra mouse counts during that 1 second?

The correct calculation is 1 second of movement @ 3 counts/poll = 375 counts and 0.9375 inches.
No transformation = 1:1 = 375 pixels on the monitor.
375 pixels on the monitor @ 80DPI = 4.6875 inches.
Mouse/Display Gain = 4.6875/0.9375 = 5.0
Throw all of the polling and refreshing and MS confusion way, the mouse is 400 CPI, the monitor 80 DPI, assuming 1:1 (no "transformation"), Mouse/Display gain = 400/80 = 5.0 (Hmmm same number as above!)

I don't know if you have read my first blog post, but Microsoft carried this stuff-up all of the way into the actual Windows XP code, then sort of realised there must be a mistake somewhere, then stuffed it up some more for good measure and shipped it...

Ditto for your second example with the 22 inch LCD monitor.
Why suddenly do mouse counts arriving 125 times a second, magically turn into (with no "transformation" = 1:1) 3 pixels moved 60 times a second (the 60Hz monitor refresh rate)?
Answer: They don't: Microsoft were confused.
The proper Mouse/Display gain (with no transformation) is 400/90 (CPI/DPI) (which is not 2.13).

We DO NOT have Screen Resolution, expressed in dpi (RWdpi).
We do have the Screen Resolution expressed in Xpixels*Ypixels, but unless we have the physical size of the screen we have NOT it in dpi (or ppi, pixels per inch).

Correct, we do not have directly have screen resolution (DPI).
We do have the monitor "Text Size", which will have to do, and be used in place of the actual monitor DPI.
Presumably they are at least crudely related, if for no other reason that a user with a high DPI monitor may tend to set the Text Size DPI higher so they can read text better...

How to change/view the DPI on Windows 7.
How to change/view the DPI on Vista.
How to change/view the DPI on XP.

"Text Size" AKA Monitor DPI will just have to do, and that is what MS use in the accel logic.

Logitech mouse drivers (SetPoint) if installed, can have their own scaling and accel, and disable the Window Control Panel settings.
Best to make sure what your Logitech mouse driver settings are before testing things, if you have SetPoint installed.

(Measuring mouse response)

I'd say your measurements are consistent with an actual mouse CPI of ~440 CPI.
With EPP ON, and moving slowling, the default Windows curve has a × 0.58 multiplier (Windows XP, 60Hz monitor, "Normal Fonts"=96DPI)
2.16" with × 0.58 should be 440×2.16×0.58 = 550 pixels, but would be more if you took shorter than 5 seconds to make that movement (because EPP accel would start to kick in).

With EPP OFF, 440×2.16" = 950 pixels
With EPP OFF, 440×0.85" = 374 pixels

Were I started, was moving the mouse slowly (make sure MouseMovementRecorder never shows more than 1s), and changing the monitor refresh rate and Text Size DPI and seeing how that affected the mouse response (with EPP ON of course) and then cursing at MS for what I found.

A quick observation makes evident that the mouse cursor "levels" that you can obtain in the control panel, which have been numbered from 1 to 11, being 6 the "middle setting", correspond to a value in the Registry HKEY_CURRENT_USER\Control Panel\Mouse\MouseSensitivity, with values that correspond to the following: ...

With EPP OFF, hopefully the piecewise sensitivity function above agrees with your measurements for CPL=1 thru 20.
(From memory, if the registry MouseSensitivity is outside the range 1 thru 20, Windows uses 10 instead.)


And finally:
THANK YOU jaclaz for querying about how many points there were and how many segments that corresponded to!

Because of yourcomments, I very closely reexamined the logic, and from 5 points, enough magic can be applied to get 3 flat segments and 2 step-ups, so that Windows 2000 Medium and High curves can be implemented, with 1 flat 1:1 section, a zero-width step-up, a flat 2:1 section, another zero-width step-up and a final 4:1 curve going out until approx 8000 mouse counts!




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users



How to remove advertisement from MSFN