Vaccaria

You have windowed mode, windowed mode has a resolution, what resolution are you using? What is the monitor size and native resolution? Do you use windowed mode in other games? example:

These are not constants, these values will be different as they use centimeter in the formula. For example, these are the values I got in CoD:MW Jedi's Tick - Horizontal ≈ 107%MDV, 60%MDH; 107*(9/16)=60.1875%MDH Jedi's Tick - Vertical ≈ 68%MDV, 38%MDH; 68*(9/16)=38.25%MDH

What I don't understand is when a person tries to point out in words something that only they are experiencing. I've done some tests of what you pointed out. I got a match. I also know the reasons for the CPI inconsistency on the mouse, i.e. lack of consistency. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ 4.17*100=417 px The cursor started and ended the movement of the active are - That means the math works. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ You want to know how many pixels you can get through at 216 mm. so: 216/25.4=8.50393700787*800=6803.1496063 px - We multiplied the distance by CPI, we got a value, let's understand it as px. Since CPI are counts, they can be tied to anything, in the case of a monitor, they are tied to resolution, i.e. px. >>> 6803.1496063/1920=3.54330708661 - We found how many can fit 1920 px on this area.

Variables: 1) Active Area is the mouse pad - 216x135 mm. 2) Relative Mode is the same DPI, but in a different form - 800 DPI. 3) Screen Resolution - FHD: 1920x1080. 4) Field of view in the game - Overwatch, 103 Hdeg 16:9. 5) Game sensitivity multiplier - Overwatch, 6%. First we need to find out what kind of 800 DPI is in OTD. 1 inch = 2.54 cm = 25.4 mm. 800/25.4=31.496062992125985 X'Y sensitivity in OTD. If we want to have edge-to-edge desktop resolution in the active area, then: (1920/(216/25.4))/25.4=8.8888888888888 X in OTD or (1080/(135/25.4))/25.4=8 Y in OTD. If you don't use a different X'Y DPI, you need to have a single X'Y multiplier in OTD. You can use inches for calculation. The workings of the variables field of view, screen resolution, and sensitivity multiplier in the game, can be seen here. Sensitivity 1: Sensitivity 6% 360° Distance: 28.8636 centimeters Pixel ratio: 0.5278 pixels/count

Yesterday I realized that the lock on X'Y is a coefficient of "1" between distance on 360 under any FOV. When we use the % scaling calculator, this lock always works, so we choose to scale either X or Y. We can currently use tools from the game itself, in the form of unlock the X'Y lock, or third party tools like rawaccel. In rawaccel there is a Y Range, it gives a different feel to changing Y, I have not seen this type of Y change in the game yet. Here we unlock the lock under hipfire, we did scaling, we have changed the Y coefficient, it became higher than "1". This coefficient above "1" will work over a 360 distance for ADS and Scope, even when we choose to scale for ADS, Scope either X or Y. What we need to do is to reduce the coefficient, make it lower than "1". And since the coefficient above "1" is the coefficient that will always be there, if set same scaling method for Hipfire, ADS, Scope, e.g. only X, then like when we lock to X'Y, it is the same, it means that it also keeps the scale as "1" for 360 distance, and this does not give a percentage match on the monitor, because the monitors have aspect ratios, e.g. 16:9. And with that in mind, vertical scaling looks like the best fit for the X'Y lock(Of course, I'm not writing about 0% here, since using a stretched res for any aspect ratio, will give a different sens multiplier for X'Y, 0% takes this into account, by setting the multiplier for Y in rawaccel, we will get a coefficient, it will the same for both the sens multipliers and the 360 distance coefficient between Hipfire, ADS, Scope).

Apparently the person wants to get the Y string for rawaccel in the output for the game, when using split X'Y, since not all games have the ability to change Y. There are two options: 1) Use X'Y Ratio(in the image above, he indicated ) 2) Use Y Range (TheNoobPolice here explained how to do the other option) Only as you said it will only work for Hipfire, for ADS and Scope the vertical multiplier will be different. So 0% of 2D is most effective:) With him there is no reason to do that.

