Cyborgs get some with 25cm/360, human beings with 30+. I use 35 in some games and never cared about it during 180° flicks.

errh cyborgs get some with 15cm/360 ran enotus a while back while playing and did loads of 1.5-1.7m/s wrist flicks and peaked at 2.7m/s

ingame conditions plz. I could make my first gen da skip too when I wanted to.

while playing.

EDIT: iirc I did it while playing 4 person ffa on ospdm5 in cpma and I did loads of 180circle jumps ( aka TURBO FLICK ).

"When im in windows, and doing trying some hardcore sweeps, mousemovementrecorder doesnt show any negative or positive accel what so ever. But when im in game, i can tell there is some."

neg accel is related to screen resolution afaik. that might be normal if u use higher resolution in win, than what u use in game

so, what is a way to solve that problem? I have Abyssus, have neg accel too time to time.

You have negative accel with the abyssus? I thought it had 4m/s perfect control. What's your sens?

3.08@450 dpi; no accel

raw input?

cause it's not the mouse for lowsens, what faerie said

Works good with a bit of accel :)

I did some tests with enotus.

Max speed is 1.73 m/s, with IME 3.0. No wonder if im feeling negative accel.

Same test with mx518, and it went over 3.33 m/s. And when I did "game like" sweeps, it went past 2.5 m/s.

But many quake players, cs players and so on still use Microsoft mices, do they have bigger sensitivity settings or what?

most "good" quake players use accel (cursor travels faster the faster you move the mouse, which is perfect for flick rails and 180° while having slow sens), so it's not much of an issue.

cs is not fast enough to experience that issue (small/short mouse movements), unless you use like 40cm/360 and flick all over the place for no reason and without lifting the mouse off.

AFAIK, there are 3 sources of negative accel:

1) Some mice have a 'normal' data path and can only send movements between -127 and +127. (MS IME is one of those)

To test for this, use MouseMovementRecorder, and if a fast movement shows X or Y DEVICE MOVEMENT of 100 or higher then negative accel is likely or possible.

The fix is to increase the polling rate, as you have done

2) Games that don't use Raw Input and don't use DirectInput often calculate mouse movement by forcing the (hidden) pointer to the centre of the screen, and recording movement away from that centre point.
Each time a movement is noticed, the difference between the current (hidden) pointer position is compared with the centre of the screen and turned into an in-game movement, and then the pointer position is reset to the centre of the screen again. This is repeated while the game is running.

If the position is checked a little slow (your frame rate is low), or the edges of the screen are a bit close to the centre (your in-game screen resolution is lower), THEN the pointer can sometimes move all of the way to the edge of the screen, and get "stuck" there, because all extra movement past the screen edge is discarded (WIndows won't let the pointer position move off of the screen.

Follow this link to test: How to test for Negative acceleration [link].

3) The sensor in the mouse is not fast enough or good enough to see the mousepad flying past under the mouse, or the mousepad surface does not work well with the sensor.

Try cleaning the sensor window or try a different mouse pad.

"1) Some mice have a 'normal' data path and can only send movements between -127 and +127. (MS IME is one of those)"

Hi, can you elaborate on that sentance? 127 is degrees?

A USB mouse has a 'polling rate'. The normal polling rate is 125Hz, which is 125 times a second and means that Windows will ask the mouse (via the USB hardware), 125 times each second, how much movement has happened since the last poll.

(The movement is measured in 'counts' or 'dots' or 'mickeys'. A 400 CPI mouse will send a total of 400 counts for each inch of movement.)

The mouse then sends the movement data to Windows in a 'HID report', using bytes of data.
A 'normal' HID report has 1 byte for the button data (which buttons are clicked, which are not clicked), one byte for the X (left-right) movement, 1 byte for the Y (up-down) movement, and one byte for the scroll-wheel movement.

Because only 1 byte is used for movement in each axis, that limits the highest and lowest 'counts' that can be sent.
The count sent must be between -127 and +127 (127 mickeys left or up and 127 mickeys right or down).

Some mice send the movements using 2 bytes per axis, and can send larger movement numbers. Look for "16 bit data path" or similar in the mouse technical details.

So 127 is counts, or dots.
127 counts every poll, and 125 polls every second means 127×125 = 15875 counts every second. For a 400 CPI (DPI) mouse, that is 39.7 inches/sec, or almost exactly 1 metre/sec.

Graphs and more explanation for a MS mouse are here :
ESReality MouseScore 2007 - MS Wheel Mouse Optical 1.1a [link].