It's beyond me why sens would ever be anything other than a direct multiplier of mouse input perhaps scaled by a constant to make the values nice.

Yeah okay, maybe you can put your DPI in there and enter a value in cm/360 or deg/cm, but really the q3 system was the most intuitive thing.

polling data * polling rate * sensitivity constant * DPI???

everyone rolls their own

At the end of the day, linear sensitivity will always be calculated like:

angle delta = constant * sensitivity * mouse delta.

That constant is the only thing that should really be changing between games. In Quake, it is m_yaw or m_pitch. It doesn't have anything to do with polling rate, and the only good reason for it to be related to DPI would be to have the sens value measured in deg / cm or some other real world metric. Theoretically, the constant could be scaled according to FOV, which is ultimately an imperfect calculation, but I really think that would only confuse the player due to the trade off between similar sens feel while tracking and ability to perform standard turns like 90 and 180 degrees.

There just might be an internal sensitivity that is used and what you see in the crappy UI. For example, the Windows sensitivity slider gives different values at each notch but not according to any particular pattern. It's lame.

Guess what, we came up with different formulas for it.. so do the guys at epic, id, basically that's why it's different

Windows raw API vs direct input vs windows API... windows has like three apis for mouse input

There's no real answer to this question

Who is we?

Are epic and id different in any way other than in the constant scaling factor?

The formula I gave you is the definition of linear sensitivity. Any variation on that introduces some kind of acceleration. All of the Quake games and derivatives using their engines and Source games and OW and pretty much any game that is not a turd for mouse input uses this. I think most gamers would be upset at the idea of not being able to turn off accel.

Windows' various APIs are another layer on top of this that I'm not even talking about, and no game takes into account what processing, if any, they do on the mouse data.

you and i

I wrote: polling data * polling rate * sensitivity constant * DPI???
you wrote: angle delta = constant * sensitivity * mouse delta.

notice how those are diffrent?

now think about it

what if you and I are both working for companies wiritng game engines
suddenly the sensitivity works diffrently on two diffrent games

thus answering: "It's beyond me why sens would ever be anything other than..."

what If i want to write my mouse input code using windows RAW API and someone else writes the code using the other windows API for mouse input? then it will be diffrent in our games... thats why i brought it up

also, you dont consider the polling rate... what if i use your formula but poll the mouse twice as much?
then my true sensitivity is higher. what if i poll the mouse based on frame-rate?

I'm not understanding you.

You pulled some random formula out of your ass that has nothing to do with the way angles are calculated in any game. I showed you the actual DEFINITION of linear sensitivity.

That's the difference. I can do what you did to. Why not make the formula:

CPU speed * disk size * screen width / number of files on the hard drive?

"suddenly the sensitivity works diffrently on two diffrent games"

If both games are using linear sensitivity (something gamers love to have; look at how long they debate about the existence of the slightest acceleration in their mouse), then the ONLY difference will be the scaling constant.

It doesn't matter what API you use. It doesn't affect how the game calculates this shit using the data provided. That's just another layer for the user to worry about. They might be able to control it with something like in_mouse, or not.

It doesn't matter how often you poll the mouse. It will give you a measurement of the distance it moved since the last poll. So whatever the interval is, your game will update the correct amount. It does not change your sensitivity at all.

An example:

If I poll the mouse at 1000Hz, and each poll reports a value of 1, then every 1000th of a second, my view angle will change by "constant * sensitivity".

If I poll the mouse at 500Hz, then each poll will report a value of 2, for the same mouse movement, and every 500th of a second, my view angle will change by "2 * constant * sensitivity".

Either way, my view angle will change at the same rate.
In the first case, at

constant * sensitivity * 1000 degrees per second.

In the second case, at

2 * constant * sensitivity * 500 degrees per second.

You can see they are identical.

Somehow, I expected you to know this, so you may even be trolling me at this point. :D

you're completely missing the point

I wasnt trying to tell you the "correct" way to program sensitivity

I was trying to tell you that two different people will program sensitivity in two different ways, thus two different games will have two different ways of doing sensitivity

you asked "how could two different games have two different ways of calculating sensitivity?"

If you cant understand my attempts to explain it to you at this point then its pretty hopeless...

I tried out the idea that polling rate doesn't matter and you were right at least with windows RAW api, when i tried it out with my game which uses:

