You have no idea what you're talking about.

M_filter doesn't halve anything.
m_filter smoothens the mouse by waiting for 2 values ( iirc ) and then averaging them before they take part in the ingame calculations, something that you don't need as long as you use 250hz or more.
You're not gonna be able to feel the difference between 500hz m_filter 0 and 500hz m_filter 1.

Old habits die hard.
Old placebos are invincible.
And you really have no idea what you're talking about.

i can feel the diff that's why im asking this question.

1st piece of paper : Old placebos are invincible.
2nd piece of paper : cyborgs are already replacing us.
*Puts em in a black box *

Pick one.

nope i can feel the diff.

1st piece of paper : Old placebos are invincible.
2nd piece of paper : cyborgs are already replacing us and they're really good at denying they're cyborgs
*Puts em in a black box *

Pick one.

negative i can feel the difference, the tiny shaky movements when i attempt to move my mouse in a smooth swing are gone when using m_filter 1.

This is on 500hz and 800 dpi

Indeed. I can feel the difference as well. That is why I play with m_filter 1 [because I also have been for the past 8 years or so] I am just used to it :x Hence....

Never change a running mule.

Or maybe your post is a placebo, you only feel that it solves the question but really doesn't.


Placebo effects are often a possibilty and can the correct answer many times, but you shouldn't abuse them just to get an easy answer.

