i'm not a math guy but this looks interesting

Haha your flag is Japanese and you're not a maths guy? Nice try.

talk to sujoy he should be a mouse expert by now :P

Sujoy Roy ? the most successful professional video gamer ???

:

http://www.sujoy.com/about

ah ok

lol

What are you on about? Reviving a 4 year old thread to diss sujoy, of all the people on esr? Really?!

"Sujoy Roy is the UK's first and most successful professional video gamer."

total crap lol

I thought nvc was?

Yeah NVC for pres

Fucking James '2gd' Harding my fine sir.

So you can't implement say 0.1-0.9 mouse accel (Q3)?

I think you misunderstood.

Settings may have fractions, but the outcome (applied acceleration) cannot.

Mouse devices send ticks (or "mickeys") to the device driver (eg. X: -10 Y: +123) and MouAccel intercepts them.

You can't report a half tick - they have to be rounded.

so it may be ever so lsightly innaccurate, wouldnt it be the same as cl_mouseaccel in the end anyway?

I don't know how perceptible it'd be, but it is certainly less accurate than Quake 3.

Besides, Quake 3's acceleration is only an example - any (and multiple) algorithm(s) is/are feasible.

Quake 3 is GPLed : http://www.fileshack.com/file.x?fid=7547

To give you a first impression, I have built a test version of MouAccel simulating Quake 3's mouse acceleration with a cl_mouseAccel value of 0.1.

I have not yet written/generated an installer, so it has to be done manually - this is fairly easy (see "installation.txt").

Download: mouaccel_test_20061210.7z


The driver is optimized and stable as it has passed PREfast (all driver filters), Static Driver Verifier (all rules) and PnP Driver Test Tool (all checks), but still lacks usability features.

MouAccel should run on Windows 2000, XP, Server 2003 and Vista, but I have only tested WinXP SP2 yet.
Currently, there is no x86-64 build available (for Windows XP/Server 2003 and Vista "x64 Edition"), because the compiler does not support inline assembly.
Additionally, Vista "x64" might be problematic since it does not allow the execution of unsigned kernel mode drivers by default.

Third-party drivers like Logitech's SetPoint suite can vitiate MouAccel's mouse feeling with their own acceleration.
Of course, you should also use proper cursor settings (pointer speed at 6 [or 10 in registry] and no cursor acceleration).

I intend to release full source code (license undecided) once it has become more feature-rich.




For the developers lurking at ESR, I have a question concerning FPU instructions:

Floating-point math operations at kernel level are a bit tricky as you have to take care of the FPU context yourself.
This sounds rather difficult, but in reality it's just two apposite API calls.

However, you cannot use common fp routines supplied by the IDE - so you have to write your own ones.

I have written the following functions:

// round float to int
__inline int lrintf(__in float x)
{
int r;

__asm {
FLD x
FISTP r
}

return r;
}


// square root of float
__inline float sqrtf(__in float x)
{
float r;

__asm {
FLD x
FSQRT
FSTP r
}

return r;
}

(Please disregard "__in" - it's just for PREfast)


Are these functions safe with modern FPUs or should I add FWAIT instructions?

Edit: Forum is messing up the layout...

Working link please.

As you know, Sujoy is going to release that huge mouse-roundup, which also shows the negative acceleration in values.
I would like to see your MouAccel-tool counter the negative acceleration by giving acceleration once the mouse is moved at a certain speed.

Of course, that differs from mice to mice.

Hopefully that's not impossible to create.

That would be cool if you could "mirror" the negative accel perfect.

i don't think you can because negative accel is caused by the sensor clipping off at a certain speed

It depends.

As you can see in Sujoy's almanac, some mouse devices suffer from internal buffer limitation (they're capped at +127 or -128).
A mouclass filter driver cannot reliably remedy this deficiency as it actually doesn't even know about the real mouse itself, which is obviously necessary to determine the real distance covered.
Apart from extraneous metadata, the filter can only see MOUSE_INPUT_DATA packets.
In its present form, it can modify any variable of that structure, but cannot inject or discard packets as a whole (this is possible, though).

