Best DPI Settings? - Page 3 - Overclock.net - An Overclocking Community

Forum Jump: 

Best DPI Settings?

Reply
 
Thread Tools
post #21 of 48 (permalink) Old 01-24-2012, 03:12 PM
Gone
 
Skylit's Avatar
 
Join Date: Jan 2009
Posts: 8,730
Rep: 541 (Unique: 328)
It's more of a combination of the two in my opinion. If the angles are truly larger as you say, it's still a form of interpolation as you're artificially increasing the true sensitivity, lower or higher. Older input methods as you know were built around 400 CPI, hence why default game sensitivity is around "3-5".

I asked if you had an A9500 mouse since most of them are able to scale down to 90 or at least 200 CPI. An interpolation value of "10" via lowest CPI setting feels very simular to how a cursor gets interpolated on a windows desktop. Now it could be as you say, but whether that's "precise" is another thing.

Skylit is offline  
Sponsored Links
Advertisement
 
post #22 of 48 (permalink) Old 01-24-2012, 03:14 PM
Retired Staff
 
Join Date: Jun 2009
Location: Melbourne, Australia
Posts: 8,183
Rep: 504 (Unique: 355)
highly depends on the game and how the game engine handles mouse acceleration.

<div class="post-sig post-sig-limit shazam usersig-click"><div class="reparse-sig-lineheight"><b>* 4th September 2010 4:35 am [local time] - <a href="http://en.wikipedia.org/wiki/2010_Canterbury_earthquake" target="_blank">Mag 7.1 earthquake</a><br>* 22nd February 2011 12:51 pm - <a href="http://en.wikipedia.org/wiki/2011_Christchurch_earthquake" target="_blank">Mag 6.3 earthquake</a><br>* 13th June 2011 2:20 pm - <a href="http://en.wikipedia.org/wiki/June_2011_Christchurch_earthquake" target="_blank">Mag 6.3 earthquake</a><br><br><img alt="heart.gif" src="/images/smilies/heart.gif">Life goes on! RIP the ones Mother Nature has claimed. <img alt="heart.gif" src="/images/smilies/heart.gif"><br><img alt="post-flame-small.gif" src="http://files.overclock.net/images/smilies/post-flame-small.gif"><a href="https://www.overclock.net/t/1209918/requesting-some-sound-advice-here-read-this-first">Requesting Audio Advice? Read This First!</a> <img alt="post-flame-small.gif" src="http://files.overclock.net/images/smilies/post-flame-small.gif"><br><img alt="post-flame-small.gif" src="http://files.overclock.net/images/smilies/post-flame-small.gif">Got some recommendations for <a href="https://www.overclock.net/t/1014902/ocns-most-recommended-audio-products">OCN's Most Recommended Audio Products</a>? PM me. <img alt="post-flame-small.gif" src="http://files.overclock.net/images/smilies/post-flame-small.gif"></b></div></div>
chinesekiwi is offline  
post #23 of 48 (permalink) Old 01-24-2012, 03:57 PM
Gone
 
Skylit's Avatar
 
Join Date: Jan 2009
Posts: 8,730
Rep: 541 (Unique: 328)
Mouse acceleration is just an extra contributing factor to cursor speed. The degree of accel changes based on current CPI value.

The way CPI is handled depends on a specific game engine and how well the the actual input is constructed. IE. raw input or windows cursor snapping. After that CPI is usually multiplied with the game engines sensitivity setting.

Skylit is offline  
Sponsored Links
Advertisement
 
post #24 of 48 (permalink) Old 01-24-2012, 11:49 PM
New to Overclock.net
 
Glymbol's Avatar
 
Join Date: Jul 2010
Posts: 595
Rep: 41 (Unique: 25)
There are many things to consider. To make it simple I assume we are talking about "3D" game. By "3D" I mean: a game in which mouse movement is responsible for turning the view of the player (games with a crosshair in the middle of the screen wink.gif ).

Another assumptions would be no acceleration and raw input or "good" Windows' settings. By "good" I mean 1:1 CPI to pixel movement ratio.