/// 1800 dpi sensitivity "0.568889" zoom_sensitivity_ratio_mouse "1.000000" (Zoomed: AUG, SG 553) zoom_sensitivity_ratio_mouse "1.000000" (Zoomed 1: AWP, SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.000000" (Zoomed 2: SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.000000" (Zoomed 2: AWP) or zoom_sensitivity_ratio_mouse "1.088317" (Zoomed: AUG, SG 553) zoom_sensitivity_ratio_mouse "1.096285" (Zoomed 1: AWP, SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.124343" (Zoomed 2: SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.127085" (Zoomed 2: AWP) /// 1600 dpi sensitivity "0.755628" zoom_sensitivity_ratio_mouse "1.088317" (Zoomed: AUG, SG 553) zoom_sensitivity_ratio_mouse "1.096286" (Zoomed 1: AWP, SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.124343" (Zoomed 2: SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.127085" (Zoomed 2: AWP) /// 1600 dpi sensitivity "0.853333" zoom_sensitivity_ratio_mouse "0.963707" (Zoomed: AUG, SG 553) zoom_sensitivity_ratio_mouse "0.970763" (Zoomed 1: AWP, SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "0.995608" (Zoomed 2: SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "0.998036" (Zoomed 2: AWP) or zoom_sensitivity_ratio_mouse "1.088317" (Zoomed: AUG, SG 553) zoom_sensitivity_ratio_mouse "1.096285" (Zoomed 1: AWP, SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.124343" (Zoomed 2: SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.127085" (Zoomed 2: AWP) /// 1355 dpi sensitivity "0.755628" zoom_sensitivity_ratio_mouse "1.088317" (Zoomed: AUG, SG 553) zoom_sensitivity_ratio_mouse "1.096286" (Zoomed 1: AWP, SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.124343" (Zoomed 2: SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.127085" (Zoomed 2: AWP) /// 1200 dpi sensitivity "0.853333" zoom_sensitivity_ratio_mouse "0.963707" (Zoomed: AUG, SG 553) zoom_sensitivity_ratio_mouse "0.970763" (Zoomed 1: AWP, SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "0.995608" (Zoomed 2: SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "0.998036" (Zoomed 2: AWP) or zoom_sensitivity_ratio_mouse "1.088317" (Zoomed: AUG, SG 553) zoom_sensitivity_ratio_mouse "1.096285" (Zoomed 1: AWP, SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.124343" (Zoomed 2: SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.127085" (Zoomed 2: AWP) /// I have no idea which option is right for you. You can't get rid of the slowness of character movement at 16.9. You can only change Pixel ratio(mp and dpi)(res).

Your settings sens?

Osu vs McOsu and the impact on conversion from Hipfire to ADS, Scope. At the very beginning of the study, I used native osu. McOsu I used as 3D, with a native square osu. Since I used native osu, the area of note appearance has a square. By moving the pointer over the square area each time, I arrived at the method: MDH 60% from Hipfire to ADS, Scope. When I moved to McOsu to test the full screen format instead of the square, I continued to use MDH 60%. I didn't even have any doubt that MDH 60% was the most effective. Not long ago I came across questions, topics, discussions about 100%MDH, and it prompted me to double-check this method, because past experience is past experience, because as soon as you think, there is, found - you start to die. /// When I started running tests with MDH 100%, my confidence was shaken, I immediately realized what was wrong. Square is MDH 60%, but when fullscreen it is MDH 100%. From here we get the following data: 1) Native osu is 0-60%, maybe someone will have 100%, but according to my data 60% is most effective. 2) Fullscreen McOsu is 60-100%, yes, can use 60%, 90%, 98.434389% or any other value to address any shortcomings you may personally have. But for the sake of understanding, let's take 100% as a base. How to make full screen mode: Need 3 commands, I don't know how these values will display on other monitors, my values are as follows: osu_playfield_stretch_x 0.5 osu_playfield_border_bottom_percent 0.112 osu_playfield_border_top_percent 0.112 1) Manually enter one command each time you run McOsu. The key combination to open cmd is "Shift+F1" or 2) Enter these lines in the file "osu.cfg" in the path "*\SteamLibrary\steamapps\common\McOsu\cfg" /// The images show the value of the size of the circles(cs 0). The higher the cs, the more the area is narrowed. This is the mechanics of cs, there is no way around it. Therefore, at the usual values of 4-6 cs, the area will be narrowed. Comparison of area: Native area in osu(cs 0) Fullscreen(cs 0) What does cs 4 look like with fullscreen. Or Here are more fullscreen for specific cs values: cs 2 osu_playfield_stretch_x 0.471 osu_playfield_border_bottom_percent 0.097 osu_playfield_border_top_percent 0.097 cs 4 osu_playfield_stretch_x 0.446 osu_playfield_border_bottom_percent 0.081 osu_playfield_border_top_percent 0.081 cs 5 osu_playfield_stretch_x 0.432 osu_playfield_border_bottom_percent 0.073 osu_playfield_border_top_percent 0.073 cs 6 osu_playfield_stretch_x 0.418 osu_playfield_border_bottom_percent 0.064 osu_playfield_border_top_percent 0.063 I check the values in photoshop to make sure the lines are the same from the edges. /// Well, another confirmation that the same method shows different effectiveness when the environment changes. This means that you should choose methods by studying your own environment of training, playing games or whatever else you do with your PC:) Let's take The Finals game as an example, the calculator shows limit of MDV 100%, i.e. in the game cannot be set higher than this value. The environment limits by imposing restrictions. Playing native osu, you will be changed by the osu environment as there is no way to change the area. /// That's all for now. Tag solution On topic, this is: Click Click together with Click Click other posts additional information

