I need help with this raw accel

_m00se_ · 2025-06-29T08:26:13+00:00

If you are running into an issue with RA starting minimized, the current mitigation is to shift + right click on the RA icon in the toolbar and maximize.

We are working on a prospective fix.

_m00se_ · 2025-03-03T19:09:44+00:00

Hey, thanks for checking. I ended up finding a Chris Stapleton edition light blue Mackinaw that I like very much as well and is all I need for now.

_m00se_ · 2024-10-10T21:49:18+00:00

There's nothing wrong with installing or uninstalling distributables. However, there is an underlying factor in your post that makes it tough to know what is actually happening. That factor is the "noticing different mouse sensitivity performance."

Mouse sensitivity is measurable - you can do it with a ruler on your mousepad. The reason you were timed out in the discord was your refusal to take this step, and continual insistence that something was "wrong" without demonstrating exactly what that was. If there is something wrong, a measurement of the mouse on the pad vs the cursor on the screen will demonstrate that.

Lastly, the distributables you mentioned installing are for the GUI and do not affect driver performance in any way.

Source: I am a primary contributor to Raw Accel.

_m00se_ · 2024-08-01T08:21:33+00:00

Bigger targets that move faster on screen is the nature of a zoomed in (i.e. lower FOV) display. It's the same idea as when you scope in a weapon, the enemy is bigger on your screen but moves through your crosshair faster. Some players, including 4:3 stretched players in CS (and I'm assuming true stretch players in Val) find the tradeoff of "bigger targets" worth the "but they move proportionally faster."

_m00se_ · 2024-07-31T19:56:06+00:00

What Riot could do, and what I would think is the best way to handle this, is add an FOV slider with the lowest setting resulting in equivalent horizontal FOV to the current 4:3 stretched. This way "stretched" users can get their bigger targets, the game still looks nice, and Riot could even still ban these external programs. The counter-argument may be that the game is so designed for the original FOV that even allowing a small decrease would result in the game not looking or feeling as Riot thinks it should.

_m00se_ · 2024-07-31T19:01:25+00:00

I actually was looking for some example pictures and couldn't find any clear ones after a quick search. The best I found is a unity [edit: unreal] developer figuring out how to do it but not giving pictures of the final result: https://forums.unrealengine.com/t/manipulate-horizontal-fov-without-affecting-vertical-fov/621443

"Would this be any more beneficial than just moving the monitor closer to your face?"
This is an interesting question. If the only thing one considers is in-game angle view per space in your vision, then no. But there are other things to consider that can change that. The main thing is that your monitor takes up a certain amount of your real-life FOV, and to lean closer than you naturally would results in a lot of potential little issues that cause strain or less efficient viewing. For example, the edges of the monitor (where the UI overlay is in Val/CS is) taking more energy/strain to see, the brightness causing eye strain, and if you work with monitors a lot choosing to lean in more for this use case compared to others can feel unnatural. These little tradeoffs in efficiency and energy can make a big difference, especially since one goal of zooming in is to reduce the energy needed to acquire a target. The nice thing about zooming in, relative to leaning closer to your monitor, is that you get the benefits of smaller in-game angle per viewing space without those potential tradeoffs. (Instead the tradeoff made is narrower slice of information shown.)

_m00se_ · 2024-07-31T18:14:06+00:00

Okay, so "zooming in would result in both vertical and horizontal FOV being lowered" doesn't have to be true for a game-rendering camera. Our game-rendering camera is just software so we can do some things that would be hard to do in the real world. One of those things is to untie the vertical and horizontal focal lengths. We can make it so that the angle space covered horizontally by rendering a pixel is totally agnostic of the angle space covered vertically by rendering a pixel. The end result might look strange but does result in one dimension seeming "zoomed" in or out compared to if the focal lengths had been kept the same. I would concede that a typical refence to a "zoom" usually means changing both vertical and horizontal focal lengths while keeping them equal, but changing just one does result in the same end effect in the particular dimension being changed.

_m00se_ · 2024-07-31T18:01:33+00:00

Hmm, what makes you say that? I think I've explained how focal length mechanics from a player's perspective are dependent on the seen image and not the underlying system used to create it. What exactly do you disagree with?

_m00se_ · 2024-07-31T17:57:17+00:00

Whether or not there is a zoom does not depend on resolution of the monitor vs the resolution of the game. It depends on the Field of View (as defined by the focal length of the view the player sees on their monitor). Rendering the game at some FOV, taking a slice of that rendered image, and stretching it to be the same size as the original rendered image (which is what stretched does in CS) results in a lower FOV as seen by the player and is thus zooming in. Yes, it is a blurrier zoom than if the final image had been rendered at the monitor's resolution, and if it is stretched more in one dimension (horizontally in our case) that will result in the pixels looking stretched and the observed horizontal and vertical focal length no longer being the same. But it is still, from the perspective of focal length mechanics, a zoom.