theta = RAW input * m_speed

where RAW input is polled every frame
Other games use quaternion rotation but I used Euler angles so my game has weird sensitivity compared to everything else

I'm not missing any point.

You can calculate it any way you like. If you do not calculate it the way I said, it will not be linear sensitivity.

It's as simple as that.

The reason I ask the question is rhetorical. (I didn't even really phrase it as a question.) It's stupid not to at least include the option of linear sensitivity, i.e. sensitivity with no accel. Only really casual games come with built-in accel you can't turn off.

Even your game uses the same method according to your description here.

It does not matter how you perform rotation, whether you use quaternions, euler angles, rotation matrices or anything else---so long as you code it correctly. An x degree rotation around an axis is the same just achieved using different maths.

then why is sens = 4 on one engine diffrent from sens = 4 on another engine?

maybe because im right

Because of that constant I was talking about.

Nice, i should add cm/360 value, lots of players modify m_yaw/pitch so sens only isnt accurate in every situation

Wow. So I thought I would be way off trying to adjust my sense over time to equal what I have in Quake live to champs...


according to your guys calculations....I was only .01 sens off of my real sensitivity :DDDD

Just surprised i got that close on the first day when beta was......still a works in progress :P

Thanks for the conversion to verify!

can you add converter from ql to q3 (osp 1.03 more precisely)? been playing both for some time and sens are not the same

I'm pretty sure both those games use identical sens calculation if you are using power 2, senscap 0, offset 0 in QL.

The other difference is that q3 only has DirectInput (in_mouse 1) and Win32 (in_mouse -1) input modes; there is no raw input (in_mouse 2).

So you can try to use in_mouse 1 for both. Maybe that will help.
You can also make sure m_filter is 0 in both.

If you are using any of those config hacks where you are zoomed all the time (to get a thin LG beam or whatever), there will be differences too. zoom sensitivity is calculated properly in QL but not in q3.

Other than that, if it feels different, it will be due to differences in rendering that you can't control.

Haven't used any zoom config afaik (started my QL config based on k1llsen's cfg) also haven't look for all these options, only know half of these console commands I just tried using the same sens + cl_mouseaccel and it gave me different results.

It's kinda unlikely you have one of those fancy zoom configs, which are not necessary in QL. They were just used as hacks in the OSP days to make the LG beam narrow due to the way it got scaled if you set your FOV very high and then zoomed into the FOV you actually wanted to play with.

If your m_yaw, m_pitch, sensitivity, cl_mouseaccel are the same in both games, then I'd say the most likely cause would be in_mouse, which needs to be 1 in both games so that they are both using DirectInput. in_mouse 2 is usually what is recommended for QL, but q3a doesn't have that.

If that doesn't work, then it is most likely just a fundamental difference in the feel of the games due to a compounding of various factors you can't adjust with configs.

in q3 of course I haven't zoom cfg
what I omitted to say is that I (re)started q3 recently after QL so my main problem is how to convert my (almost) perfect QL sens to q3, not the opposite

You can try changing in_mouse from 2 (I presume it is 2) to 1 in QL and see whether that is the source of the difference in the feel.

If it is, then maybe you have some scaling factor on your sensitivity in driver software that you can investigate, but it may still feel different without such a factor. In that case, you have to use a different q3 client that supports raw input as faerie_ suggested, or adapt to in_mouse 1 in QL---at least then the feel should be the same in both games.

There's a q3 build with raw input floating around, q3e or something. At the end of the day it doesn't matter, you can get exactly the same sensitivity in all 3 modes if you sanitize what you send to the game - that means no win sens or driver sens shenanigans and/or only using multiples you can reverse engineer -.

Yeah, I guess he doesn't want a new client if he's still using OSP.

All these games will calculate the same angle deltas if they're getting the same mouse input. I'm guessing differences in "feel" are a lot more subtle than that.

Just for the record, Quake3e works fine with OSP.

Thanks. Good to know. :D

i'd + you but i can't. thanks anyway.

Doesn't work for me:
In QL I have near 30 cm / 360
seta sensitivity "15"
seta m_yaw "0.022"
seta m_cpi "400"
seta m_filter "0"
And your calc gives 7 cm / 360 for my sens.

That's because you are using m_cpi 400, which converts your sensitivity setting from its usual meaning into a measurement of degrees per cm.