Now we need to define what is "precision" and "speed". I think the easy way to understand this is:
speed - the distance you have to move your mouse on the mousepad for full turn in game (cm/360° or inches/360°)
precision - the number of possible "aiming points" along the 360° turn (something like Dots Per Inch) - let's ignore Y axis completely

I'll analyze Skylit's example from the first page:
1) sensitivity 1.0 @ 800 CPI
vs
2) sensitivity 2.0 @ 400 CPI

1) and 2) have the same speed because:
m_yaw 0.022 (standard value for Quake/goldsrc/source)
Code:
                  360 * 2.54                 360 * 2.54
1) speed = --------------------------- = ------------------- = 51,95 cm/360°
            m_yaw * sensitivity * CPI     0.022 * 1.0 * 800

Code:
                  360 * 2.54                 360 * 2.54
2) speed = --------------------------- = ------------------- = 51,95 cm/360°
            m_yaw * sensitivity * CPI     0.022 * 2.0 * 400

Precision isn't the same though:
Code:
                        360                 360
1) precision = --------------------- = ------------- = 16363 possible "aimong points"
                m_yaw * sensitivity     0.022 * 1.0
Code:
                        360                 360
2) precision = --------------------- = ------------- = 8181 possible "aimong points"
                m_yaw * sensitivity     0.022 * 2.0

1) is twice as precise as 2) because there are 2x that many possible points to aim in 360°.

Summary:
1) sensitivity 1.0 @ 800 CPI
speed = 51,95 cm/360°
precision = 16363 "ap"

2) sensitivity 2.0 @ 400 CPI
speed = 51,95 cm/360°
precision = 8181 "ap"

Verdict: 800 CPI is more accurate because it gives you two times better precision than 400 CPI.

What? NO WAY!

Is there CPI value in precision calculating formula used? No.

I'll consider another setting:
3) sensitivity 1.0 @ 400 CPI
Code:
                  360 * 2.54                 360 * 2.54
3) speed = --------------------------- = ------------------- = 103 cm/360°
            m_yaw * sensitivity * CPI     0.022 * 1.0 * 400
Code:
                        360                 360
3) precision = --------------------- = ------------- = 16363 possible "aimong points"
                m_yaw * sensitivity     0.022 * 1.0

Yet another summary:
3) sensitivity 1.0 @ 400 CPI
speed = 103 cm/360°
precision = 16363 "ap"

So with 400 CPI it is possible to have the same precision as with 800 CPI. Is CPI relevant here? It isn't, I may use 1 CPI mouse and still have the same precision.

Correct verdict: 800 CPI is faster because it gives you twice as much speed as 400 CPI. Sensitivity 1.0 is more accurate because it gives you two times better precision than sensitivity 2.0.

The game doesn't even know what CPI you are using.

Bottom line is:
more CPI = more speed, if you need more speed then set your CPI higher
lower sensitivity = more precision

There was a lot of assumptions and a few definitions made. If you doesn't agree with them please suggest better ones.

I'm sorry for the length of this post. In combination with my poor English, I'm sure nobody will read it now, so in a few weeks we will have another "best DPI" thread wink.gif .

This post is supposed to be written in English, at least I did my best, to make it as close to English as I could :-)
Glymbol is offline  
post #25 of 48 (permalink) Old 01-25-2012, 12:47 AM
Gone
 
Skylit's Avatar
 
Join Date: Jan 2009
Posts: 8,730
Rep: 541 (Unique: 328)
Quote:
Originally Posted by Glymbol View Post


So with 400 CPI it is possible to have the same precision as with 800 CPI. Is CPI relevant here? It isn't, I may use 1 CPI mouse and still have the same precision.
Correct verdict: 800 CPI is faster because it gives you twice as much speed as 400 CPI. Sensitivity 1.0 is more accurate because it gives you two times better precision than sensitivity 2.0.
The game doesn't even know what CPI you are using

Correct. My example wasn't the greatest, but it's more or less the same conclusion in the end.