If internal buffers are not a problem (e.g. alleviated via increased polling rate) and someone can figure out a pattern in negative acceleration (device specific), it is theoretically feasible to artificially complement the coordinates.
However, I wouldn't call it reliable either.


As of writing this reply, I haven't looked into such algorithms and probably won't in the future.
I lack the necessary hardware and am usually unwilling to "fix" products broken by design.

this is a nice approach, thx for ur efforts!

"I would like to see your MouAccel-tool counter the negative acceleration by giving acceleration once the mouse is moved at a certain speed."

I hope so too.

any updates?

Whenever I have understood the underlying concepts - or at least believe so, my motivation usually fades away rapidly.
This is a personal trait I find hard to overcome.

This filter is my first C program, so on top of the Windows driver development basics I had to acquire the language first.
My interest was very high, but unfortunately (?) it took only two days to learn both (C is now my preferred language in most situations).

Features like installer, registry lookups and IOCtls are only gimmicks now.
Additionally, I consider the native registry API extremely inelegant.


Right now, I'm preparing the source code to be released, which particularly means:

1. Commenting (done)
2. Clean-up (done)
3. Examples (done)
4. Final testing (done)
5. Brief documentation (done)


The examples will include basic transposition of x- and y-coordinates, legacy Windows 9x/2k acceleration, approximated Quake 3 acceleration, my acceleration algorithm (more later), mouse wheel acceleration using my algorithm (to demonstrate possibilities) and maybe a Vista specific variant (unimportant).

I hope to release it soon and I might even implement additional features depending on my boredom.

omfg, dude, i LOVE this, even if its just the test and not changible i've been looking for a universal mouse accel program forever! and its the implementation i like, not step but a smooth curve! i cannot thank you enough for this :D

I have uploaded the source code and binaries: mouaccel_20070106.7z
There are various examples, including approximated Quake 3 mouse acceleration.

You will need the Windows Driver Kit or Windows Driver Development Kit for building the binaries.


If you're using WDK (a.k.a. WinDDK 6000) and want to reduce the build's file size, you can use my tinyWinDDK package.
I have optimised compiler and linker flags, updated the development environment to the most recent version and manipulated the Microsoft Incremental Linker ("link.exe") to disable the generation of unnecessary information (excluding 3 bytes of the DOS stub and Name of IMAGE_SECTION_HEADER).
However, these modifications break certain compatibilities, so be sure what you are doing!

If you need the full MSDN library:
MSDN Library for Visual Studio® Team Edition for Database Professionals (December 2006)


Depending on my motivation, I might release more examples.

the only reason i would be interested in this kinda program is for cs (but i hardly even play that so)
it's a good idea but most games already have mouseaccel implemented.

edit: (mind you i havent read most of the comments so if im repeating then ignore this \:D/)

I would really like to see the acceleration made more customizable (Ex. User can configure at what speed maccel starts cutting in, how steep of a curve it is). I find my tracking improves without maccel, but my snapping suffers - if this could be implemented, it would be possible to have the best of both worlds.

Maybe something like win98 driver? From what I heard the way it works is something between normal acceleration, and lack of it. There are simply two speeds, the first normal, and the second increased which is used to fast moves including reaction shots/flickers. There was somewhere guide how to set it that way on xp.
Also I dunno if thats exactly the truth how it is/works, but since I moved to xp, my accuracy and ammount of reaction shots I make decreased no matter what I do.

Super stuff!
Looking forward to a potential full release.

Very interresting. I'm personally not in favor of mouse accelleration at all, but if I where to suggest anything it would be to simulate the Q3 ballistics. For "some" reason I always felt confortable with the Q3 feel, although I've long since given up on the game itself in favor of good old QW. I will definitely try out your test version and provide feedback.

And thank's for doing something cool for the community.



/PaRa

I have uploaded my acceleration method (src & bin): mouaccel_mine_20070109.7z

I will most likely cease development and stop posting.

The Q3 acceleration method applied at the driver level strikes me as less than optimal. Since mouse movements must be reported in integers, the result is that the rounding results in a loss of precision. This effect is less apparent at higher speeds (Ex. With cl_mouseaccel 0.25, if the mouse it has moved 2 pixels physically, the 2.5 needs to be rounded to either 2 or 3, which is 20% off what it should be. At 30, 37.5 gets rounded to 37 or 38, which is just 1.33% off what it should be). The result is if you graph physical mouse speed to actual cursor movement, you end up with something that looks like a stepwise function, instead of a line with a constant slope like it would ideally be. Furthermore, your USB refresh rate will also affect how the acceleration works.

