The hex values have nothing to do with the hz.

The "120hz" you think you have is because most usb devices (such as most mice) run at 125hz.

Editing the hex in windows only changes the way the accel works and how the mouse moves.

Of course I could be incorrect, but I don't think the acceleration curve in windows depends on hz. And the hz from the mouse will be constant.

Hey, I think you are confused. Read the post again and if it still doesn't make sense ask me what you don't understand.

I know something changes along with the hz, thats why in the cheese fix there are multiple registry entries for different hz, problem is there is not one for 130, so I am trying to figure out how to calculate it.

Yes I started to get towards the end of my comment that you were talking about the display refresh. I did not think that the hz of the monitor affected the curve of the mouse movement.

I used to use the registry entry fix on xp and never noticed any difference between 60, 75, 100 or 120hz. (With regards to mouse movement). I don't understand WHY monitor refresh rate would affect the mouse curve in windows (Although I understand why fps would affect it in games)

I summon injx!

/slaughters goat

You running Vista? Because if you are on 7, you should be using MarkC's accel fix. If you are on XP, you should be using anion's accelfix.exe and forget about registry fixes altogether.

Hi I have used anirs? accelfix.exe but just wanted to make sure this setting is optimal as windows still might use it.

If accelfix.exe installed correctly, the enhanced pointer precision feature (name of the Windows' mouse acceleration) is dead and there is no way for it to affect anything unless the win32k.sys is modified again. Checking / unchecking it in the Control Panel/Mouse should have no effect whatsoever. The reg fixes merely modify the way epp works, thus accelfix.exe makes them obsolete.

Yea, I thought that was the case. I guess I am just paranoid it is not working properly and there still is some windows mouse acceleration. Which value would you use for 130 hz? I think the higher the HZ the higher the value in S m o o t h M o u s e X C u r v e

To avoid placebo, apply Test_Flatline.reg from http://www.filefront.com/17191014/MarkC_Windows7_MouseFix.zip
and log out&in (or just reboot).

If the enhanced pointer precision is still alive, you will feel it. If you feel no change (accel still present) you need to start looking the cause of it elsewhere.

Hey Hoppan, Just to clarify you're saying if I have anirs accelfix installed then both the Smoothy and x curves registry entries have no effect on my mouse?
Cheers.

Exactly :)

Cheers, Will try. OH and if it isn't present do I need to execute the Test_flatline reg again? or not?

is mouse accel properly fixed in win7? for example quake 2? i remember the double mouse accel speed call in old games was fucked up before anir's accel fix on xp when u used just the reg fix.

Mousefixes fir the wrong Hz value will still get rid of accell. Though it won't be exactly 1-to-1. There's a guide here somewhere on esreality on how to calculate your own mousefix.

Might be Hoppan who made it.

If you're to lazy, just use wcafix.

EDIT: yep hoppan's guide: http://www.esreality.com/?a=post&id=1945096

It's been removed from filefront! Still available here: http://www.vdclan.net/node/18

Extra details for the Cheese Mouse Fix.

Cheese Mouse Fix is just like the CPL Mouse Fix, but DONE PROPERLY.

Edit: The Cheese Mouse Fix needs the mouse pointer speed slider set to the middle (6th) position to get rid of the CPL Mouse Fix problems listed below...

The CPL Mouse Fix has problems, WHEN the 'Enhance pointer precision' checkbox is ON (or your game forces it on), which include:
- Not an exact 1:1 mapping of mouse movement to pointer movement.
- At refresh rates < 80 Hz, it moves the mouse pointer < 1 pixel for each mouse count sent, which causes bizzare wobbling and slowdown if moving the mouse slowly right and down.
- At refresh rates > 80 Hz, it moves the mouse pointer > 1 pixel for each mouse count sent, which causes bizzare wobbling and speedup if moving the mouse slowly left and up.
- At any refresh rate, moving the mouse slowly in small circles causes the pointer to move up and left slowly.

