![]() ![]() 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. It scales down your sensitivity and turning becomes harder while aiming feels approximately right. You will see this exact effect when you use zoom in QL. 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. If you want to scale your sensitivity due to a FOV change, you are faced with a dilemma. The sensitivity is purely concerned with the degrees of rotation for given mouse movement. "Is there a formula taking FOV and aiming into account somehow?" 180 will make you look behind you 360 back where you were originally looking, etc. The number of degrees is how far you have rotated around that axis. When you use the mouse to look left or right, you're rotating around an axis. 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.Ī degree here is one degree of rotation in the game. 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. Yep, so you pretty much answered your own question. "yaw*windows_scale*sensitivity together should produce value of type degrees per "dot"." In this case, the size of the unit that sensitivity is measured in is DPI dependent. The usual meaning of sensitivity in QL is what you get when m_cpi is 0. 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. Somehow, I expected you to know this, so you may even be trolling me at this point. 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".Įither way, my view angle will change at the same rate.Ĭonstant * sensitivity * 1000 degrees per second.Ģ * constant * sensitivity * 500 degrees per second. 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". It does not change your sensitivity at all. So whatever the interval is, your game will update the correct amount. It will give you a measurement of the distance it moved since the last poll. It doesn't matter how often you poll the mouse. They might be able to control it with something like in_mouse, or not. That's just another layer for the user to worry about. It doesn't affect how the game calculates this shit using the data provided. 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. "suddenly the sensitivity works diffrently on two diffrent games" Why not make the formula:ĬPU speed * disk size * screen width / number of files on the hard drive? I showed you the actual DEFINITION of linear sensitivity. You pulled some random formula out of your ass that has nothing to do with the way angles are calculated in any game. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |