The actual sensitivity you get at any one time is calculated like so:

actual_sens = sensitivity + cl_mouseaccel * rate

where rate is the speed at which the mouse is physically moved. I'm not sure what units you could express it in, but i imagine its value involves many factors such as windows sens, mouse driver, sensor etc.

However you can view it using cl_showMouseRate, which will print the rate and actual_sens values together.

Ah, that helps a lot, but I still need to know the way it determines rate...

Well I can't give you an exact formula, as the mouse movement values are supplied to Q3 by the operating system. But if you do a bit of thinking, the rate should have the following proportionality:

rate = k * R * S * W

where R = Resolution of mouse sensor
S = Speed of mouse movement
W = Windows sensitivity (from 1 to 20)
and k is some scale factor.

k is very roughly 0.0001 for me, whether this encompasses other variables I can't tell you.

btw, why do you want to know this?

Hrm, this is much less reliable than I thought.

((res width * (360/fov)) / hand for 360°) = dpi

This equation should tell you about how much dpi you need to get the most out of your hand movement. However, I can't seem to figure out just what I would need to reliably apply accel to it.

In that case, your "hand for 360" (which I presume is the mouse distance moved for a 360 degree turn) will obviously be dependent on the speed of the mouse movement.

I don't have the time to do a formula for it, but maybe later.

Yes, you have it right. I suppose the equation doesn't really need a constant to work in both accel and non-accel situations, but I'd like at least one for each.

I wouldn't bother trying to find a "perfect" value, just set it to different values with a sensitivity you feel is comfortable for aiming but slightly too low for movement etc then raise it untill it feels "tight but smooth".

I'd rather know at least how much minimum DPI I need to make sure that my comfortable sensitivity isn't a little off.

A little off what? :D

Sujoy did a DPI-Res "perfect" calculation somewhere on this site. Adding accel makes that "perfect" sens "not perfect".

I want the ability to hit every pixel in a 360 degree field without the need to lift my hand. That way, when I pick a mouse, I know what I should get. However, I'd assume that having MORE DPI than your minimum amount would work just the same. I just thought it might be nice to know.

As far as accel, I just want to be able to apply this same equation to accel in case I ever need it later or in case I find someone who wants to know.

Then it would totally depend on how fast you are moving the mouse. Since the sensitivity changes depending on the speed of the mouse, it's possible you might be moving so fast that your sensitivity is skipping pixels.

However if you are moving the mouse that fast, you almost certainly aren't going for pixel perfect aim. There's a balance somewhere.

In my opinion having acceleration means that your regular mouse movement, for running routes etc are unchanged. The changes are for fast flicks e.g. rocket jumps, where you don't have to move so far to get the whole flick. And also for slow movements, where you're trying to go pixel perfect.

Therefore I would conclude that acceleration means you need less dpi to be effective, since it's the slow movements that want pixel-perfect accuracy.

I can see this being debatable.

I agree. Certainly, for this to work, you need a certain amount of DPI to hit things at least, but going up to your max speed with accel, you'd need a certain amount of DPI that would handle everything.

/*
=================
CL_MouseMove
=================
*/
void CL_MouseMove( usercmd_t *cmd ) {
float mx, my;
float accelSensitivity;
float rate;

// allow mouse smoothing
if ( m_filter->integer ) {
mx = ( cl.mouseDx[0] + cl.mouseDx[1] ) * 0.5;
my = ( cl.mouseDy[0] + cl.mouseDy[1] ) * 0.5;
} else {
mx = cl.mouseDx[cl.mouseIndex];
my = cl.mouseDy[cl.mouseIndex];
}
cl.mouseIndex ^= 1;
cl.mouseDx[cl.mouseIndex] = 0;
cl.mouseDy[cl.mouseIndex] = 0;

rate = sqrt( mx * mx + my * my ) / (float)frame_msec;
accelSensitivity = cl_sensitivity->value + rate * cl_mouseAccel->value;

// scale by FOV
accelSensitivity *= cl.cgameSensitivity;

if ( rate && cl_showMouseRate->integer ) {
Com_Printf( "%f : %f\n", rate, accelSensitivity );
}

mx *= accelSensitivity;
my *= accelSensitivity;

if (!mx && !my) {
return;
}

// add mouse X/Y movement to cmd
if ( in_strafe.active ) {
cmd->rightmove = ClampChar( cmd->rightmove + m_side->value * mx );
} else {
cl.viewangles[YAW] -= m_yaw->value * mx;
}

if ( (in_mlooking || cl_freelook->integer) && !in_strafe.active ) {
cl.viewangles[PITCH] += m_pitch->value * my;
} else {
cmd->forwardmove = ClampChar( cmd->forwardmove - m_forward->value * my );
}
}