"CPI/DPI" allow more speed while keeping the "precision" of a non interpolated value of "1".(quake engines). Basically what also happens in a desktop environment, yes? smile.gif

Quote:
Bottom line is:
more CPI = more speed, if you need more speed then set your CPI higher
lower sensitivity = more precision

Yes, yes. I think I got a little confused with how you worded that tongue.gif




Skylit is offline  
post #26 of 48 (permalink) Old 01-25-2012, 01:10 AM
New to Overclock.net
 
DeMS's Avatar
 
Join Date: Dec 2011
Posts: 621
Rep: 66 (Unique: 46)
I still have a question in that kind of matter, which is related but more on the tech/practical side when configuring your sensitivity in-game :

Do values different than sensitivity 1 mean you're potentially discarding info coming from the mouse input by the means of in-engine rounding?
So, is there difference in rounding when it comes to having a decimal part on the value of your sensitivity?

For example:
Code:
0.022 * 1.0 = 0.022 Nothing to round here
0.029 * 1.7125 = 0.049|6625 Does this part get clipped?

Asking this since I was playing on a "weird multiplier" that gave more decimals than it should on those operations :
Code:
0.022 * 1.55      = 0.034|1

And it felt very slightly inconsistent, specially on very fast swipes (up to 3m/s), since then that value should get multiplied by the inputted CPI from the mouse, so it can lead to a large error if rounded.

Another question would be if on quake/src engines values below 1 should be treated different or as "discarding counts", or if the same rounding behavior is present, only more prominent since there is going to be potentially more decimals.
Code:
For example:
0.022 * 0.35 = 0.007|7
360/0.007|7 = 46753           "possible aiming points"
Or, if we make the rounding by truncation (discarding values) :
360/0.007 = 51428        "possible aiming points"

So if this was true (allowing all the suppositions about the rounding to stay true), lower sensitivity would be better in all cases according to the engine interpretation we're making, so it would make sense to put our mouse at the highest CPI possible and get our in-game sensitivity as low as possible.

However, we don't know what the rounding scheme is, so chances are it would be not as precise because of rounding and discarding counts.

I mean, ultimately the game engine takes the counts that the mouse has sent and transforms them in the likes of
Code:
Y_axis_CPI_input * m_pitch * sensitivity + (enable_accel * (accel parameters)) = Y axis position increment
X_axis_CPI_input * m_yaw * sensitivity + (enable_accel * (accel parameters)) = X axis position increment

A - Let's take X axis for example, and a default 400CPI mouse giving all the CPI in one count :
Code:
400 * 0.022 * 0.35 = 3.08 "counts" in X plane.
(Here we depend on how that's translated on-screen, it could be degrees or it could be another way of "counting" movement).

B - Same but with a 1600CPI mouse :
Code:
1600 * 0.022 * 0.35 = 12.32 "counts" in X plane.

C - Let's take an integer for sensitivity value and 1600CPI :
Code:
1600 * 0.022 * 1 = 35.2 "counts" in X plane.

D - Let's take an integer for sensitivity value, but now with a different m_yaw, still on 1600CPI :
Code:
1600 * 0.01 * 1 = 16 "counts" in X plane.

E - Let's try to match the number of "counts" we had on B but without any chance of rounding and using m_yaw only :
Code:
1600 * 0.0075 * 1 = 12 "counts" in X plane.

So, from a point of view of taking the most advantage of your mouse CPI, would it make more sense to put sensitivity at 1 and then modify only m_pitch/m_yaw on q3/src based games so counts don't get either discarded or rounded up in the final calculation?

In conclusion, and as the "mother" question :
Starting at sensitivity 1 and lower, should we pick very carefully our m_pitch/m_yaw so it comes as integers once multiplied by the CPI of the mouse?

The chance of getting integers is greater the higher the CPI, so upping the CPI might make sense then?

PS : I hope I made sense here ;x
All the mistakes on that posts and misconceptions are mine and entirely mine, if you copy my mistakes I'll send you the FBI to be shut down inmediately rolleyes.gif

EDIT : Yes, I accept a "it could be a placebo effect" aswell, but I rather go into numbers.
DeMS is offline  
post #27 of 48 (permalink) Old 01-25-2012, 04:36 AM
New to Overclock.net
 
Join Date: Apr 2011
Location: Germany
Posts: 1,647
Rep: 122 (Unique: 91)
What is still miss is here, is the practical point of view.
Code:
                        360                 360
1) precision = --------------------- = ------------- = 16363 possible "aiming points"
                m_yaw * sensitivity     0.022 * 1.0