So you have 15 degrees per cm, which is 24 cm / 360.

If you have set m_cpi correctly, and your mouse DPI really is 400, then your settings correspond to a normal sensitivity value of 4.33.

So you need to plug 4.33 as your sensitivity into his converter to get the required sens value for other games.

"So you have 15 degrees per cm, which is 24 cm / 360.

If you have set m_cpi correctly, and your mouse DPI really is 400, then your settings correspond to a normal sensitivity value of 4.33."

So you are using the formula from http://www.funender.com/quake/mouse/index.html . Can you please explain what's the "usual" meaning of sensitivity? yaw*windows_scale*sensitivity together should produce value of type degrees per "dot". What's the meaning of a degree here? Sensitivity in that formula doesn't depend on FOV, but in aiming it surely does. Is there a formula taking FOV and aiming into account somehow?

Yes, that is the correct formula, except that windows sensitivity won't factor into it unless you're using in_mouse -1 in QL, which is unusual.

The usual meaning of sensitivity in QL is what you get when m_cpi is 0. In this case, the size of the unit that sensitivity is measured in is DPI dependent.

"yaw*windows_scale*sensitivity together should produce value of type degrees per "dot"."

Yep, so you pretty much answered your own question. :D

Sensitivity is measured in QL-rotation-unit / mouse count, where QL-rotation-unit is equal to m_yaw degrees, so its size is dependent on m_yaw and DPI.

If you set m_cpi to your DPI as you have done, then this dependency disappears, and we're using real-world units deg / cm.

"What's the meaning of a degree here?"

A degree here is one degree of rotation in the game.
When you use the mouse to look left or right, you're rotating around an axis. The number of degrees is how far you have rotated around that axis. 180 will make you look behind you; 360 back where you were originally looking, etc.

"Is there a formula taking FOV and aiming into account somehow?"

The sensitivity is purely concerned with the degrees of rotation for given mouse movement. If you want to scale your sensitivity due to a FOV change, you are faced with a dilemma. Yes, with a lower FOV, tracking aim and small flicks will feel faster, so you might want to scale down the sensitivity, but if you do that, the flicks you are used to doing for making 90 degree and 180 degree turns or hitting strafe jump angles for movement become larger.

You will see this exact effect when you use zoom in QL. It scales down your sensitivity and turning becomes harder while aiming feels approximately right.

There is a formula for this, but there is no perfect way to preserve the feel of sensitivity (even just for aiming) after changing FOV. You can only preserve the feel (required mouse movement) of one flick size (measured in the percentage of the width of your screen) while others will feel different.

The default QL zoom formula, for instance, preserves the feel of a flick equal to the distance from your crosshair to the top-centre of the screen. Personally, I prefer a slower sens than that because smaller flicks and tracking are more important to me.

It gets complicated. What FOV changes were you thinking of? Keep in mind the FOV setting in QC has a different meaning to the FOV setting in QL. For instance, 110 in QL is the same as 125 in QC.

16:9 fov 103 in OW - whats equal to QC?

I think OW and QC have the same FOV so you would enter 103 (which is equal to 87 in QL). Looks like the lowest available right now is 110 in QC.

I don't think QC should allow changing mouse sensitivity or FOV because this gives an unfair advantage to people who have the skill and knowledge to do so and are willing to spend time customizing these things, and we don't want people to gain an advantage just because they know how to abuse the available configuration options. Hardcode it to 10cm/360 for everyone.

Yeah, it's all or nothing, right? We shouldn't consider the consequences of each setting individually. Using this logic, I see no reason why QC should not come with its own scripting language that lets you change any aspect of the game. Anyone not willing to spend the time doing that can just suck it.

Besides, to change sens in a menu, the knowledge required is virtually zero, and the advantage gained is virtually zero. It is the very definition of a preference setting.

No cg_placebo, no game.

Funny how years later people still miss the point completely about zooming. It's not necessarily about if you have the time or knowledge to set up single or dynamic zoom configurations. It's about how the function itself cuts distance, and to go maximum autistic, doesn't even make sense as these weapons do not have scopes. Zooming makes targets larger and claiming it's countered by the targets now moving faster is laughable. If you can't hit a target that's now 100% larger you probably just can't aim. I'm not even going to mention nudging. You zoom nudgers are filthy and the mental gymnastics you perform to defend it are olympic caliber.