German Anonymous Tech-heads are at it again!

it's just aion/anir...

Actually I think this is a different guy iirc.

Nice... Anyone want to help me with making that a bit more easy to read?

That is one of the Q3 source parts I referred to to answer your original question. However the real answer you're looking for will not be found in there, or anywhere in the source code.

Why not?

mx = ( cl.mouseDx[0] + cl.mouseDx[1] ) * 0.5;
my = ( cl.mouseDy[0] + cl.mouseDy[1] ) * 0.5;

I belive x and y are distances that the mouse traveled in a frame. After raw data is supplied rate is calculated based on distance covered in a frame:

rate = sqrt( mx * mx + my * my ) / (float)frame_msec;

After that acceleration is calculated based on rate and in-game sens...

accelSensitivity = cl_sensitivity->value + rate * cl_mouseAccel->value;

// scale by FOV
accelSensitivity *= cl.cgameSensitivity;

...and added to the initial values:

mx *= accelSensitivity;
my *= accelSensitivity;

I could be wrong fcourse.

You're almost right, but reading the code's easy, everyone can do it. All you have done is the same as post #1 but in a more confusing way.

The real thing he needs to know is how to express those mx and my values in terms of the mouse dpi and the speed at which the mouse is physically moved across the mat.

Only then can you get an expression for the "hand for 360" as a function of mouseaccel and 'speed of hand movement' etc. I did get such an expression, but there's something a little wrong with it, so I won't post it yet.

For that you'd need the specifics of cl.mouseDx/Dy[]. Post those maybe we can find something there.

"hand for 360" can be more aptly replaced by "/360°. =P

I'm only using the terms that you introduced in your own post #4. And "/360°" or "per 360 degrees" means nothing on its own. A more correct description would be "distance per 360°"

I realise, I was just using some pseudo equation. =P

It seems mx and my are being reduced by half from the value returned by cl.mouseDx*. I assume *= refers to multiplying the first value twice? What about frame_msec? I assume that's millisecond, so does it go by time instead of frames rendered?

Also, I don't see how this has to do with FOV:
// scale by FOV
accelSensitivity *= cl.cgameSensitivity;

No, ignore that. He accidentally posted the code for mouse smoothing (m_filter) which takes an average. Also as long as you are not using +zoom, then the line

accelSensitivity *= cl.cgameSensitivity

has no effect.

Ah, I see. So smoothing just uses .5 of those values. The rest should apply to accel, though. Some things were left out that apply, i think.

Smoothing takes an average of the last X frames (It's set to a value in Q3 can't remeber which, Q4 you can choose your value of frames)

Is there more code that shows that? This part seems to only cut the value in half.

That's just what I've been told by various people in various places and it seems to make sense seeing as that's how mouse smoothing works in Q4 for example. :/

I've always heard the same thing about that it averages things out , but the code just seems to half values. Maybe I'm thinking m_filter?

hmm that's what I was talking about :x

I had thought the code for m_filter was m_smooth. I don't see that one, though.

you're getting owned mate :P

Look at the code. It's not halving the values at all. It adds the previous value and the new value and then halves - which is just an AVERAGE of the two.

mx = ( cl.mouseDx[0] + cl.mouseDx[1] ) * 0.5;

Stop trying to make it seem more complicated.

For m_filter 0, this doesn't happen, it just uses the new value.

Ah yes, I'd've thought it just a half but it's only two values.
But what are cl.mouseDx/cl.mouseDy and what are the mouse indexes?

You don't need to know about the indexes, one holds the previous value and the other holds the new value, that's it.