I agree, rounding toward nearest integer is not the optimal way to get fine-grained mouse movement.

The driver(s) I wrote should be regarded as Proof of Concept since I have abandoned development.

However, I am also working on a similar project, which employs slightly different techniques.
I'm now adding the previous fractional parts, saving the new fractional parts and then truncating the float (instead of rounding) to achieve subpixelation.
The abosulte error stays below 1 count, but the relative error is less.

Of course, I'm also measuring the elapsed time to ensure a consistent mouse feeling regardless of sample rate.

Besides that, there are a few technical differences, like:
- Hooking the callback chain instead of directly intercepting the IRP_MJ_READ IRPs
- Avoiding inline assembly for greater portability

That sounds awesome. I look forward to your results. I hope you find the time to introduce the ability to customize the acceleration values with a registry value too, since not all of us have the Windows DDK or the technical knowledge to compile it ourselves :P

nice

For some reason, the driver seems to cause Half-Life mods to crash when I have it loaded. HL CPU usage just spikes and crashes, so regrettably, I can't really use this :|

Was there ever a working version of this? :/ Anyone got it?

yeah he did a new version of it called moudrv, which can be configured via registry entries (its a mouse driver that is used in place of the standard windows mouse driver)

unfortunately he removed the post where he launched it, but i saved it so i'll upload here for you:

Instructions
moudrv (2008-02-01)

Read the instructions carefully, especially about how to configure the registry entries using the hex number converter.

To get the same accel as in Q3, you need to use

MouseAcceleration = cl_mouseaccel / sensitivity(q3)

and then set cl_mouseaccel = 0 in game. (for 6/11 windows and moudrv sensitivity left at 1)

Ahh very nice of you :) Thanks!

What to do if your accel/sens is a decimal number? My cl_mouseaccel is 0.04 and sens is 0.7 which gives ~0,0571429 and if I convert this number into a hexadecimal I get 0.0ea0e91933adac8, which is both too long to fit the Moudrv mouseacceleration value and it contains a dot which is not legal neither.

What to do?

you've done something wrong.

for those numbers i get 3D6A0EA1.

edit: you should be using this convertor:

http://babbage.cs.qc.edu/IEEE-754/Decimal.html

Ah thanks. I guess the other converter was silly. Why does one have to devide the accel with sens? It seems wierd that if I want to experince the same accel in other games as in QL I have to use my QL sens in the calculation. Why is that?

because the game will multiply the input by 'sensitivity', which will effectively scale the acceleration that was applied at the driver level.

dividing it out in moudrv ensures the combination of moudrv scaling and the in-game scaling results in your desired setting.

You are awesome. Thank you.