how serious is this post?

http://www.esreality.com/post/2466063/should-zoom-be-illegal/

I dont know if u are srs but i think they could make a low tier railgun and an upgraded railgun with zoom.

i mean why not vehicles even, at this point nothing could surprise me.

tl;dr

use a tape measure

Pretty interesting to see how close I got though! :D

I didn't checked the beta forums, but did they (id) said something about adding m_yaw, m_pitch, and cl_mouseaccel cvars in the closed beta phase?

dunno/dunno/yes, soon (i think in 2-3 beta max)

All of them were mentioned in that "ask the devs" thing.

How about things like mouse acceleration and raw mouse input?

Adam Pyle: Mouse acceleration is nearly ready for testing. The current mouse implementation uses DirectInput. Raw was tested early on and found to produce higher latency under the current conditions. However, I'm personally a big fan of raw input and moving forward we hope to reevaluate and provide more options if they provide superior input quality.
Alexander Larionov: Also, we are actively working on other mouse settings, such as m_filter, m_pitch, and m_yaw.

They're all in this build apart from pitch and yaw atm.

Oh fantastic!

Do we know whether they mean the same as in QL?

I would assume so, I think they want to make it as easy as they can for people to convert, and are probably porting the code as close as possible.

Yeah, it makes a lot of sense, and it doesn't get much more intuitive than simply increasing sens by an amount proportional to the raw speed of the mouse.

I've already put my old settings in, but haven't got a game yet. :(

Looking forward to m_pitch too. I like having that a little higher than m_yaw.

what about a fov converter? I have 110 in ql what should i have in qc?

125

Thanks, Its funny cause I was asking in the Quake champions discord too and one guy said 124 an the other 126 :P
I guess ill choose one of them :)

It is technically 124.5870726. :P

I just rounded it up. :D

Now another problem.
I got used with sensitivity about 0.63 in QC. What sens, DPI and in_mouse setting I must use in QL to get the same mouse sens?

(Tried direct conversion in reverse, it gave me 3.15 in QL equivalent to 0.63 in QC but it was not good, too slow, my QL settings was DPI 400 and in_mouse 2, I used reset DPI to 0 and it was too fast, then with DPI 0 and in_mouse 1 I get somehow different results, kind of ok but still dunno if it would be the equivalent to QC or just got some close/middle results)

QL sens should just be your QC sens multiplied by 5, so 3.15.

in_mouse should be 1, since QC uses Direct Input.

DPI isn't a QL setting. It is a mouse setting. It should be whatever you use when playing QC.

If you use m_cpi in QL, it should be equal to your mouse DPI.

Ensure m_yaw and m_pitch are both 0.022.

QC may just be laggier. If that's the case, you can't really simulate it in QL, except maybe by trying m_filter 1, but that's awful. :D

m_filter 1 (vs m_filter 0) is barely perceivable..

It's dependent on your frame rate, so you can try a higher value for m_filter.

All it is gonna do is add lag by filtering the mouse input. I pretty much see it as a legacy setting for dodgy mice.

Yeah true, I guess at 250 fps you aren't going to notice that much of a difference :). I've been using m_filter 1 for years now anyway, more of a placebo than anything else though haha

"DPI isn't a QL setting. It is a mouse setting. It should be whatever you use when playing QC"
I don't know what DPI I use when I play QC (I'd do the standard 360 degree mouse rotation measure but unfortunately QC won't let me do anything till servers are up).

My m_cpi in QL is 0.

m_yaw and pitch in QL are good (0.022)

(owning a wireless Logitech mouse m/n m-r0021 (M325?)) with windows sensitivity right in the middle, enhanced pointer precision OFF, windows 8.1 x64, no additional mouse drivers installed)

Yeah, I don't see any reason why your DPI would change from one game to another unless you are deliberately changing it.

m_cpi 0 is fine. You can use the 3.15 sens in QL with it.

It may never feel exactly the same, but it should feel about the same.

For players going from QC to QL m_cpi should just be 0 in QL, and QC has no equivalent and it completely changes how /sensitivity works (it becomes a value in 360/cm )

Yeah, I know that. What I wasn't clear about is that if he wanted to use m_cpi, it would be set to his DPI, and then the sensitivity value would have to be recalculated accordingly.

We have later discovered he's not using m_cpi anyway. :D