@Aim DASH 1) I don't play games. 2) If talking about OW, I use 103. If talking about WoT, I use 100. WoT was my main game, and OW has a feature set for testing. But I don't play games anymore:) 3) I will explain the impact through numbers in a calculator. If I start explaining about how FoV affects visual response, since the eyes are receptors, I might fail. And that's just the word FoV, but there are objects in the game, the distance of your eyes to the monitor screen, the size of the monitor screen, your ergonomics in your chair, your visual acuity, glasses with or without diopter and etc. etc. etc. First step: FoV affects the 360° Distance for hipfire(different multiplier) and the Pixel ratio: 103: 90: Second step: With different FoV for hipfire(different multiplier) there will be different multiplier values when scaling for ADS, Scope. And this will already affect the shooting. Yes, will adapt to it, there will be no difference for brain. But these methods affect the principle of shooting differently. 103: 90: There is no right or wrong here. You can try all of these, record the results, analyze the results and decide which FoV is the most effective for you. Another condition is that not all games have a high FoV, not all games can change FoV. So you don't need to fixate on specific values. I'm going to take it out of context a little bit and steal the words: /// If there are any more questions, ask. ///

You are right. The new version really has all the features I need. But where I live, banks are disconnected from SWIFT. So I can't pay directly. Since I tried it and collected data that I tried to analyze afterwards, I understand what you wrote about. That's awesome. Data input has become very consecutive. Something like this was consistent with angle-snapping "6", but the quality is much different. Also with angle-snapping I felt the square on the monitor, which was able to show effectiveness in osu, only in osu(2D)... In 3D the square helped with stability, it helped with input consistency, but that's something I was able to notice right away as the process of comparing between A and B was underway. But when I compared Anisotropy and Angle-snapping, all my reasoning about why I feel that consistency (crosshair stability) at certain angles immediately became clear in the form of math. Thank you @TheNoobPolice

There was another function that came to my attention. "Angle snapping" Considering what I encountered and came to rotate the sensor, angle snapping gives a noticeable result in 3D along with sensor rotation. If remove the sensor rotation to 0(I have that, as 0 gives me a strong bias relative to -5), the value in angle snapping goes up. This means that the efficiency goes down. Hence. First of all, need to determine the sensor rotation angle (ex. 5, 0, -5, etc., etc.), and after all the long tests, should move to the angle snapping. By doing this, the value of the angle binding will be less, which will increase the efficiency. This may not be useful to some people, but for me, it's a useful feature. It can also be useful in 1-2-3 degrees, i.e. small values, as a kind of helper. I'm using 20k dpi, I need 508 dpi. That's why the "Sensitivity multiplier" is like this. Raw Accel - settings.json. 3D, vertical multiplier for OW "Sensitivity multiplier": 0.0254, "Y/X sensitivity ratio (vertical sens multiplier)": 1.42486085343, "L/R sensitivity ratio (left sens multiplier)": 1.0, "U/D sensitivity ratio (up sens multiplier)": 1.0, "Degrees of rotation": -5.0, "Degrees of angle snapping": 6.0, (search process) "Input Speed Cap": 0.0 2D, non 3D games "Sensitivity multiplier": 0.0254, "Y/X sensitivity ratio (vertical sens multiplier)": 1.0, "L/R sensitivity ratio (left sens multiplier)": 1.0, "U/D sensitivity ratio (up sens multiplier)": 1.0, "Degrees of rotation": -5.0, "Degrees of angle snapping": 6.0, (search process) "Input Speed Cap": 0.0 I have the sensor turned to -5, which is pretty significant. When I increase Y, it also gives less stability, but when I add an angle snapping - I'm getting stability. end

Have you tried the experiment on linux? For example, in the latest versions of Mint there is an option to disable mouse acceleration in the settings, when I started using Mint there was no such option. Need to define the scope of your search rather than immediately burying yourself in the depths of windows. As one example, I remember Logitech had a lag issue on wireless devices with close proximity to a wifi device, but this problem was not with Razer. The problem itself, the person solved by replacing the mouse, but was initially trying to dig deeper. Any suggestion can be discussed and a solution can be reached. The USB itself contains a lot of things. It is a physical port (mom, dad) which is soldered to tracks in the layers of the motherboard, these tracks go to the chipset, the chipset itself is blah blah, etc. Which means if dig deep, need to know what to look for. The data you provided can be interpreted as another type of information, the first type is what we capture with our eyes, the cursor is drifting. You were able to learn from the machine how it reads the signal. But there are many more variables in the depths, and only a limited number of people can know them. I don't know. I can suggest an idea, test it in Linux.