Well, there is a program called "Mouse Master" ( @ http://www.4gsoft.net/ ) and you can set individual accel settings for each app. The reason I don't use it for accel in games is because it won't apply the accel in q4 (and probably isn't as nice of an accel as q3/q4's). But anyway it should do what you want ;)

Hmm there was a post from doped which this is supposed to be a reply to, but ESR is being weird again it seems ;p

Anyone who removes their own posts from a forum all over the place, I'd have to question the reliability of what they posted for people to download in the first place.

Did aion just get upset over something people don't know about or were there too many bugs he couldn't work out in his program? Either way it's not too important to me, but I do wonder how many pro gamers actually use this 'mouse accelleration removal' tool.

The moudrv is rock solid, I have no idea why he removed it.
He just does all this stuff as a hobby and it's really invaluable to the competitive gaming community. I wish he'd get someone to help him and just make one final program, XP and Vista 32/64 bit compatable to do the whole works:

-complete slaying of the windows accel (1:1 movement)
-sensitivity adjustment (helpful if you have a 1800cpi mouse and can't use it as well on the desktop from the speed or play something like CS1.6 where the lowest in-game can be set is 1)
-accel settings (amazing q3 style like at present)
-scroll wheel accel (<3)
-Single port USB overclocking
-GUI (since many people have trouble trying to do this in registry or by having to replace system files.)
-No restart required
-Small file size

Moudrv included options for mouse smoothing, but unless your mouse is shit and tracks erratically it's not helpful at all.

I'd personally donate 50 dollars to him if something like this was ever made. He's made most of these tools separately in various stages of refinement. It'd basically be his opus magnum. Then just get LAN PC's equipped with it. =]

That would be way cool :o

Does anyone still have the source for this? I'd like to play around and see if it's possible to add a mouseacceloffset-like setting.

Yeah, all the links have failed. Really want to have some clue how it feels like.

#49.

Check Injx' comment (Comment #32) for links to Moudrv. I installed it today and it works like a charm.

Edit; Moudrv is a updated and better version of the program in the topic, afaik.

great thx :D

Feature I'd like to see: a way to make one direction of the x axis more sensitive than the other or vice versa. Same for the y axis.

Of course I know there's no 'clean' way to do this, if the game uses driver mouse settings and I have them set 1:1, I'd have to have at least one direction different from this.

If implemented via mouse hardware (changing the cpi), there's the whole problem that increasing the cpi is more than just a change in sensitivity, it's a change in feel. I'd be willing to try it though for sure. Bit of an engineering problem as to how the mouse would suddenly have to know which direction it's going and change the cpi immediately. Latency would be a concern.

It would be better if this could simply be implemented in the game itself. For example if quake live supported an 'm_yawleft' and 'm_yawright' or something. Can't change that stuff what with qL being closed source and all (and probably non-trivial).

So, driver level is my only hope, and long story short, it's a feature I'd like to see.

In XP I had a decent fix for mouse acceleration, in win7, I don't like the methods as much.

I don't like to use mouse software either, such as setpoint.

I recently bought a new mouse (zowie) to try out. No dpi buttons on top, only on bottom.

I stumbled upon this thread and driver. I really like it.

Floating point to Binary32 conversion is a complicated process, although I did eventually get the formula. A bit of a pain to change the speeds when you need a convert, isn't it?

I built a GUI for this driver, changing Speed, Accleration, Smoothing Maximum and Smoothing Sensitivity. The rate of change of each parameter can be in increments of (.01, .10, .25, .50, 1).

I like how the change in the value in registry is instantly felt in the driver.

I hooked a hotkey to each parameter and set a mouse wheel event, so when you press the chosen hotkey for a parameter, a mouse wheel scroll up or down changes the value of the parameter up or down by your chosen rate of change.

Anyone interested in this still?

Cool.

yes!

Yes please, I don't use it atm but a GUI would be very useful if I use them again in future.

Thanks!

Ok, good to see I am not the only one liking this driver.

I have created a new version now. Here you can see some screens of it.

http://img850.imageshack.us/i/mougui015.jpg
http://img847.imageshack.us/i/mougui014.jpg
http://img340.imageshack.us/i/mougui013.jpg
http://img862.imageshack.us/i/mougui012.jpg

You can see how each of the 4 parameters has a combo box to change what I call the "step rate". You can see a button to increase or decrease each parameter. You can see a progress bar being used as a visual indicator of the current value, as well as an input box that shows the numeric value.

You note on the right side the option to set your hotkey or modifier key. This allows you to set a key, such as "numpad plus" to a given parameter, such as speed. When you then depress and hold the hotkey, the mouse wheel scrolling up or down modifies the registry value. I like that part myself.

You note the mention of Configs and Presets. I am making the ability to have the scrolling not only change a given parameter incrementally "on-the-fly", but also to change up to 5 "configs" and 6 "presets".

A config would be one or more of the 4 parameters. So you could save the speed and acceleration at a certain setting in config 1, and maybe you include smoothing in config 2, and so on. When in config mode, changing a value up or down changes which config you are "loading".

The same works for presets, only those are strictly for the speed setting. So rather than having to scroll 8 times to reach a speed, then 8 times back to where you were, you scroll through the presets, much like a DPI button would do.

One can choose to use only 2 preset or config, up to the max of 5 config or 6 preset.

Also I included an .INI file with this, so you can set different parameters within the INI file, but you set them as regular integers and the program converts them to binary32 format for you. much easier than having to use an online converter.

It is interesting to note that with this driver and a mouse that has a DPI button, the DPI button will usually still work even without the mouses proper driver. I have noticed that if I set the DPI to 2000 for example, and use the driver to get the speed where I like it, it stays the same across most windows/applications/games. So it allows me to use the max DPI, which is a good thing in terms of how accurate/smooth the movement is, but instead of per game trying to get the speed just right, the driver ensures it is almost always exactly the same.

I have some more features to add, and some more testing to do, but I have most of it working. I have to sort out the best method to use the hotkey/modifier. It seems that in something like a game, where you mash down the "S" key to move forward, the low level hooks can become a bit troublesome. Once I figure out the best method to use, or how to tame such things, I will get a link here so you can play with it.

Nice one, looks really good, I'm sure a lot of people will appreciate it if you post it up here, as they should find it by google and word of mouth :)

Superb stuff.

When can we have it? :D

Pretty soon, I would think in a couple weeks, time permitting. It is mostly done, but there is a strange issue I keep having that I need to correct.

Alright.
Can't wait. :)

Here is the mostly finished beta version
http://mrwoojoo.com/sg/index.htm
(look for moudrvGUI)

I have not included the driver, you can get that link in this thread. This works pretty well, but there are a few quirks I have not yet solved. If you try it, you will likely use hotkeys to change a setting on demand, like in a game. I have noticed that at times, for reasons unknown to me, things get funky. I believe it is due to the lowlevel hook I used and the typematic rate of the key being held down.

I will most likely make a different version that the hotkey will "toggle" the mousewheel on/off rather than just holding the hotkey to enable and releasing to disable. Maybe some input from others will shed some light.

MrWoo.

Very good job man. It works so far. Although im not sure what the smoothing exactly does or how its related to max smoothing. Tried it some time back but cant remember if it was like accel or m_filter(?) . Anyway, now it will be much easier testing stuff with mousewheel or just alt & tab and doing changes in the GUI)

