anyone have any idea on how to do this? I don't use accel myself but have a couple guys I know that do, none of which have figured out how to work source's accel to work like quake's.
someone asked me this years ago. it is possible to setup a source game to be the same as quake, but as the source engine's acceleration is framerate dependent, you MUST have a constant framerate in the source game, else it will fluctuate.
first set sensitivity, m_yaw and m_pitch the same as quake.
then in the source game set m_customaccel 1 and m_customaccel_exponent 1.
the last two settings are,
m_customaccel_max = cl_mouseSensCap
m_customaccel_scale = cl_mouseAccel * fps / 1000
where fps is your framerate in the source game, not in quake.
If m_customaccel_exponent is something other than 1, you cannot equate the two methods.
Assuming the engine uses 65536 for the maximum possible iterations of a 360 degree turn, an m_yaw of (360 / 65536) with sensitivity 1 would mean one of these iterations per mouse count.
The guys at id (HL ran goldsrc which was modified from a quake engine, and later goldsrc evolved into source, and I guess some characteristics like this were kept) found early on that this m_yaw made for ridiculously low sens, so they increased it by 4. This made the sensitivity numbers much more "normal" , like 2-4-8 etc.
With sensitivity 1, m_yaw x changes the view by x degrees per mouse count.
didn't think ANY original quake C/win code would remain after all the iterations of re-writes with moving to C++, directx and all :)
I think I still have the HL2 leaked engine sources somewhere, I should do some searching and check.
You don't need mouse accel to play Portal. You could play it with a fist up your ass and still it'd be one of the best gaming experiences you've had in a while
So m_customaccel_exponent 1 means what exactly? Power of 2?
In ql with mouseaccelstyle 0, what value should be set so that moving the mouse twice as fast results in twice the sensitivity? How does sens/yaw affect this?
yeah, well they're not really doing it on purpose. it's because you cant tell whether a piece of code has framerate-dependent behaviour just by looking at the code - you need to do some analysis first.
as developers try to do more complicated scaling algorithms, it's more likely they will accidentally break the conditions required for framerate-independence, to which they are oblivious.
It's ironic that the game where everyone gets constant 125 fps isn't framerate dependent for accel, and the game where a lot of people don't get 125 fps is. :(