What? You want logarithmic deceleration? Like velocity=log(mouse_velocity+1)?

MIND=BLOWN

I'm just wondering why the hell would anyone want such thing?
Maybe he meant velocity=-log(1-MAX(mouse_velocity,1))?
Sounds crazy, doesn't it?

perhaps he meant exponential

I meant like this - http://en.wikipedia.org/wiki/Natural_logarithm

So you meant that your crosshair goes opposite direction at low speeds? Ok. gl.

DELTA_X = delta_x1+delta_x0*ln(delta_x1/delta_x0)

=BAD IDEA

I don't get it =) What are xs

DELTA_X = cursor position variation

delta_x0 and delta_x1 are consecutive position increments
let T be the poling period

delta_x0/T = mean speed during movement 0

delta_x1/T = mean speed during movement 1

base acceleration = (delta_x1/T) /(delta_x0/T) = delta_x1//delta_x0

Ok, this is really bad idea :) formula depends only on last two pos increments and it can be as short as 3ms.
I always thought accel should be function of mouse speed - otherwise it would get too hardware/software dependant.

dunno how it works in ql, but the definition of acceleration is the difference of velocity between two dinstinct time frames.

my evil twin.

nemesis!

what the hell, dude, I've came from university with my mind totally fucked, opened ESR to read some shit about cheaters exposed and that kind of cooloutac mental flux
dafuq I see? Logarithms and exponentials!

For a topological space X, the cohomology group Hn(X;G), with coefficents in G, is defined to be the quotient Ker(δn)/Im(δn-1) at Cn(X;G) in the cochain complex:

\cdots \leftarrow C^{n+1}(X;G)\ \stackrel{ \delta^n}{\leftarrow}\ C^n (X;G)\ \stackrel{\delta^{n-1}}{\leftarrow}\ C^{n-1}(X;G) \leftarrow \cdots \leftarrow C^0 (X;G) \leftarrow 0.

Elements in Ker(δn) are n-cocycles and elements in Im(δn-1) are n-coboundaries. The cohomology groups with n ≥ 1 are called the higher cohomology.

Logarithmic accel like:

sensitivity_factor = max(1, log(mouse) + C)
pointer = mouse * sensitivity_factor ?

You *might* get close with a Windows accel curve, you might not.
The Windows accel curve only has 4 segments, and each segment is not *really* a straight line when plotted properly, so can only approximate any desired curve.
(See: http://libpointing.org/media/default-functions.png, Windows in green.)

If you can describe (with a formula?) what the response should be like, over what typical mouse speed range (use MouseMovementRecorder to measure speeds), then maybe an attempt could be made.

What if 0<mouse<exp(C)^-1 ?!

You mean what if 0 < mouse < exp(-C) ?
That's what the max(1,...) is for.

True, but it's really bizzare anyway. I doubt any non-smooth function would feel good.

Hmm i tried the program and i don't know where to get the info about speed. can u just give me an example formula and i just lower all the components that affect windows accel if it the accel is too fast for me considering it is logarithmic accel, or does it not work that way?

Read out the "MOUSE MOVEMENT' column values for various situations.
MouseMovementRecorder doesn't work as well in-game as it works on the desktop, so try on the desktop first, imagine you are playing a game and move, sweep, swipe, whatever the mouse at typical game speeds for a few situations (tracking a target, trying a 180 degree spin etc.
Take note of the "MOUSE MOVEMENT' column values.

Use :

MouseMovementRecorder > record1.txt

... to record movement to a file, then Ctrl+C kill it immediately when you have completed the test movement. This will let you record and see more than a screenful of numbers.

With those values, we would know the best place to put the 4 parts of a Windows curve. No point in putting the points at places that don't match typical speeds that you use.

Playing with example numbers shows me that a Windows curve can quite closely approximate a log curve.

Try this curve:
[q]Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Control Panel\Mouse]

"SmoothMouseXCurve"=hex:\
00,00,00,00,00,00,00,00,\
cd,cc,00,00,00,00,00,00,\
9a,99,01,00,00,00,00,00,\
00,00,04,00,00,00,00,00,\
b7,6d,09,00,00,00,00,00

"SmoothMouseYCurve"=hex:\
00,00,00,00,00,00,00,00,\
00,60,04,00,00,00,00,00,\
00,e0,0e,00,00,00,00,00,\
00,c8,37,00,00,00,00,00,\
00,78,b4,00,00,00,00,00/q]

What's the formula?
sensitivity_factor = max(1, M * log(mouse) + C)
M=1 and C=0 for the curve above.

What I'm about to say makes most sense if you can see a graph, wait for the moderators to approve the graph?...


I set the curve based on mouse movement values, in Mickeys or counts, for these mouse speeds (counts per poll):
Mickeys= 2.8 5.6 14 33
The first point is roughly e (2.71...), then ×2, ×5

For those mouse speeds, I set the pointer speed (pixels per poll):
Pixel GAIN= 1 1.7 2.55 3.5

Note: Ln(e) = 1, I set the pointer for the first point to 1.
Ln(5.6) = 1.72, I use a little less than that.
Ln(14) = 2.64, I use a little less than that, because the Windows curve bulges up greater than Ln(x) between points.
Ln(33) = 3.496, I use 3.5

Convert mouse speeds to SmoothMouseXCurve by dividing by 3.5, giving:
SmoothMouseXCurve = 0.8 1.6 4 9.429

Convert pointer speeds to SmoothMouseYCurve by SmoothMouseYCurve = PixelGAIN × Mickeys / Scale
Scale, for Windows 7, is Display DPI × 96 / 150.
Scale, for Windows 8, is Display DPI × 96 / 120.
(Display DPI is usually 100%, so that is 96/150 = 0.64)

