Doom 3 to the best of my knowledge DID NOT have mouse accel.
It had some smoothness thing which actually seemed to lag the mosue.
You cna however set mouse accel in the Logitech drivers, not exactly sure if this will be the same as q3.
I made a choice to play with mouse accel off at the start of the year because of this very reason. Get used to it before q4 is here I say:)
The ESR q4 cfg whines are already starting, wait until you find out you probably wont be able to assign individual sensitivities to each weapons.
Raged pole/swede/usa/uk alert.
I agree also, this is why I stopped using it long ago, because I knew eventually it would not be able to be re-done correctly... so I didn't wanna get used to something and have to lose it later :(
My old 0.02 accel config was damned comfy, though.
got sens 3 accel 0.7 and i hope they dont only have cl_mouseaccel, but also in_mouse
and if they care about q3 players, they will have these commands.. i want in_mouse 1 und the sens settings im used to and just lean back and feel comfy
AFAIK, the Q3 acc. code is fairly simple.
So simple that it only took ONE email from some random gamer to have the devs include it in Painkiller. Apparently it's easily added.
Maybe you acc. boys could make a small petition or just mass-email Raven about this.
All right, I take it back, then.
I only heard it from the guy, who sent the email, that they told him they had added it after recieving his email.
But I guess they're a bunch of liars. :(
And yes, PK sucked dick, massively.
Could have been such a great game, but again they didn't listen to the beta testers and the quakers, and instead focused on single player (even though they claimed to be oh-so in touch with the 'pro' gaming community)
Luckily for me (if the lack of accel in q4 is true), I recently discarded the use of accel purely because it's a pain (or more precisely: you need to be good) to aim consistantly with it.
Logitech setpoint drivers do exactly that. Although the settings arent very flexible with only low/mid/high accel options. It also overrides the inherent win xp mouse accel if u want it to. The "CPL mouse accel fix" didnt really work properly anyway, so it's a welcome addition.
I mailed Logitech about a month ago and asked them to make accel in their drivers more flexible. I actually got an answer! "I understand you are having problems with acceleration in the Logitech drivers." I hope the guy forwarded that mail to one of the coders ....
It's unlikely we would be able to create Q3 type accel in a driver or external app. The reason is that Q3 acceleration doesn't directly affect the X/Y motion reported by the mouse, it affects the actual sensitivity value. It increases the sensitivity value depending on how far you moved the mouse and that is what makes Q3 style accel so good IMO. A driver or external app won't easily be able to change a game's sensitivity value, it might be possible to hack it for some games but for most games it would likely be impossible.
Couldn't it be the same form of acc. as the Logitech drivers have (which is good, too bad only 3 stages)?
And just allow to the user to set the value from 0 - 100.
Logitech acc. works with all games.
I wish Logitech would get their fingers out of their asses and add more acc. values. Low, med, high is simply not enough to choose from.
I, personally, woudl prefer something even lower than the Low in Logi driver.
It wouldn't be too hard to make a global acceleration driver and a GUI to control it. I don't know much about acceleration algorithms but maybe it is worth investigating.
His nick is anir. I know him a little also from the Blueprints forum. I don't think he has kernel driver development knowledge yet and maybe he hasn't the free time to learn it, but like you say, if anyone could do it, I agree it would be him, and he would do a good job of it.
A few month ago, Atalan did me a favour and implemented a simple acceleration algorithm in "mouclass.sys".
The algorithm is (pseudo code):
MickeysX(Y) := MickeysX(Y) * 2 -(+) 1;
The class driver "mouclass" usually applies to all connected mouses and modifies the reported information at a low level, so DirectInput is also affected.
Atalan himself doesn't seem to like any kind of mouse acceleration, so it is not very likely he has any personal motivation concerning this subject.
He did me this one favour and I really appreciate his efford.
I don't want to bother him again, because he seems to be very busy with his job and his family.
There are two methods how you could alter it for individual preference:
1. Get the DDK and edit the source code yourself
2. Disassemble the existing modification and alter it there (very limited options, though)
It really depends on the variety of algorithms you prefer.
Personally, I think Quake 3's implementation is rather flawed, because both data of the X- and Y-axis are accumulated and applied without axis-specific differentiation.
I don't know how you imagine optional increments in this algorithm.
The problem with floating-point numbers or "sub-pixilation" is either a remainder or rounding it to integers.
I have chosen this algorithm, because all possible results are always integer.
I have always wondered what exactly is in quake3 acceleration code. I have looked for what cl_mouseaccel actually does in google but have been unable to find it.
Could somone explain it here? Or email it to me at [email protected]?
When m_filter is set to 0 it just takes the latest mouse movement and stores it in the mx and my variables but when m_filter is not 0 it takes the mouse movement made in the previous frame as well as the current frame and adds it together then divides it by 2.
I'll do an example with mouse smoothing disabled and a 400 DPI mouse which has been moved diagonally in a single frame giving us:
mx = 100
my = 100
If it had been a 1600 DPI mouse the above would instead be mx = 400 and my = 400 for the same diagonal mouse movement.
The following is the start of the mouse acceleration code:
rate = sqrt( mx * mx + my * my ) / (float)frame_msec;
The above calculates the euclidean distance (straight line distance between two points) giving us 141.421356. It then divides that distance by the frame_msec which is 8ms when using 125fps. So rate will be:
rate = 141.421356 / 8 = 17.6776695
The following calculates the sensitivity value to use for this frame:
This code takes the sensitivity value we use and adds the calculated rate multiplied by the cl_mouseaccel we use. For this example we will use sensitivity 3 and cl_mouseaccel 0.25 giving us: