MarktheC

It is now possible to emulate old-style Windows 2000+98+95 mouse acceleration on Windows XP+Vista+7+8. Check it out now @ The MarkC Windows 8 + 7 + Vista + XP Mouse Acceleration Fix Builder (also emulates Windows 2000/98/95 acceleration). Or The MarkC Windows 8 + 7 Mouse Acceleration Fix. Both contain pre-built Windows 2000 Acceleration and Windows 98+95 Acceleration REG fixes. The fix builder can build custom fixes with custom thresholds and custom speed-factors. [Edit: Beta now over, and fixes released.]

I have built some .REG mouse fixes that make XP/Vista/7 emulate Windows 2000 & Windows 9X mouse acceleration. I need some beta testers to test the Windows 2000 Medium and Windows 2000 High accel fixes, just to be 100% sure they are safe. If you can help test the fixes, please send me a Private Message, by clicking on the 'PM this member' envelope icon below my name at the top left of this post. @ownage11 : This includes you. If you can test the fixes, please send me a PM. A normal CPL or Cheese or MarkC mouse fix is 100% safe to use. The W2K Medium and High fixes are not normal. There is a very small chance that they might not be safe. I have tested them (on 3 different PCs) and they work for me, but I need more testers to be 100% sure they are safe. To test them you will need one of: - A Windows logon user account that is separate from your normal login. You login to Windows using that separate account, and test the fix. OR - Your PC boots to the Welcome screen or Logon dialog, and you already have a second logon user account that you can use if needed. You know that that second account is enabled and can be used to login. You login to Windows using your main account, and test the fix. OR - You have a Virtual Machine you can test the fix in. You take a Snapshot of the VM, and test the fix in the VM.

No ... and yes... There are 2 ways of writing the formulas: One way more EASY easily readable and understandable by us humans, so we can understand the rough calculations, and another way showing the EXACT internal calculations done, if we need to be sure that the internal rounding is OK and remainders are being handled as we want them to be. I've given the EPP=ON EXACT formula, but the EPP=OFF EASY formula, which is why it looks like a 65536 is missing. Here is the EASY formula for EPP ON: If: - Smooth_X is the delta SmoothX value of the segment (SmoothMouseXCurve - SmoothMouseXCurve[i-1]) (1.0 = 0x10000) - 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 =MouseSensitivity/10 (1.0 for the 6/11, "10" position) Then the final sensitivity (Windows 7) is: Scaling=(Smooth_Y*((DPI/150)*MouseSensitivityFactor))/(Smooth_X*3.5)) (BTW, this is a simplified formula that only applies when the segment starts at 0,0, so it can be used for 1:1 fixes and the like...) If we want to understand how the 'Enhance pointer precision' accel works, we can use the EASY formula. But the EASY calculation, if done on your desk calculator, or if done by Excel, does not exactly represent what Windows does. If we want to make sure that a curve we build has EXACTLY a 1.0 scaling (rather than a 65535/65536 = 0.99998 scaling), then we need the EXACT formula. (The EPP=ON exact formula is on page 2 of this thread.) When EPP is ON, the EASY formula and the EXACT formula sometimes give different results. Here is the EASY formula for EPP OFF: if (MouseSensitivity <= 2) MouseSensitivityFactor = MouseSensitivity / 32 else if (MouseSensitivity <= 10) MouseSensitivityFactor = (MouseSensitivity-2) / 8 else MouseSensitivityFactor = (MouseSensitivity-6) / 4 Scaling = MouseSensitivityFactor For creating a graph comparing EPP=ON versus EPP=OFF, I would use the EASY formulas for both. Neither of which have a 65536 in them. Here is the EXACT formula for EPP OFF: (The scaling factor is stored in fixed point 24.8) if (MouseSensitivity <= 2) MouseSensitivityFactor = INT(MouseSensitivity * 256 / 32) else if (MouseSensitivity <= 10) MouseSensitivityFactor = INT((MouseSensitivity-2) * 256 / 8) else MouseSensitivityFactor = INT((MouseSensitivity-6) * 256 / 4) Scaling = MouseSensitivityFactor BUT... If the EPP=OFF EASY calculation is done on your desk calculator, or done by Excel, it gives the SAME result as the EXACT calculation, so there is no point in using the exact calculation, which one reason I didn't include any 65536 or 256 in the EPP=OFF formula. Yes, the attachment is correct, although I suggest dividing the X-axis by 65536 so it runs 0 thru 3.5 Eh? Sorry, I'm not sure what you are asking here. The cyan coloured curve doesn't match what?

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 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). 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. 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. 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!

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: (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! You can't change your mind now! 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?

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!

Oooh, so tempting! If only it were true... 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 Strange things happen if the first point is not (0,0) - I wonder why MS even bothered storing it (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!

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. I totally missed the reference to "six" points! There are obviously only 5. What MS should have said is : 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. 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. 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.

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. 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.) 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! 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. 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... Similar comments as for Win2K Medium. I'll look forward to it. meh. That's a good idea. 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). - 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...! ) 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:

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.

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.

If the normal MouseSpeed, SmoothMouseXCurve, etc are missing, default values are used. The defaults are the same as the values normally present for XP. If you go into control Panel and change the 'Enhance pointer precision', it should create a MouseSpeed option.