Code:
                        360                 360
2) precision = --------------------- = ------------- = 8181 possible "aiming points"
                m_yaw * sensitivity     0.022 * 2.0

Let's assume you need only 6000 "aiming points" for pixelperfect aiming at your screen resolution, how does it let you aim more precise having it set to 16363 "ap" instead of 8181 "ap"?

thuNDa is offline  
post #28 of 48 (permalink) Old 01-25-2012, 06:46 AM
New to Overclock.net
 
Glymbol's Avatar
 
Join Date: Jul 2010
Posts: 595
Rep: 41 (Unique: 25)
@ DeMS
I understand what you mean. To clarify:
m_yaw * sensitivity = angle of rotation in degrees (°)

From what I know the maximum precision in Quake/goldsrc/source is 65536 (2^16). So the minimum possible angle is 360 / 65536 = 0.0054931640625° (notice 4 * 0.0054931640625 ~ 0.022). I don't know how many decimal places are there, remember that computer works on binary numbers so rounding is different. I guess the worst scenario is rounding half of this value (0.005493 / 2 = 0,002747°) but you should ask someone educated in computer science. I'm pretty sure sensitivity 1.0 wouldn't cause additional errors. Either way it's probably the last thing you should worry about wink.gif .

@ thuNDa
Some time ago I tried setting 640x480 res, sensitivity 1.0 and turning by 1 count to see if it's even visible. It's funny but it actually is visible smile.gif . You are right, from practical point of view any sensitivity below let's say ~4 will be good enough. It's the reason why very high CPI isn't really needed for FPS games. Precision gain from sensitivity 2.0 to 1.0 is something like mythical difference between 500 and 1000Hz polling rate. Both sensitivity 2.0 and polling rate 500Hz are enough for everyone.

This are sensitivity values calculated from angle represented by "the middle" (the largest), "the average" and "the edge" (the smallest) pixels for different settings:
Code:
h_res   m_yaw   FOV     max_px  av_px   min_px
[px]    [°]     [°]     sens    sens    sens

640     0.022   90      8.139   6.392   4.076
800     0.022   90      6.511   5.114   3.260
1024    0.022   90      5.087   3.995   2.546
1280    0.022   90      4.069   3.196   2.036
1366    0.022   90      3.813   2.995   1.908
1400    0.022   90      3.721   2.922   1.862
1440    0.022   90      3.617   2.841   1.810
1600    0.022   90      3.255   2.557   1.629
1680    0.022   90      3.100   2.435   1.551
1920    0.022   90      2.713   2.131   1.357
2048    0.022   90      2.543   1.998   1.272
2560    0.022   90      2.035   1.598   1.018

"The middle" pixel means pixel next to the crosshair, calculated using method from here: http://www.funender.com/quake/mouse/index.html.
"The average" pixel is calculated using method from here: http://www.esreality.com/?a=longpost&id=1265679&page=2.
"The smallest" pixel is at the edge of the screen.

As you can see even for ultra high screen resolutions sensitivity 1.0 is enough. There will be no "pixel skipping" even for "the smallest" pixel.

This post is supposed to be written in English, at least I did my best, to make it as close to English as I could :-)
Glymbol is offline  
post #29 of 48 (permalink) Old 01-25-2012, 09:25 AM
New to Overclock.net
 
fasti's Avatar
 
Join Date: Mar 2011
Posts: 222
Rep: 15 (Unique: 8)
I just use 400-450 for everything, so that I get used to it in any situation. Hard smooth mousepad makes it easy to move mouse around and light mouse is very easy to lift when needed.