When im back at home i have to try to get it to work with Setpoint 5.2 - aion helped me getting moudrv to work with Setpoint 3/4 (just for comfort reasons and i always closed SP after i changed my G3 profiles back then.)

thanks again for moudrvGUI (beta ;))

Argh, almost missed this.

Make sure to post a whole new thread about this.
This is too good to get lost, just posted as a comment in an old thread like this.

Most people don't read all these replies.

Cheers for the work, btw!

He is right. If u start a new thread, i'll repost my feedback of course.

Have you still got the gui by any chance? The link is dead :((((((

My bad, found it:

http://www.esreality.com/post/2299662/help-mo...pid2299728

Nice, thanks.

Also, people on a 64 bit win system can use dseo13b.exe to sign the drivers.

Hmm, because this changes settings at the driver level in_mouse 3 doesn't remove it when you play Quake.

It would be really amazing and I would start using this again if it could somehow implement cl_mousesenscap from ql!

When I tried to install the driver, "moudrv" Windows came up with an error like:

"There was a problem trying to install the driver............. The driver is not signend by the manufacturer"

So the driver was installed correctly, but the mouse didnt work. I even checked the registry databse and saw that the correct folders/files was there.

Can you help pls?

Does anyone still have this?

bump, want more of this
hm, i want this (q3 accel) and control over usb polling rate, and for it to be signed by microsoft.

me too. the idea is old tho. http://www.esreality.com/post/1582296/#pid1582296

To be signed by Microsoft you need to pay some big money to the corporation (1500 USDs or so I heard).

thats not big money, especially in kiev, hehe
so, if someone put up donation fund, you'd only need 1000 people donate $1.5 each

no need to get signed by microsoft, just use testmode 24/7 and remove the watermark

no need to have a mouse either, just use the keyboard arrow keys. obviously I want a signed driver for convenience and security, not out of "need".

wait people actually still use mouse accel? LOL

This moudrv driver is awesome, great features (wheel accel), pointer accel also works great, no bugs, really smooth.
With this driver triple screen full hd res setup on a 400dpi in 2d environment is not a problem.