Cheese's Mouse Fix does not have those problems and works on any system that the CPL Mouse Fix works on.

(There is a wee problem with the 70 Hz .reg file: To fix that problem, edit the "01 50 01" so that it reads "02 50 01" instead.)

If the screen refresh rate you use is not one of the ones that Cheese has pre-built, you can create your own.
The numbers to use depend upon the Screen Refresh Rate you use (in-game I think, rather than the desktop refresh rate(1)).
(If you use "Large Fonts" on your desktop, that will affect the numbers to use also (even in-game).)

If your Control Panel>Display>Settings>Advanc... setting is "Normal size (96 DPI)" (which is the default value), then use these rules to build your own 1:1 curve

- Convert your screen refresh rate into hexadecimal (Google can convert it for you: http://www.google.com/search?q=60+in+hex and remove the "0x" from the front)
- UnZIP or extract Cheese's 60.reg file and rename it according to your actual refresh rate
- Edit it (Right+Click>Edit)
- Replace "3C" on the second line of the SmoothMouseXCurve setting with the hexadecimal of your refresh rate
- IS your refresh rate less than 100 AND also exactly equal to 1 more than a multiple of 3?
(ie is it equal to 61, 64, 67, 70, 73, 76, 79, 82...?)
If YES, then edit the second line of the SmoothMouseYCurve setting to 02 50 01
Otherwise leave it set at 01 50 01
- Save
- Run/Open (Double+Click) the .reg file you have created
Answer "Yes" to the "Are you sure you want to..." question
- Logout or reboot
- Enjoy 1:1 mouse:display mapping!

Mark


Notes:
1: If your in-game screen refresh rate is different than your desktop refresh rate, you will likely need separate .reg files for each situation.

If you use "Large Fonts", you will need different numbers in the .reg files.
(It's the desktop DPI setting that matters here, NOT any in-game DPI or screen resolution.)

If your Control Panel>Display>Settings>Advanc... setting is "Large size (120 DPI)", then use these rules to build your own 1:1 curve

- ... as above ...
- Calculate R1 = DisplayRefreshRate MOD 15 (divide by 15 leaving a whole number remainder between 0 and 14)
- Take the remainder result above, and calculate R2 = R1 MOD 8 (divide the remainder from before by 8 leaving a whole number remainder between 0 and 7).

- Replace "00 01 50 01" in the second line of the SmoothMouseYCurve setting according to this table:

R2: SmoothMouseYCurve value
0: 00 01 A4 01
1: 40 01 A4 01
2: 80 01 A4 01
3: C0 01 A4 01
4: 00 02 A4 01
5: 40 02 A4 01
6: 80 02 A4 01
7: C0 02 A4 01
(Note: the "A4" goes where the "50" was)

- Save and then continue as above

MarktheC wrote that
http://www.gotfrag.com/cs/forums/thread/346432/

Cheers man thats exactly what I needed. Just some clarifcattion though, Since I am going to be using 130 hz this translates too 82 hexadecimal value.
here he states
"- IS your refresh rate less than 100 AND also exactly equal to 1 more than a multiple of 3?
(ie is it equal to 61, 64, 67, 70, 73, 76, 79, 82...?)
If YES, then edit the second line of the SmoothMouseYCurve setting to 02 50 01"
Since my 130 Hz translates too 82 and 82 is 27x3 + 1 I should change my SmoothmouseyCurve setting to 02 05 01 instead of 01 50 01 right?
And also could someone with the insight explain why this change is needed? just curious.
Thanks again

An easier way to get 1-to-1 mouse fix sensitivity for XP is to use my Mouse Fix Builder here: The MarkC Windows 7 + Vista + XP Mouse Acceleration Fix Builder.
That way you don't have to worry about hex or decimal anything.

If you do want to instead tweak the Cheese fix, then I should have clarified:

"... IS your refresh rate less than 100 DECIMAL AND also exactly equal to 1 more than a multiple of 3?
(ie is it equal to 61 DECIMAL ..."

130 (decimal) isn't less than 100 (decimal), so leave it at 01 50 01.

The change to 02 50 01 is needed for some refresh rate values because of the rounding that Windows does for it's internal calculations. 01 50 01 ... usually rounds OK and gives exact 1-to-1, but sometimes the calculations round a bit low and needs a +1 bump to get exactly × 1.0

More information than you need:
Visit this website: http://www.convertit.com/Go/ConvertIt/Calculators/Math/Expression_Calc.ASP ... and enter this expression:

((65536 * ((( 0x01500100 * ((( 130 <<16)/96)&-1))/65536)&-1) / ( 0x820000 * 3.5))&-1)/65536

... Note that the answer is exactly 1.
The formula is a version of what Windows does internally, tweaked into form that that website understands. Bolded are 3 values: the magic value 01 50 01, the decimal refresh rate you use, and the hexidecimal refresh rate you use.

Now try this expression:

((65536 * ((( 0x01500100 * ((( 70 <<16)/96)&-1))/65536)&-1) / ( 0x460000 * 3.5))&-1)/65536

... Note that the answer is not exactly 1.
... Bolded are the magic value, 70 Hz, and 70Hz in hexadecimal.
70Hz is one of the Hz values that has a problem and needs a different magic value.

If the magic value is tweaked:

((65536 * ((( 0x01500200 * ((( 70 <<16)/96)&-1))/65536)&-1) / ( 0x460000 * 3.5))&-1)/65536

... Then the answer is now exactly 1.

I think in your case leave 01 50 01, but I'm not 100%. I'm sure if you msg MarktheC he can clear everything.

Ok cheers for your help. If I understood Hoppan correctly since I have anirs accelfix installed both of these smoothx and y curve registry entries will have no affect.

Yes, hoppan is correct.

You can test it by applying a REALLY bad curve : Test_Flatline.reg, turning EPP ON and seeing what your mouse reponse is.
If accelfix is running properly, then a bad curve (or any curve) will have no effect, even with EPP turned ON.=> therefore no reason to worry about tweaking any bytes in the curve.

Wow thanks Mark for the detailed explanation, exactly what I was wanting. Quite interesting too but a little over my head (never was a natural with math).
So since I have used anirs accelfix there is no need to use your Mouse Fix builder? Because my icon resolution is 96 dpi and my windows slider is on 6/11.
I also use RInput.exe when playing COD4 so I don't believe I have any acceleration, just being fussy.
Last but not least, with this equation

(pi * g) / (i * tan(f / 2))

in-game resolution width
real sensitivity (inches/360)
field of view (fov)

What happens if the estimated useful resolution (dpi) is lower than your mouses dpi? Say your mouse dpi is 400 for example and that equation says your estimated useful dpi is 200.
Would it be better if the estimated useful dpi was closer to your actual dpi? Ie tweaking the sensitivity in game to get 400 estimated useful dpi.
Sorry with all the questions.

Also haha, I have seen other calculators out there claiming to calculate minimum dpi until pixel skipping etc occurs, yet all these equations are different and yield different results :\
Quite confusing, I am placing my money on the calculations at http://phoon.us/mouse/ to be the most accurate for games such as quake and cod.
In the end I think as long as the estimated useful dpi is under what you real dpi is then tweaking your sensitivity in game until it feels comfortable for you is the best solution.

"... since I have used anirs accelfix there is no need to use your Mouse Fix builder?"

Correct.

"What happens if the estimated useful resolution (dpi) is lower than your mouses dpi? ... Would it be better if the estimated useful dpi was closer to your actual dpi?"

Nothing much useful DPI > mouse DPI is slightly not so good; useful DPI < mouse DPI is meh, whatever, good enough.

Tweaking the in-game sensititivy will change your real (inches/360) sensitivity, which would be disruptive.

"In the end I think as long as the estimated useful dpi is under what you real dpi is then tweaking your sensitivity in game until it feels comfortable for you is the best solution."

Yes!

Thanks for clearing that up. One last thing, whose equations for working out calculations like estimated useful dpi, cm/360 etc are the most accurate? Would they be the formulas on phoon.us/mouse?

for further reading start here:

http://www.esreality.com/index.php?a=post&...pid1852718

p.s. there's nothing wrong with have a higher dpi than the estimated useful dpi, as long as everything is functioning correctly.

Hey injx, I have read through that thread quite a while ago. I still get confused with how the game translates physical mouse movement into movement on the screen.
The whole idea of using degrees (m_yaw 0.022)? to translate motion is quite tricky to comprehend, maybe you could explain it using laymans terms.

An analogy would be a photographer with a digital camera. The photographer is able to move around, rotate his body and aim the camera in the physical world, then he takes a photo which produces an image. The resolution of the camera in no way affects his ability to move or rotate - it could be a 1x1 pixel image or a 1920x1080 pixel image - the control over his 'aim' is the same.

To complete the analogy, the photographer would be blindfolded, and the only thing he is allowed to see is the last photograph taken. Based on this information he has to decide how to move to prepare for the next photograph. So although there is no direct link between image resolution and rotation, the finiteness of the image limits the information available to the photographer. This provides a kind of bottleneck which we can use as a basis for estimating what the smallest useful rotation can be, and hence the lowest dpi for a given real sensitivity.

This is supposed to give a rough guide as to how much dpi is going to be useful - it's not a big deal if you don't have 'enough', but it may suggest you will get a noticable benefit from more. It certainly wasn't intended for people to screw up their setup just to try and satisfy this estimate.

The game itself obtains mouse movement in units of counts (raw input). The in-game mouse settings (sens, accel, yaw, pitch, etc.), when combined, provide a conversion factor from counts to degrees - the converted input is then used to update the direction of the player's aim. At no point in this process is the renderer or the screen resolution referred to - it may as well not even exist.

Some of your confusion may be due to older games using pointer input, whereby the game tries to reverse engineer the mouse movements by observing the motion of the (hidden) windows mouse pointer. This is something completely separate from how the game uses the input to produce rotation, and how an image is generated to visualise the result.

Excellent explanation that I think will help a lot of people understand. I just woke up so my comprehension is pretty bad at the moment but I still have one last question.

The question is, is it possible for your combined settings to be under a threshold when translated into degrees?

What I mean is if you moved your mouse enough so that on a desktop your cursor would move 1 or 2 pixels and you did the same in a game but none of the pixels when viewing that game changed. This means that if you were trying to make very fine adjustments in game you might have to move your mouse the equivalent of say 3-5 pixels on the desktop to get roughly 1-2 pixels in game of change at the center of the scope.
Another question is in a game say you move exactly 0.022 degrees does that mean every pixel will change to give the viewer perceived rotation or do the pixels at the very edge of the screen move first then the centered ones last? Because of the pixels in the center representing more than 0.022 degrees. Sorry if these questions are self evident from reading your explanation above I am pretty tired.

Quake stores angles as 16-bit integers, meaning there are 65536 possible angles in 360degrees. The smallest possible rotation is therefore 360/65536 degrees. This is much smaller than you will ever need (by design).

There's nothing particularly special about 0.022 - it's roughly 4 times 360/65536, but that's about it.

The pixels don't really move at all, they just change colour. It's not very helpful to think of pixels moving in 3D graphics - the geometry moves relative to the camera, not the pixels. For a 2D mouse pointer you *do* have somthing moving across the screen, but in 3D graphics you have a sequence of 'photographs' produced by a rotating camera.

Due to the perspective projection, the pixels on the edges of the image will tend to change (or "move") more than the central ones (this is more obvious on a large fov).

But the extent to which the pixels change depends on what you're looking at and how fast you are rotating - you don't have to rotate a pixel's worth in order to change the image, but this will depend on what the scene is made of, how detailed it is, and how you are viewing it. Either way, it's just a visual effect due to a finite resolution image.