Takes ~23cm to go from accross the desktop (6/11 1920x1080+1680x1050). And using ~15cm/360 in fps, I have small arm so this might be ~25 for normal people.

Also this means you will move your arm around and leaving the most accurate stuff to your wrist, instead of using wrist for all. Maybe it will be good for your hand/arm/wrist durability, atleast some people have cured their wrist problems by using low sensitivity.


Dpi vs sensitivity, some mices come with drivers that allow seperate sensitivity controls outside of windows settings, some doesn't. With razer you can use what ever dpi and still tweak the sensitivity to to very low for "2D" usage. Tweaking windows sensitivity out of 6/11 fails badly for accuracy.

.
fasti is offline  
post #30 of 48 (permalink) Old 01-25-2012, 09:49 AM
Gone
 
Skylit's Avatar
 
Join Date: Jan 2009
Posts: 8,730
Rep: 541 (Unique: 328)
Quote:
Originally Posted by Glymbol View Post

@ DeMS
I understand what you mean. To clarify:
m_yaw * sensitivity = angle of rotation in degrees (°)
From what I know the maximum precision in Quake/goldsrc/source is 65536 (2^16). So the minimum possible angle is 360 / 65536 = 0.0054931640625° (notice 4 * 0.0054931640625 ~ 0.022). I don't know how many decimal places are there, remember that computer works on binary numbers so rounding is different. I guess the worst scenario is rounding half of this value (0.005493 / 2 = 0,002747°) but you should ask someone educated in computer science. I'm pretty sure sensitivity 1.0 wouldn't cause additional errors. Either way it's probably the last thing you should worry about wink.gif .
@ thuNDa
Some time ago I tried setting 640x480 res, sensitivity 1.0 and turning by 1 count to see if it's even visible. It's funny but it actually is visible smile.gif . You are right, from practical point of view any sensitivity below let's say ~4 will be good enough. It's the reason why very high CPI isn't really needed for FPS games. Precision gain from sensitivity 2.0 to 1.0 is something like mythical difference between 500 and 1000Hz polling rate. Both sensitivity 2.0 and polling rate 500Hz are enough for everyone.
This are sensitivity values calculated from angle represented by "the middle" (the largest), "the average" and "the edge" (the smallest) pixels for different settings:
Code:
h_res   m_yaw   FOV     max_px  av_px   min_px
[px]    [°]     [°]     sens    sens    sens
640     0.022   90      8.139   6.392   4.076
800     0.022   90      6.511   5.114   3.260
1024    0.022   90      5.087   3.995   2.546
1280    0.022   90      4.069   3.196   2.036
1366    0.022   90      3.813   2.995   1.908
1400    0.022   90      3.721   2.922   1.862
1440    0.022   90      3.617   2.841   1.810
1600    0.022   90      3.255   2.557   1.629
1680    0.022   90      3.100   2.435   1.551
1920    0.022   90      2.713   2.131   1.357
2048    0.022   90      2.543   1.998   1.272
2560    0.022   90      2.035   1.598   1.018
"The middle" pixel means pixel next to crosshair, calculated using method from here: http://www.funender.com/quake/mouse/index.html.
"The average" pixel is calculated using method from here: http://www.esreality.com/?a=longpost&id=1265679&page=2.
"The smallest" pixel is at the edge of the screen.
As you can see even for ultra high screen resolutions sensitivity 1.0 is enough. There will be no "pixel skipping" even for "the smallest" one.

You should really make a thread explaining CPI for the "next time" biggrin.gif

Skylit is offline  
Reply

Quick Reply
Message:
Options

Register Now

In order to be able to post messages on the Overclock.net - An Overclocking Community forums, you must first register.
Please enter your desired user name, your email address and other required details in the form below.
User Name:
If you do not want to register, fill this field only and the name will be used as user name for your post.
Password
Please enter a password for your user account. Note that passwords are case-sensitive.
Password:
Confirm Password:
Email Address
Please enter a valid email address for yourself.
Email Address:

Log-in



Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may post new threads
You may post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off