It swaps every frame, so sometimes the new value is in index 0 and sometimes the new value is in index 1. This is so the values don't have to be shuffled around all the time.

And that value is x/y information? I see it resets it to 0 after it gets done setting mx/my to the values. Are those values how many dots it as read since the last reset?

Yes

Well, then the only other parts I'm not too clear on are:

mx *= accelSensitivity;
my *= accelSensitivity;

and the value of frame_msec

You said the answer isn't here, though. You don't think this will help in the equation I was trying to make?

Those 2 lines are taking the values of mx and my and multiplying them by actual_sens (aka accelSensitivity). frame_msec is the frametime in milliseconds.

Does that mean it's FPS dependent?

No, it's just taking its discreet nature into account for consistency. Don't worry about that.

Ok here it is. I arrived at this equation theoretically, but I'm not 100% convinced, there's probably room for improvement.



D = Distance for 360
E = Mouse speed across mat
R = mouse sensor resolution
M = m_yaw
S = Windows sens scaler
B = sensitivity
A = cl_mouseaccel

k = whatever your mouse driver does to your sens

k = 1 for me

k accounts for either something that is dependent on the individual mouse/mouse driver.

Note that there are 11 possible Windows Sensitivity settings on the slider: 0.03125, 0.0625, 0.25, 0.5, 0.75, 1, 1.5, 2, 2.5, 3, 3.5

As you can see if you use no accel ( A = 0 ) then the equation simplifies greatly.

Can this be worked into my original equation? I still need to work resolution height with the width. Just not sure how yet.

also, are you using the XP mouse accel fix?

Here it is, it should give good results, but have a play with it and see what you get.

Equation 2

W = Horizontal (Width) Screen Resolution
F = FOV
R = dpi of mouse in use
U = Useful dpi

Remember, if you want U in dpi, you need to input speed E in inches per second.

Yes I use the XP mouse fix

I thought perhaps the XP accel might have been the constant. =/

It's something along those lines. It is introduced when calculating the number of pixels moved on screen from a movement of the mouse.

So now U is about how much minumum DPI would be needed? I've been running some numbers through it. Will this equation still support an accel of 0?

Yes it should now support all cases and give reliable results. And yes, U is how much dpi you need to be able to hit all pixels.

What's an average good number to assume for E?

I wrote a small program and plugged in some numbers. I don't know what windows sensitivity Cooller uses, but I assumed 10 as default. Using his config, I get 249.561088 (which he uses a 400 dpi mouse). I'd like to know some other people who use accel that I could try this against. I plugged in 1 second for E, though.

Depends on how you play. Anything between 1 and 10 I would imagine are everyday values.

Is the speed moved necessary or could it be removed? As it varies during play, it makes for unstable results here.

Also, why do you simply divide by the fov? Wouldn't you have to multiply to get the full 360 degrees from that? (W * (360/F))

It's been said many times in this thread by more than just myself: the application of accel is dependent on the mouse speed. That's the whole concept of accel - more speed = higher sens. So no, it can't be removed.

No, the 360 cancels from substituting equation 1 into your original equation.

I know that speed has to do with accel, it's just the speed varies, it makes it hard to estimate without doing a min/max speed for E.

I understand what you were initially trying to achieve, but unfortunately its not that simple. Your best bet is to estimate the max mouse speed and put that in.

I have the program I wrote use the 3 values that Sujoy talked about for high/med/low sens players. I have it display all three values and the average of the three. Seems to be working out pretty well. <3

I didn't notice until trying to change the value, but you removed D from equation 2. Was it not necessary?

Nope, Equation 2 is good now. In fact the main part of this whole problem is that D is dependent on how quickly the mouse is moved.

Let us know if you find out anything interesting from the values given by the equation.

Now I just need some config files that use accel. =P

Is k a part of accel or is it just a value? Without accel, should k still get calculated?

No k is nothing to do with accel.

Well, I haven't found many configs that use accel, but it seems that cooller only needs about 280 dpi with his 400dpi mouse. Fox's config ended up giving the value of around 675 and he uses the same mouse. That's somewhat interesting.