Try this: Windows7_MouseFix_TextSize(DPI)=100%_Scale=1-to-1(2-to-1@2.7)_@6-of-11.reg Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Control Panel\Mouse] "MouseSpeed"="1" "MouseSensitivity"="10" "SmoothMouseXCurve"=hex:\ 00,00,00,00,00,00,00,00,\ 00,c9,00,00,00,00,00,00,\ 00,00,00,00,00,00,00,00,\ 00,90,0c,00,00,00,00,00,\ 00,00,00,00,00,00,00,00 "SmoothMouseYCurve"=hex:\ 00,00,00,00,00,00,00,00,\ 3c,4b,04,00,00,00,00,00,\ 00,00,00,00,00,00,00,00,\ 0b,67,89,00,00,00,00,00,\ 00,00,00,00,00,00,00,00 NOTE TO OTHER PEOPLE: This approximates W2K Low accel ONLY FOR A 500Hz mouse. If anybody tries this but doesn't have a 500Hz mouse, it won't feel the same as W2K Low accel. On Windows 2000 Server, Low was a threshold1 of 7, and I'm assuming that W2K Pro would be the same. mouse movements 1 thru 7 were 1-to-1, 8 and over were doubled. Since you have a 500Hz mouse, the counts that Windows sees are divided by 4 (only 1/4 of the time to accumulate counts when polling at 4 times the rate. So a stream of movements of 8 will now be a stream of movements of 2. The above curve applies 1-to-1 up to 2.75 counts per movement, then doubled after that. Because of the smooth curve, the transition between 2 counts and 3 counts will not be exactly abrupt like in W2K: 2 counts might sometimes map to × 1.5 if the previous movement was 3. It might feel like your old W2K, or it might not, because you might have gotten used to Windows 7 now. If your new mouse has a different DPI than the old, you may now move the mouse slower than you used to, or faster etc. Let me know how it feels. Give it a try for a while. It needs EPP ON to work. The magic numbers are: The SmoothX and Y numbers are nominally speeds in inches/sec, multiplied by 65536 (to give a whole number). Curve segment 1 has SmoothX = C900 (=51456), divided by 65536 = 0.785 inches/sec = 2.748 mouse counts per poll. The conversion between SmoothX and mouse counts is buried deep within Windows, and uses this formula: SmoothX = mouse counts / 3.5 So to make a curve segment kick in at 5 counts per poll, SmoothX = 5/3.5 = 1.428, converted to fixed point hex = 1.428 * 65536 = 0x16DB6, which is stored as B6,6D,01 Smooth Y is set so that SmoothY / SmoothX × 96/150 / 3.5 = [required sensitivity], with some funky rounding going on. For the first part of the curve, SmoothY = 0x044B3C (= 281404) And then [required sensitivity] = 281404 / 51456 * 96/150 / 3.5 = 1.0 96 is not a constant, it is the Control Panel Text Size, 96 corresponds to Text Size = 100%. 150 and 3.5 are hard-coded constants. I hope that's not too much info!

Yes it is possible. More or less exactly if you used to use Windows 2000 "Low" accel, but only somewhat approximately if you used to use Medium or High. Do you remember what W2K setting you had? And what settings do you have now (OS/Refresh rate/Mouse polling rate/Text Size)? (If you run the MarkC Windows 7 + Vista + XP Mouse Acceleration Fix Builder, and accept the default values, your current setup will be in the .REG filename created, just also tell me your polling rate.)

Windows 2000 mouse accel is described here: http://technet.microsoft.com/en-us/library/cc978664.aspx ... and here (excuse the translated Japanese and missing images): http://translate.google.co.nz/translate?sl=ja&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fweb.archive.org%2Fweb%2F20101029202016%2Fhttp%3A%2F%2Furawa.cool.ne.jp%2Ftb-works%2F37_Win_Mouse_Driv.htm W2K (and prior) accel was a crude mechanism using 1 or two threshholds. With no accel (MouseSpeed=0), mouse-to-pointer movement was 1-to-1. With 1 threshhold accel (MouseSpeed=1), mouse-to-pointer movement was 1-to-1 below (or at) the threshhold, and doubled when the mouse moved faster than MouseThreshold1. No smoothing, just a sudden jump, doubling of pointer speed. With 2 threshhold accel (MouseSpeed=2), mouse-to-pointer movement was 1-to-1 below (or at) the threshhold, and doubled when the mouse moved faster than MouseThreshold1 and quadrupled (×4) when faster than MouseThreshold2. The values for the 3 settings (MouseSpeed, MouseThreshold1, MouseThreshold2) depended on which W2K pointer accel radio button was chosen (None, Low, Medium, High): http://ltxfaq.custhelp.com/app/answers/detail/a_id/1205/~/slk-mouse-synchronization-issues#Windows2000 If you still use a mouse polling rate of 125Hz (or use the same polling rate as you had on W2K), it is possible to quite closely emulate the W2K "Low" setting using a XP/Vista/7 SmoothMouse*Curve curve. Ditto, it is possible to somewhat approximate the W2K Medium and High settings with an XP/Vista/7 curve. Here is some XP/Vista curves that approximate the Windows 2000 "Low" accell curve: http://www.gamefront.com/files/20858946/XP_Vista_MouseFix__XXHz_DPI_96_Scale_1_to_1_2_to_1_9___6_of_11_zip When I have some free time, I may build some "Windows 2000"-like curves for Windows 7 also.