Jump to content

Any way to cannibalize the Windows 2000 mouse driver?


WinWin

Recommended Posts

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

Link to comment
Share on other sites



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
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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
Link to comment
Share on other sites

@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:

  1. "Full" X axis min 0 max 45 primary unit 5 / Y axis min 0 max 650 primary unit 50
  2. "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

mouseaccelW2k.zip

Edited by jaclaz
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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:

  1. not being a gamer (and having NO idea how a Win2K "felt" in a gaming)
  2. not havng a Win2K system handy (actually I am lieng :w00t:, I have one, but have no display that I can use with it)
  3. 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/radio4/hitchhikers/game_nolan.shtml

but I used to have the original Infocom one, that looked like this:

http://pot.home.xs4all.nl/infocom/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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

(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.com/b/microsoft-excel/archive/2009/11/02/excel-add-in-for-manipulating-points-on-charts-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
Link to comment
Share on other sites

...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 - SmoothMouseXCurve[i-1])

(1.0 = 0x10000 = 65536)

- Smooth_Y is the delta SmoothY value of the segment (SmoothMouseYCurve - 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-SmoothY[i-1]) / (SmoothX-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:

post-352446-0-48008900-1339069791_thumb.

Edited by MarktheC
Link to comment
Share on other sites

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.microsoft.com/en-us/library/windows/hardware/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

Link to comment
Share on other sites

...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.microsoft.com/en-us/library/windows/hardware/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
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

Internally, Windows processes the raw curves. It calculates : (SmoothY-SmoothY[i-1]) / (SmoothX-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!

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...