For the first point, the calculation is SmoothMouseYCurve = 2.8 × 1 / 0.64 = 4.375

For the rest:
SmoothMouseYCurve= 4.375 14.875 55.78125 180.46875

In curve hex, 4.375 = 46000, entered as 00,60,04,00...

I think hoppan describes how to convert decimal curve values to hex, let me know if you need help with that.

Next steps would be to:
Tune the Mickeys used to define the curve to match the speeds you use,
Try the curve, and tweak M and C values as required...

[Edit: I misread my spreadsheet and stuffed up the reading of the last curve point. The actual hex curves were OK, but the calcultations I used to describe them were off for the last point. I've fixed that and also moved the last point down to a more sensible place, so its calculation is easier.]

Thanks, i tried your example curve and typed this - http://i.imgur.com/S0ANq.png and this - http://i.imgur.com/Gb6Pw.png into regedit. I'm a noob to all this so could you check if i typed it in correctly? Also by typing these two into regedit that's all i need to do to get a logarthmic curve right? Atm the speed is a bit too quick but i'll come back to you on it and show you my converted method (with the lower speed) so you can check if it's done right (if you don't mind. :)

Yes, that's what to expect and is correct after applying the curve I suggested.

Not sure if i am getting any of this right but i had a shot at it. I just lowered the first
mickey from 2.8 to 2.2 to lower the mousespeed of the accel and got the SMOOTHMOUSEXCURVE and
SMOOTHMOUSEYCURVE that way.

MIKCEYS = 2.2, 4.4, 11, 110
PIXELS = 1, 1.48, 2.4 (2.39 rounded off to 2.4), 4.7

SMOOTHMOUSEXCURVE = 0.63 (6.28 rounded off to 0.63), 1.26, 3.14, 31.4
SMOOTHMOUSEYCURVE = 3.4375, 10.175, 41.25, 807.8125

I have yet to convert the SMOOTHMOUSEXCURVE and SMOOTHMOUSEYCURVE to hex decimals.

If what i am doing is completely wrong then tell me so because to tell you the truth i hardly
get any of this so i'll just give you the mousespeed from mousemovementrecorder. Also trying to
get the values of SMOOTHMOUSEXCURVE and the pixels, i got really long digit numbers but just
rounded them off to two digits. Does this affect the logarithmic accel in anyway?

The Mickeys values are the threshold where accel kicks in. Lowering it makes the accel kick in earlier, and gives MORE accel (not less!)
(BUT re-doing the calculation again with PixelGAIN = 1 re-normalises it again, so it ends up in more or less the same place).

I made a labelling mistake in my original post: It should be PixelGAIN, rather than 'Pixels'. PixelGAIN = 1 is a scaling factor of ×1, and is 1-to-1, not just 1 pixel. The formulas are still correct and haven't changed.

To adjust the accel, decrease the PixelGAIN values.
(Keep the first one at 1.0, but scale the rest down by adjusting M and C.

M = 0.5 and C = 0.5 should give half the accel as before:
Mickeys = 2.8 5.6 14 33
PixelGAIN= 1 1.3 1.8 2.23

0.5 × Ln(2.8) + 0.5 = 1.015, I use 1 (we want 1-to-1 at lower speed, as a starting point)
0.5 × Ln(5.6) + 0.5 = 1.36, I use 1.3, because the Windows curve bulges up greater than Ln(x) between points, so I pull it down a little.
0.5 × Ln(14) + 0.5 = 1.82, I use 1.8, same reason as above.
0.5 × Ln(33) + 0.5 = 2.25, I use 2.23, same reason as above.

New SmoothMouseYCurve values are:
00,00,00,00,00,00,00,00,\
00,60,04,00,00,00,00,00,\
00,60,0b,00,00,00,00,00,\
00,60,27,00,00,00,00,00,\
00,fc,72,00,00,00,00,00

Curve looks like this:

(Wait for moderator to approve pic.)

Summary: Set the Mickey values based on how fast you move the mouse (measure with MouseMovementRecorder!) so that the curve has the best coverage of the speeds you use.
Move a mickey value higher to make an accel point kick in later (at a faster speed).
Move a mickey value lower to make an accel point kick in earlier (at a slower speed).

Then adjust accel at each Mickey point with the PixelGAIN values.

[Edit: I misread my spreadsheet and stuffed up the reading of the last curve point. The actual hex curves were OK, but the calculations I used to describe them were off for the last point. I've fixed that and also moved the last point down to a more sensible place, so its calculation is easier.]

I said:

Set the Mickey values based on how fast you move the mouse (measure with MouseMovementRecorder!) so that the curve has the best coverage of the speeds you use.

That's true, *but* the first mickey value does more than just that.
It determines where accel first kicks in.

Before the first mickey value, there is no accel, and response is straightline/flat.

In the curves above I suggested the first mickey value be 2.8, because that is close to e, and ln(2.8) is close to 1, giving the 1-to-1 for the very first, un-accelerated, part of the curve.

But 2.8 is perhaps a bit large, and you may feel that as a large range of mouse speeds where there is no accel (between 0 and ~2.8), and then accel may seem to suddenly kick in (for speeds faster than ~2.8).

Setting the first mickey value to 1.505 (the Microsoft value) may feel better, as long as the accel starts gently/smoothly enough.

Let me know how it goes.

[img]

lol@math

i'd be fucking stephen hawking if math got me mad pussy yo, but it don't so fuck that shit

do more weed sons

math on weed, now that's the shit

how bout quake on weed? )))

Is that even legal?

that's how I always play:]

man it makes me laugh the shit ppl do like this, get over it, man up and shoot ppl as is ;)