I got the data after comparing two Y: "1" and "custom". With a multiplier of "custom" the vertical and diagonal tracking distance is more "comfortable" for the forearm and fingers. With a multiplier of "1" the "comfort" distance is shortened, so the forearm is more active in moving and taking the load, and the fingers are used in less area. The more vertical and diagonal distance required, the better the performance of the "custom" multiplier will be. At multiplier "1" the movement becomes 1:1, thus vertical and diagonal tracking becomes more labor intensive, but there is stability in the form of "flick" movement on short vertical, diagonal area, long horizontal movements at sharp angles. When the multiplier is "custom" with "flick" movement on a larger vertical, diagonal area, long horizontal movements at less acute angles. In other words. The image depicts figures, dimensions are a convention and should be interprised as for clarity. Y - custom Y 1 - lock X & Y Yellow rectangle - area of forearm. Green square - area of fingers. With multiplier "1" on one green square the fingers show more stable flick, forearm the same. At two squares the forearm is connected, fingers work only at one square. The forearm performs a more stable flick with a long movement and a sharp angle. With the "custom" multiplier on two green squares the fingers show a more stable flick than with one square, but that doesn't mean that the difference can reach several times. It is there, it can be felt when moving, that's what I recorded. There are difficulties when trying to make a long forearm movement with an acute angle, but these difficulties are not present if you make a more diagonal movement, i.e. with a less acute angle. 3D to Osu With a multiplier of "1" when playing osu, the forearm is used more than the fingers. With a multiplier of "custom" when playing osu, the fingers are used more than the forearm. That is, with different multipliers, the forearm and fingers are used to different degrees relative to each other. If at "1" in 3D we are more active with the forearm, then in Osu will be transferred to the forearm (going the distance). And vice versa in "custom". From here it follows that some games that use more horizontal aiming can form the habit of aiming in this way and no other way, if a person wants to try to use "custom Y", his habit will make itself known. In OW you can aim diagonally and maintain that style. But in Valorant you can't anymore. And that's where "recoil" comes in, so recoil is distance measured. Which means that if I use my fingers for vertical movement, I'm more comfortable controlling most of the recoil with my fingers, and only after I engage my forearm(shoulder). To use "1" or "custom" is a compromise with yourself, i.e. your habits. But to know your habits, you have to try and only then compare: the old experience and the new experience. p.s. Because I tested rotating the sensor, I was able to gather even more data on how I hold and move the mouse. I was able to come up with a more efficient grip. I compared two mice, my last mouse and my current mouse. The shape and grip give differences in sensor rotation, but on my two mice sensor rotation is necessary, on both with sign "-". On the Razer Viper between 2 and 4, this is an approximate range, because by warming up it is possible to reduce the value, if you take an unstretched arm, the value is closer to 4. Also tested the rotation "0" with multipliers Y: "1" and "custom". When rotating the sensor, the performance of "custom" increased dramatically. I have some reasoning as to why mine is the way it is, but I'm not ready to share yet, i.e. the reasoning is not ready. I use 200% MDH(X) and 200% MDV(Y) at FHD/650dpi.

Since I was doing a lot of testing, in my dream I came up with the idea to reduce the DPI to the minimum value, i.e. Viper V2 = 100. It is possible to reduce via the RawAccel multiplier. I decided through DPI. After that I started testing movements through different shapes(symbols etc). After getting the results, I compared them. With different mouse shape, with different palm shape(i.e. all properties are included, ex. size.) Rotating the sensor allows to correct the discrepancy between X and Y. If at "0" there is a perfect vertical line, then at X it can be curved (and the opposite effect), so need to determine the degree of importance of the horizon or vertical line for yourself (what you do, etc.). In my case, turning the sensor to -4 turned both: X'Y and there was no choice between X and Y. I once learned that ergonomic mice physically rotate the sensor relative to the body. And if we take into account how unpopular in discussions "sensor rotation" is, we can assume that people change(create) the mouse shape for mass hand, but do not take into account the location of the sensor in mass hands. We have cyber sports for FPS games, if my hands don't fit a mouse by all properties, but another person's do, then I am at a limited development potential. I was able to come up with the sensor rotation, but here we have LAN tournaments banning any outside software, that means I've reached the limitation again. This is my observation about the competition between people in FPS games. This is just one of many. Here's another one. Adjusting sensitivity in game, I want to control the multiplier under each FOV, but the game has a formula and it scales. So I'm limited again. Games don't separate the multiplier into X and Y, so again I'm limited. Funny observations on how we put our own sticks in our own wheels.