//mouse
sensitivity "8.3"
m_pitch ".023"
m_rate "1000"
in_mouse "2"

//physics
cl_independent_physics "1"
cl_nopred "0"
cl_nolerp "0"
cl_physfps "77"
cl_maxfps " 385"

(running sys_highpriority in my autoexec.)

currently runnin a viewsonic vx922 monitor so can only run 75hz atm. maybe getting a crt soon so can crank it later. 385 fps seems smoothest though. get well over 900 stable so 385 is nice. just wanted to know if i was missing any key settings that can really help.

also noticed cl_forwardspeed backspeed etc seems to make a difference if u set it real high.. what is the ideal on what should be run? just set it to 320s on all cept 500 on upspeed as advised by console. any further discussion would be good.. cheers

why do u use in_mouse 2?

I really recommend you use in_mouse 1, this is the OS implementation and gives less buffer lag than dinput (in_mouse 2) or if you have the newest ezQuake you can try in_mouse 3

btw. what value are you running for sys_highpriority? Should be 0 or -1 for good mouse performance (generally).

75hz + cl_maxfps 154 worked good for me, with some FSAA and FSAF

According to EzQuake, in_mouse 2 is "recommended for uberleet gaming performance (c)". Also, if you are on Windows XP, won't using the OS implementation cause you to have mouse acceleration? Doesn't Quake III also use direct input all the time?

That uberleet gaming is from a long time ago, dinput is / was better with old mice and old systems from what I can remember. You have to disable OS acceleration, registry or some other fix. I think q3 also has a choice of OS / dinput.

ok it seems that in_mouse 1 and sys_priority 0 is the way to go.

i set in_mouse 1 in my config but when i exec it the console sais it will change upon restarting. so when i check the command it sais current value is 2 and latched value 1. if i set in_mouse 1 in my autoexec the same thing happens. how the hell do i set in_mouse 1 !!! seems that 2 is now set. !
also what is "FSAA and FSAF" ?

your config needs to be ezquake/configs/config.cfg otherwise you need to use commandline.
Since when is direct input not the best? B( can someone affirm this?

Not necessarily true Runamok, it seems newer versions of the nightly builds seem to use /My Documents/ezquake/ to store cfgs by default.

You have to do in_restart for the latched value to be enabled.

FSAA = full screen Anti Aliasing
FSAF = fs Anisotropic Filtering

These help to make the game feel smoother especially on tft screens as they smooth away some of the tearing feeling that can easily be witnessed in the jagged edges of walls and corners for example.

Runamok.foe
Since dinput has a buffer that causes very slight lagging / delay (very slight). From what I understand the in_mouse 3 dinput used in newest ezQuake builds is bufferless (or with big buffer) like the OS implementation, aka raw dinput, meaning that there is no buffering mechanism enabled.

ok ive started running in_mouse 1 and it definately seems smoother. but speaking to others they suggest changing m_rate and in_m_smooth also. when changing m_rate and in_restarting it does seem to change things. what is the definitive on running in_mouse and other settings that are going to change and affect ur mouse sampling rate. smoothness is of concern.

also, if i run the latest ezquake, the beta version i can try in_mouse 3 and then i dont need to add anything else. is there any point in running m_rate if running in_mouse 1 cause it uses os implentation anyways. but in_mouse 2 plus m_rate 1000 and in_m_smooth seems to change the feel also.

any feedback on these issues would be appreciated. cheers

I'd disagree because these will reduce your FPS and therefore make the game less smooth.


dinput buffer has a really different purpose, it does not cause any lagging or delay (cl_placebo 1 again?). It stores the info the mouse gave between the frames, that is while the client is bothered with other tasks, mouse data get stored in the buffer and will be read once the client reads mouse input again - in_win.c, line 1519, "while (1) {" -- here all the data from the buffer are read and applied (+ there is a new patch for handling the situations where the buffer wasn't big enough)

It's true that for Raw Input we use the unbuffered method, but the result is the same. For mouse only the latest info in the buffer matters for all situations, except for the mouse smoothing, where the data in the buffer are used to calculate a better "current position" -- but again, there is no input lag involved in this.

Raw Input can be good for example if you get mouse acceleration with Direct Input after in_restart - that's the reason I have to Raw Input.

Well ofc I'm assuming that you'll reach your target FPS with those on, if you choose to enable them. My target was only 154, which felt the best with a tft very close to what the original poster has, so shouldn't be that big of a stretch.


Well I'm not going to start arguing about this again. For me, in_mouse 1, OS implementation simply feels like real-time and judging from the post above, krohm (and many others I've guided towards 1) agrees. Or is everyone using cl_placebo 1? The "problem" with the lagging / delay is that it's very slight (as in close to unnoticeable) and it's very easy to get used to.

When you use in_mouse 1, in_m_smooth and m_rate don't work, because they are only for controlling dinput. Without dinput, you have to set the mouserate with some external program like usbrate or using your mouse drivers.

My suggestions are aimed towards the most accurate and instant feeling mouse control. This does not mean that they're the best settings for you. Some people feel like they need in_m_smooth on, so they are forced to use dinput or an external smoothing software.

You know, if the engine actually used the timestamp that dinput specifies, it would be able to cover up ocasional slow graphics frames (when other processes got too much cpu time), which would of course make the game feel even more awesome. But alas, I know of no quake engine which does.
Isn't this what independant physics are all about?

Mouse acceleration with dinput? I thought you got that with the OS implementation in Windows? I am as confused as ever. Could some developer please tell us which setting is considered the best? :/

ok i have ammended my config to use the following settings. These according to this post should be the BEST mouse settings for smoothness (using my mouses best refresh rate, ie OS mouse implentation)

//mouse
sensitivity "8.3"
m_pitch ".023"
in_mouse "1"
in_m_smooth "0"
m_rate "125"

my rate through windows has been adjusted to run 1000hz. so it should be running that, even with m_rate at the standard 125. in_m_smooth dont make a difference and in_mouse 1 is SET so all is good. I hope? anything im missing?

I will also disagree since we are talking about multisampling here and multisampling uses multiple frames (4xAA requires 4 rendered frames/backbuffers) to achieve antialiasing effect, so it's not only to bound lower your fps but it will also increase the input lag (depending on the fps you get, if you still have 500fps then it's no problem obviously).