How did you arrive that the "250hz" limit`, for example?

Pulled the number out of my ass ofc.

Logical path would be to wonder why m_filer was introduced and what it actually does. Not really hard to realize that unless you're incredibly anal you won't feel its effects past a decent refresh rate.

using 125 FPS stable with 120hz CRT monitor

Even though I shouldn't have said refresh rate, you should have understood I wasn't talking about that.

but i can still feel the difference from m_filter 1 or 0. And i have the perfect set up. So something is up

m_filter 1 averages the (mouse) input over 2 frames, essentially smoothing things out and making them less responsive because of:

a what you get (see) is an average of two input values, eg. it is neither your first or your second
b your input gets recognized only after the engine had to wait over 2 frames (to calc the avg)

it takes a 12 year old to figure out why some people apparently like it and can't get break an age old habit. on the other hand it should be clear why it should be avoided by everyone else.

edit:
a few weeks ago i posted the carmack note on m_filter when he introdoced it to the engine. if you really want to know why it was included search the fucking site and don't start a new topic just because the OCD you couldn't figure it out in 12 seconds.

I get that but it still feels different. Running around on high accel with m_filter 0 makes me wobble sometimes when i'm flicking and doing 360s, sometimes i over shoot or undershoot when trying to strafe around the map.

On m_filter 1 i never ever screw up my movements. I can do 360's every 2-3 jumps and never bounce into walls. (think cypher/av3k when they do that shit)

Something is up.

i'm not disputing that it "feels different," i was trying to explain why it most probably does. again: it's an habit people fell into years ago, in this case "years ago" literally means 9-11 years for some.

there is no magic trick going on, if you happen to like m_filter by all means continue to use it. imo it comes close to people liking "prediction" (angle snapping) on a sensor level.

but that other guy was saying there is no difference from m_filter 1/0 when you use 250hz polling or higher.

to me that seems like bullshit

i'm not that other guy though :d

carmack plan update ( http://www.team5150.com/~andrew/carmack/johnc...#d19980608 ):

Jun 08, 1998
I spent quite a while investigating the limits of input under windows recently. I foudn out a few interesting things:

Mouse sampling on win95 only happens every 25ms. It doesn't matter if you check the cursor or use DirectInput, the values will only change 40 times a second.

This means that with normal checking, the mouse control will feel slightly stuttery whenever the framerate is over 20 fps, because on some frames you will be getting one input sample, and on other frames you will be getting two. The difference between two samples and three isn't very noticable, so it isn't much of an issue below 20 fps. Above 40 fps it is a HUGE issue, because the frames will be bobbing between one sample and zero samples.

I knew there were some sampling quantization issues early on, so I added the "m_filter 1" variable, but it really wasn't an optimal solution. It averaged together the samples collected at the last two frames, which worked out ok if the framerate stayed consistantly high and you were only averaging together one to three samples, but when the framerate dropped to 10 fps or so, you wound up averaging together a dozen more samples than were really needed, giving the "rubber stick" feel to the mouse control.

ok well this is what i've taken away from this thread:

m_filter 0 is more precise
m_filter 1 has issues with input delay
m_filter 1 smooths out your average tracking input, but if you are using 500hz or higher you should already have very smooth tracking and faster input thus, you won't need m_filter 1

*m_filter 1 and m_filter 0 feel different at any hz with any sens


Is this true?^

Also, i'll stick with m_filter 1. The feeling here is much more consistent than with m_filter 0. You can move and dodge and do the same flicks each and every time. So this is much more valuable than a tiny bit of extra tracking with m_filter 0.

How can you improve your aim, when most of the time the aim itself is always changing because of how hard you swing the mouse and how much accel was picked up. If it's constant each and every time, then you can just build the muscle memory easier and become a flick monster.

ye, pretty much (imo).

what is interesting (new edit above) is that in this plan update carmack attributes the choppiness to frames with fluctuating (zero at worst) input samples which by all means should not happen even with a 120hz/125fps/125hz setup unless quake regularly drops frames.

now people have been wondering about the fluctuating fps counter for years... hm :D

one last thing to consider:
m_filter 1 averages the input samples over 2 FRAMES not over two INPUT samples. with higher usb hz the amount of input samples increases, the original "lag" (wait over 2 frames than average the input) does not decrease.

this could be problematic, again quoting carmack:

I knew there were some sampling quantization issues early on, so I added the "m_filter 1" variable, but it really wasn't an optimal solution. It averaged together the samples collected at the last two frames, which worked out ok if the framerate stayed consistantly high and you were only averaging together one to three samples, but when the framerate dropped to 10 fps or so, you wound up averaging together a dozen more samples than were really needed, giving the "rubber stick" feel to the mouse control.

125fps/1000hz/m_filter 1 -
average the input samples over 2 frames:
1 frame every 8ms/ 1 input sample every 1ms adds up to 16 input samples over 2 frames, pretty much what he was talking about ("a dozen more samples than were really needed").

with 500hz it would obviously be an average of 8 input samples, which is still a lot more than what he suggested.

see that's my point. Once you have set a rate for your mouse that you believe is "decent", you might be the one to feel the placebo effect that you can't notice a difference between m_filter 0 and 1.

So yeah, going in with a more number orientated approach might be in order.

For example, you could try relating the formula for the interpolation of the mouse input combined with the mouse's rate to the refresh rate of the monitor. See if that gives you a more objective result.
[bullveyr, if you are reading this, now is the time to jump in with some numbers ;D)

why would m_filter be related to usb hz or monitor refreshrate!? how on earth would relating them give us a "more objective" result?!

as I said, it's something I thought he could try. Difficult say if there is a

well, as both of you say m_filter is always waiting for a second mouse signal for an interpolation, so
there should be a time delay between the two signals. And I'd think that that time delay depends on the hz rate of the mouse. Thus, if I'm right, with a rate of 250hz your mouse input has a delay of 4ms (+whatever delay you get from hardware, etc)

But, the time interval at which your mouse changes position in the game's engine, doesn't matter that much until you get an actual visual feedback. That is where the fps/display refresh rate come in.

To exaggerate: If you only get one changed frame on your display every second, it doesn't matter if your mouse reports 1000 or 1 million positions in that same time.

On the other hand, only 4 mouse inputs per second with 125 fps, will not work.

Thus, I think it is obvious that there is some minimum amount of mouse signals that you need in relation to your fps.

But, I say again, that's just something he wondered when I read their discussion, couldn't say if something usable would come out of it, if someone really looked into it. (probably a lot more factors to consider to do it right!)


In any case, the change of getting a usable result is considerably better than from a discussion gogin like:

A: I feel nothing.
B: I feel it.
A: You are just feeling a placebo.
B: No, you are feeling a placebo.

tl;dr: everything is more objective than: "I don't feel it and you are wrong." ;)

if you'd be correct than - with 120hz/125fps - everything should be smooth as long as the usb hz is atleast 125?
yet most people agree on this being "choppy" in comparison to 250/500/1000hz. the numbers don't seem to add up :p

i've tried 125hz polling with 125 fps and 120 crt monitor. It feels choppy indeed. 250 feels fine, 500hz feels the best. With 1000hz i cant get a constant feeling with my mouse.

I use mx510 w/driver at 800dpi

agreed, found the same to be true with 60/75/100hz monitors too.

i stopped using m_filter 1 in ~2003 and "angle snapping" in ~2009 (or whenever xai came out) because i disliked the "guided" feeling m_filter gave me.
today i sometimes notice i haven't fully adjusted to the latter yet. tbh if i'd be playing for money i probably would not change these things unless forced too.

Maybe, but for a definate answer it needs much more thought, as there are a few things to rule out first.

For example, when thinking of stuff like this people often comfortably assume the frames and the mouse signals are "in sync", i.e. both start at t=0 and one is the divider of the other. (Don't know if you did this, too, but I did at first :] ) But you need to consider what if they aren't.

e.g. display (125 fps) gives a new frame at: t=0 ms, 8, ms, 16 ms, and so on.
Mouse (250 hz) gives a new frame at t= 1 ms, 5 ms, 8 ms, and so on.

Can't that happen? What would that result in?

And there are probably a lot of other problems.

i did not consider the syncing issue because that goes way over my head (and programming knowledge).

maybe you can help me out here because i'm getting confused...
let's assume for a second everything is in sync, what happens when there are multiple input samples for every frame displayed?
quake averages input with m_filter 1, but what happens at this point with m_filter 0?

carmack on m_filter (link above)
Mouse sampling on win95 only happens every 25ms. It doesn't matter if you check the cursor or use DirectInput, the values will only change 40 times a second.

This means that with normal checking, the mouse control will feel slightly stuttery whenever the framerate is over 20 fps, because on some frames you will be getting one input sample, and on other frames you will be getting two. The difference between two samples and three isn't very noticable, so it isn't much of an issue below 20 fps. Above 40 fps it is a HUGE issue, because the frames will be bobbing between one sample and zero samples.

I honestly have no idea how all that works exactly, so I doubt I can help you. And I very much like the ambition to find out about such things in details.
In the end, my whole point was that something can be considered and found out way beyond _input 0 feels better than m_input 1, and I think at least with you I have achieved that :D


(As for picking values, I'd guess programs will use the "current" value whenever they need one and dismiss all the values that are provided in the meantime. At least, that is how stuff normally is done in general control systems (Regelungstechnik). )

pretty much what i was thinking... if that is true though than with m_filter 1 (1-33 really) we'd atleast get an average of our "real" input samples while with m_filter 0 up to 7/8 (125fps vs 1000hz) of the input samples would be dropped. that's uhm harsh :p

that would also explain why id made m_filter a float and added new values with ql, *maybe* to compensate for the frequent use of higher usb hz. i sincerely hope that is not true :>

yes, the way I figure you could use more (possibly all) of your input. But I doubt if that it is really desirable.

Because with either you would add a high delay (waiting for new inputs) or and average that would rely a lot more on values from the past, depending on how it was programmed. So again, there are a lot of things to consider.
All I can say is that you are becoming very good at pointing them out even though I already said, I am not capable of answering them ;x

heh .) i miss the times when people like arqon/ rea/ anthonyj were around and able to take a look at the code.

one thing to consider though to ease our collective minds: assuming we have a 125fps/500hz/m_filter 0 setup which is both stable and in sync we would have 4 input samples for every frame displayed.

while that sounds horrible in theory we have to realize that it means a new frame is getting drawn every 8ms and a input sample is taken every 2ms. eventhough this is 4:1 (or 3 out of 4 samples being used) it's still insanely accurate if we consider what is possible to do for a human in such a short time.

reading carmacks plan update again one thing stands out:
he mentions that mouse control will feel slightly stuttery when the input samples over one frame fluctuate between 1 and 2 while at the same time this is not very noticable when the difference is between two and three samples.

* with 125fps/125hz/m_filter 0 and an unstable framerate we would have either 1 (stable fps) or 2+ (unstable fps)
input samples.
* with 125fps/250hz/m_filter 0 and an unstable framerate we would have either 2 (stable fps) or 3+ (unstable fps)
input samples.

this would explain why so many people claim the choppiness goes away at 250hz and the difference between that and even higher usb hz is not that apparent.

aargh... coders chime in, please. i will stop now :x

If you have a high polling rate, there are multiple samples per game frame. No samples are ever dropped or ignored - doing so would lower your effective sensitivity which would be extremely noticeable.

The details of what happens depends on which input method you are using, but they all qualitatively do the same thing. The multiple samples of mouse movement are added together to produce one 'big' sample, which gives you the mouse input for the current frame. This single movement is then scaled and filtered using the usual cvars to update the state of the game.

Now, as you have found, the m_filter cvar was originally added to solve the win95 problems of 40Hz polling. The filter takes the input for the current frame and averages it with the input from the last frame - there is no explicit delay or 'waiting' as you put it, however there is some implicit delay-esq effect due to the filter. As the quote explains, the filter is based on game frames (it has to be as it doesnt know about samples, it only has one input for each frame as explained above), and so the effective strength of the filter depends on the framerate - at 125fps, averaging two frames of input is hardly noticeable (8ms of input is small), but if you have 10fps the same operation involves a large amount of input (100ms from each frame).

This is the reason for extending m_filter from just two frames up to multiple frames, so it can be more useful at a high framerate to those that like the effect.

The modern reason for using m_filter is nothing to do with its original purpose - no one has a polling rate lower than their framerate. There is no problem with samples or lost input. It is just a smoothing effect that some players may like in small doses. Although you are correct about 125Hz giving you 1 or 2 samples per frame with an unstable framerate, which m_filter can help to smooth out. But a higher polling rate is a better solution.

nice, thank you.

rofl lmao .FFS ! DUDE . stop pls

Sure mister non-existent neg accel

sorry sir, but ther is a BIG DIFFERENCE between 500hz m_filter 0 and 500hz m_filter 1. either you didn't tested it or you are trolling.

with m_filter 1 the mouse feels less responsive, anyway i figured out that if you use high sens (less than 25cm/360), this can make your mouse feel less sensitive in slow moves.

There is absolutely a difference.

Scientifically speaking, m_filter 0 should be the preferred setting.

In practice however everyone is different and some prefer the feel and play better with it, and this includes many pros as well.

bs

and

cypher does no longer use it (he is at 450dpi sens 4.25 m_pitch/yaw 0.018 and 0.1 accel => funny cos these re exactly my sets for some time now (i mean same cm/360 and accel in translation) good to see him use it as well )

the main cause of introducing it was to help high sens players with smoothing out their aim for the cost of a small input lag

he still does use it(well at least he still did 1 month ago)

check his profile:

http://serious-gaming.com/attachments/players...Update.rar
--> chypa.cfg

seta m_filter "0"

that is old

weird, ill ask him l8r :o

I'll ask him at Dreamhack ;)

strenx and stermy don't use accel at all? really?

Stermy doesn't, Strenx doesn't ingame but he uses a kinzu ( accelfest sensor )

i dont use accel and use m_filter 1 o:

You also use a pretty config.

true that