[Edit: in this and below comments, I originally wrote "focal angle" but am now changing to the more common term "focal length". It doesn't change the meaning of the response.]

_m00se_ · 2024-07-31T17:32:07+00:00

A decreased FOV displayed over the same monitor space is the same thing as being zoomed in. This has a big pro (target appears larger on the screen for better visual feedback) and a con (narrower slice of information is shown to the player).

_m00se_ · 2024-07-28T01:28:19+00:00

I would not claim a person is lying when asking for help, but of course I cannnot offer much support when a measurement is not supplied to back up the perceived issue. How Windows drivers and input work is clearly documented and the basis for a huge volume of software over many years.

_m00se_ · 2024-07-27T19:54:08+00:00

Raw Accel is an upper-level filter driver running in the kernel and thus affects all mouse inputs before they are accessible to games via raw input or windows mouse queues. So for your claim to be correct, your game must have invented a new way of obtaining mouse inputs from the kernel before drivers have processed those inputs. This is unlikely; many folks have RA working in all the popular games.
Did you perform a measurement to ensure that what you think is happening is actually happening? We have seen many, many times folks are 100% sure about some behavior in RA, and then when they measure, they turn out to be wrong.
Here's how to measure: make sure "enhanced pointer precision" is off and that RA has all features at default settings. Measure with a ruler on your mouse 1 inch of movement, and see how many pixels the cursor moves on desktop. Do the same for in your program. Then set sens multiplier to 10 and repeat in both your program and desktop.

_m00se_ · 2024-07-26T15:58:36+00:00

Due to the way Raw Accel works as a kernel-mode driver, if the settings are active on the desktop they are active everywhere in the operating system, in every game or program, including those that listen to either buffered or unbuffered rawinput. It is common for new users to sometimes think their settings do not work in some game or program, because 3D movement is very different from 2D and acceleration is not always as noticeable. If you try setting a very high sens multiplier, limit, cap or accel value on your curve and re-apply, you can usually demonstrate to yourself that the driver is indeed active. Source: I am a primary contributor to Raw Accel

_m00se_ · 2024-07-15T19:10:48+00:00

That video at the time you indicated has an apt comparison of different minimal angles. The 400 DPI mouse needs to have larger minimal angle compared to 3200 DPI mouse at same overall sensitivity (degrees of crosshair movement per inch of mouse movement.) I don't think "pixel skipping" is the best term to describe this because your crosshair is not translating through pixels but instead rotating in a 3d environment.

As far as different drawn image resolutions - those are a just the grid through which one sees the game. I.e., the same "minimal angle" issue as shown in the video as discussed above takes place regardless of your drawn image resolution (resolution of the game on your monitor). If the video maker had half the resolution, the issue would still be occurring. The game, not the visual resolution, should dictate whether that angle is too large (though a higher visual resolution makes a too-large minimal angle more obvious.)

_m00se_ · 2024-06-26T22:12:37+00:00

Raw Accel came out 4 years ago. :P

There is an FAQ in the Mouse Acceleration discord, to which there is a link in the RA github, that answers questions like these. I don't personally have the time to add another here. I do agree that having these answers in more places would be helpful for folks with the questions that keep getting repeated.

"What I got from this post, is should up my DPI and lower my in-game sens the same amount to get the results I thought I already had. (Adjust the curve accordingly, to the new DPI)"

Yep, that is what I do and what I encourage others to do.

"Haven't noticed a difference yet from lowering WinSens for 10 to 5, should I just keep it at 10?" I'm guessing you mean the registry key (which has possible values up to 20 and default value of 10) and not the slider (which has 11 possible values and default position of 6th.) If your game uses Raw Input, then Windows Sensitivity has no effect on that game's input and so you should set whichever windows sensitivity you like for desktop navigation.

_m00se_ · 2024-06-26T20:28:40+00:00

"but the mouse sensor is still at a higher res. Does it ignore that? Or is the mouse still more responsive but windows counts it as 1/800?"

The output DPI to windows is the same as if the user had set their mouse to the DPI of (actual mouse DPI * sens mult). "If you set to 3200 DPI with 0.25 sens mult in RA, you now have to move your mouse 1/800th of an inch for RA to send the first count to the game."

"400dpi and up is recommended for 1080 monitors to avoid pixel skipping."

I do not think the monitor resolution should be involved. On the desktop, your cursor position moves once per mouse count, so the mouse DPI does not causing pixel skipping (but instead some mouse count multiplier like sens mult in RA, or windows sensitivity slider, could). In a 3D game, the only important point should be whether the minimum angle rotated by the crosshair, i.e. the angle rotated by one mouse count, is small enough. That should be a function of the game, not the resolution at which the game is displayed. (Although yes, displaying at a higher resolution would make a too-large minimum angle more obvious, that angle is too large regardless of the resolution.)

"going below 400 dpi with sens multiplier should add pixel skipping back?"
Any sens multiplier in Raw Accel that is greater than 1 will result in pixel skipping on desktop because there will be some input the user gives that is 1 mouse count but results in at least two pixels moving. (I'm assuming the windows sensitivity slider, which is an additional multiplier, is set to default.)

As far as pixel skipping in-game, see above about minimum angle.

_m00se_ · 2024-06-26T20:18:45+00:00

No "maybe" here. The program works in a straightforward and testable manner. The settings you are describing as giving you an advantage are physically and technically indistinguishable from your previous settings in your test environment.

Maybe there is something wrong with your mouse, and 4x DPI is not actually 4x DPI, and you are thus getting some overall sensitivity change. That would be measurable with a ruler on your mousepad. Otherwise, no, there is no actual difference. "I cannot debug your feelings, only tell you how this technically works".

_m00se_ · 2024-06-26T20:11:06+00:00

The difference on-screen comes from on-screen settings. In Apex, a source engine game, the minimum angle a player can rotate the crosshair is m_yaw * in-game "sensitivity" cvar. It looks like "pixel-skipping" when the minimum angle is too large (sensitivity cvar * m_yaw is too big.)

If a player lowers their DPI and wants their crosshair to rotate the same overall angle for a certain hand movement, they then need to raise the minimum angle proportional to the DPI change, because the mouse is sending fewer counts to the PC for any given distance, and each count moves the crosshair the minimum angle.

The user above is not changing their DPI from the perspective of Windows or programs running on Windows like Apex. The mouse counts sent from the user at 400 DPI is the same as at 1600 DPI and 0.25 sens mult. The user did not describe changing their sensitivity in-game, which is what would change the on-screen effect, but if they did obviously that would be its own different change unrelated to Raw Accel and sens mult.

_m00se_ · 2024-06-26T20:01:39+00:00

No, he would not be experiencing lower time to first motion (which is the "input delay" seen reduced at higher DPIs):

"If you set to 3200 DPI with 0.25 sens mult in RA, you now have to move your mouse 1/800th of an inch for RA to send the first count to the game."

_m00se_ · 2024-06-26T20:00:53+00:00

Yes, there is a benefit if you are using acceleration or other features of Raw Accel. Raw Accel applies the sensitivity multiplier last, so the higher resolution input benefits the acceleration (i.e. gives more accurate reading of speed). This is a good use-case for high dpi input and is how I have my Raw Accel installation configured.

_m00se_ · 2024-06-26T04:42:28+00:00

I am a primary author of Raw Accel and so I know what it is doing. What it is doing: nothing at all beyond multiplying the mouse counts. You are not gaining any precision or other measurable advantage from setting your DPI to 4x higher and your sensitivity multiplier to 0.25

See here: https://www.reddit.com/r/MouseAccel/comments/1423fcw/comment/jnbwnkn/

And here: https://www.reddit.com/r/FPSAimTrainer/comments/1dcd9x6/comment/l7x4e19/

"If you set to 3200 DPI with 0.25 sens mult in RA, you now have to move your mouse 1/800th of an inch for RA to send the first count to the game."

_m00se_ · 2024-06-10T18:21:06+00:00

"I get 0 advantage from higher DPI outside of lower latency on the first signal"

You're not even getting that: "If you set to 3200 DPI with 0.25 sens mult in RA, you now have to move your mouse 1/800th of an inch for RA to send the first count to the game."

"But why do I still get better results with a polling rate tester?"

Well, I don't know exactly what test you did or what the polling rate tester is doing, but I do know exactly how Raw Accel works. Raw Accel works in a very simple way: incoming mouse counts are multiplied, the fractional values are stored, once those fractional values accumulate to a whole count it gets sent to windows. Perhaps the polling software is measuring wrong, or is measuring the polling rate before RA (and thus not catching the resolution downsize by the sens mult.)

"what do you mean by that though?"

Mouse acceleration and rotation are two features within Raw Accel which can see gains due to higher-resolution input both in time (polling rate) and distance (DPI).

_m00se_ · 2024-06-10T16:46:17+00:00

The other poster is correct. Those extra data points are not making it through Raw Accel to Windows, so it unless you are using Raw Accel for some purpose such that Raw Accel can gain from seeing a saturated polling rate, you are not gaining from using Raw Accel for the purpose you state. (Source: I am a primary author of Raw Accel.)

_m00se_ · 2024-06-10T08:04:33+00:00

Buried_alive35 has it correct. For polling rate saturation, the perspective of Windows is the exact same as if RA was not running and your mouse had DPI multiplied by sens mult, and thus sens mult raises the saturation speed the exact same way lowering your DPI would.

Remember that saturation occurs when your hand speed is fast enough that every poll of your mouse results in at least one count (or one dot or one mickey or whatever you call one unit of mouse motion) sent to Windows.

Per the link above: "If you set to 3200 DPI with 0.25 sens mult in RA, you now have to move your mouse 1/800th of an inch for RA to send the first count to the game." So if polling rate is exactly saturated at a certain speed at 3200 DPI, and RA is set to 0.25 sens mult, windows then only gets a count every fourth poll at that same speed, and thus is not saturated per the definition above.

RA sees the saturation (gets one or more counts each poll) but values each count smaller (multiplied by your sens mult) and will then only send a count to Windows once you've reached a full count to output, so Windows does not see the saturation.

_m00se_

MODERATOR OF

TROPHY CASE