in_m_smooth and m_rate only works with in_mouse 2 (dinput) so you can ignore those vars.

I have those similar settings except I use 500hz not 1000hz. I'll try in_mouse 3 to see if it makes any difference. So far its just sensitivity change but i'll test it some more.

I'm wondering about of a lot of this stuff as well. It could also be that some people 'think' they notice something different but it is just mentally because they change that variable.

Anyway, what is the reasoning behind using cl_maxfps 300 (lets say i have monitor 150 Hz) instead of cl_maxfps 0. I want as much FPS as possible. But 450 FPS I can't get stable and at the same time a lot of the times I can get 600 FPS or more. So I use maxfps 0, and I either don't notice any difference or maxfps 0 feels better. But a lot of guys say you have to put it at some value that you can keep stable. So where is the science behind all this..

Also, someone said sys_highpriority 0 is better?? I've always had it on 1 because I assumed that it is better to give QUAKEWORLD a high priority but apparently it is better for the feeling/mouse if you put it on normal priority. Anyone??

So so tempting to add a placebo mode for cvars, where it picks one value or another randomly at the start of the map, and doesn't tell you what it was until the end.


With a lower cap, your client spends more of its time sitting idle waiting for the next frame.
Your experience will be at its smoothest when every frame lasts the same duration (so long as its above a certain level).
If you run it uncapped, you get two updates one refresh, and just one the next (or 4 vs 3).
While if its capped to 300 fps at 150 hz, you'll get 2 frames per refresh, every single refresh.
And seeing as you won't see more than 1 per refresh anyway...
Uncapped fps is lower latency, supposedly, but its that little bit more jerky, and can make leading that little more awkward.

At least that's my perspective of this.


Depends on your mouse drivers.
Logitech drivers are somewhat famous for running as a process. By using highpriority, you are essentually starving the mouse drivers of any cpu time, which can noticably lag your input.
Additionally, there are some programs that run in the background all the time, that periodically wake up.
By using highpriority, they get less chances to wake up. But when they do wake up, they'll try and consume their entire time slice, which can be a bigger distruption than if they had woken up more often. It gives a smoother experience if they can work periodically, rather than in bulk.

Again, this is my perspective.

You might want to check this blog.


I don't think that the drivers run as a process in a normal sense. It is their control panel ("mouseware", or whatever it's called, "em_exec.exe" that runs as a process and interprets input as it is configured (doubleclicks etc). If you download logitech drivers, unpack the package, install the driver via device manager, then it won't install that extra control panel and you don't get extra processes running either.

But yes, the problem really lies there with the "em_exec". This means running your client at high priority might cause the client reserve too much cpu time --> the input gets lagged because it has to go through "em_exec" process and it doesn't have enough cpu time. However, this problem seems to have been a problem with mouseware 9.80 or earlier. The setpoint runs as a process too, but I haven't really used it elsewhere than on my laptop so I can't tell if it affects gaming in any way as my desktop machine uses windows default usb hid drivers for my mouse (g9).