DPI Wizard

The beta is added! View full update

I'm still working an update of the calculator code, hopefully it will be done by next week. I will continue to add games then

It must be canceled through Paypal (cancel recurring payment). Unfortunately there's no way of doing it through this site for now. Is this the user you signed up with? Or do you have another one with subscription?

It means that if you want to aim at something 5 cm away from your crosshair, that will be the same as moving 5 cm in osu (talking about physical monitor distance here). It's the same as the desktop calculator does today. BTW, I'm changing direction a little bit, I'm building everything into one calculator. All the current three (convert, distance, desktop), and the three for osu. It will be a lot more streamlined to have one instead of six, but it requires quite a lot of change to the code (which in the end will also be more streamlined and easier to maintain )

Just got the beta key!

I'm signed up for the beta now, will add it if possible when I get access! I'm currently revamping the calculator to support 2D platforms like osu! and Windows desktop, so it can be integrated in one layout instead of several. This means I won't be adding many games in the coming weeks, but I'll try to squeeze in new stuff like this game

I'm waiting for my Teensy, so I will do some re-testing when I get it. I've done a few tests similar to my original ones here on Battlefield 4, and the loss seems to be significantly lower. So the Source engine probably plays a big part indeed.

Very cool, thanks! BTW, did you do this with vsync on or off? Just one little note, and I don't know if this will make any difference. But you should try to do the test sending 100k packets in one go, with sensitivity 0.0163636364, and see how many counts you are off turning 360 degrees. I got very varying results doing only 1000 packets, but the average might be around the same.

I'm done with most formulas and integration into the existing layout and code, but I need some input from you guys if you have any. So far I've made four modes (screenshots of the progress so far): Calculation of distance to move the mouse to cross the entire screen, and convert this to new settings Ratio between mouse and on-screen movement, and convert this to new setting Convert from Osu! to a game Convert from a game to Osu! I don't play much Osu, so I appreciate any feedback regarding what's useful information and what's not Maybe another mode that keeps the distance to cross active play area constant, rather than the distance for the entire screen? Only useful if you change aspect ratio, but still.

It's actually a bug I need to fix in my code for it to work, which only affects UT4 for some reason. I will dig into it soon!

I will also make a converter from osu to any game supported, which will work kinda like the desktop calculator. I'm coding it all now, and will maybe have a "beta" out in a few days or a week!

Unreal Tournament 4 is already added, unless there's a new version out

That's exactly what I'm doing, making one mode for mouse to monitor ratio, and one for distance to move the cursor across the screen

I'm working on this right now, and will add it as a whole new calculator, because it really doesn't fit the current layout. The desktop calculator doesn't really work for osu since it uses FOV to calculate total 360 distance, which is irrelevant for osu.

Not related to the input lag, but I think I'll perform this analysis on one or two more games that use different engines and supports both raw and Windows inputs. I have a couple of games in mind that have shown to be extremely precise when I analyzed their sensitivity. Should be interesting to see how the results compare.

BTW, one annoying limitation of the Logitech script, is that it takes 0.5 ms for the script to actually send the packet. So when telling the script to sleep for 1 ms, the total execution is in reality 1.5 ms before it cycles through, making it closer to 666 Hz, not 1000 Hz. So me stating that it is 1000 Hz is not precise, but showing how the timing affects the accuracy was the main point. So I hope the Teensy can emulate real 1000 Hz!

It's just a little time-consuming, not at all impossible. It's all about priorities, but I've finished most other tasks ahead of it now

I'm planning to get one too, many cool things that can be done with it

Interesting, looking forward to see what you find out. I will do some real-life tests now, to see if I'm able to replicate my results. By physically moving the mouse I introduce a lot of uncontrollable variables though, but I'l give it a shot.

I actually started doing the analysis for 125 Hz as well, but it would have taken me over 6 hours to do What little I tested indicates that it's pretty close to 250 Hz though.

I welcome everyone to try for themselves This is the script, it will be assigned to key G1 while M1 is active (make sure you un-bind any keys/macros bound to this key): if (event == "G_PRESSED" and arg == 1) and GetMKeyState() == 1 then for i = 0, 999 do MoveMouseRelative(10,0) Sleep(1) end end Set the sensitivity in-game to 1.63636364, and executing the script should spin you around exactly 360 degrees. FOV needs to be set to the default 90. Note that with only 1000 packets you will get varying results.

Fixed now, was linking the wrong post!

The results are in! Made a new topic for this, check it out here: Counter-Strike: Global Offensive - m_rawinput vs rinput

What input method provides the best sensitivity in CS:GO between raw mouse input on or off, or the rinput program? Find out here! Rinput is a 3rd party program that injects into the game to remove mouse acceleration. Test system CPU: Intel Core i7-3770K Memory: 16 GB GPU: Geforce GTX Titan | Driver: 355.82 OS: Windows 10 Professional x64 Game: Counter Strike: Global Offensive (Steam version), Exe version 1.34.9.9 (csgo) Map: Dust II Test method This test is done by analyzing the amount of packets lost or gained between the mouse driver and the game, using Logitech's scripting capabilities in their Gaming Software. Each test is performed by sending 100k packets to the game. Packet discrepancy is not the same as acceleration. Discrepancies are whole reports sent from the mouse that does not make it to the game (or in some rare cases gets doubled), while acceleration is reports received by the game, but where movement is added or subtracted to the packet. What's not tested Since this analysis is done directly from the mouse driver, it does not account for anything that happens between the sensor in the mouse and the mouse driver, such as USB latency and sensor inaccuracy. CS: GO's built in raw mouse input supposedly suffers from buffering tied to the FPS, but I have not tested this, nor experienced it. Other sources indicate it might be a matter of 1-2 ms lag, which is insignificant compared to the findings here. The tests are also done offline, so most variables caused by online play are removed. If anything, these results represent a best-case scenario. Testing procedure At first I was set on doing a test where 1000 packets were sent to the game, then counting the discrepancy. The results turned out to vary a lot, so I needed to increase the sample size. I did a lot of testing with 10k packets, doing each test 10 times. The results were a lot more consistent, but very time-consuming. So I tested with 100k packets one time for each test, and compared the results to the average of the 10k packets tests. As they were pretty much identical, I used this method for the final analysis. Test layout There are four input methods tested here: m_rawinput 1 - CS: GO's built-in raw mouse input capability m_rawinput 0 - By turning off raw mouse input, the game gets the mouse data from Windows rather than directly from the mouse driver rinput.exe 1.2 - This program injects itself between the mouse driver and the game, and this is the non-sequential version rinput.exe 1.31 - This is the sequential version of rinput Each input method is tested with packet sizes of 1, 10 and 100. The packet size determines how many counts the game should move the cursor/cross hair in one instance. In addition, each of these combinations are tested with 1, 2 and 4 ms delay, equaling polling rates of 1000 Hz, 500 Hz and 250 Hz. And lastly, all these test were done both with and without vertical sync (vsync). All vsync tests were done with triple buffered vsync @ 120 Hz, but I've tests different refresh rates, and 60, 120 or 144 Hz does not make much of a difference. Results These graphs show the average discrepancy for each polling rate. The numbers are averaged from the 1, 10 and 100 packet size tests. The raw data is shown under the graphs. As these are averages, the reality is that you might experience anything from close to no packet loss, to over twice the average. For methods other than "m_rawinput 1" there is a lot of random fluctuation. Vsync OFF: Vsync ON: Video This video visualizes the discrepancy: Conclusion "m_rawinput 1" provides by far the most accurate and consistent interpretation of the signals from the mouse driver. All tests point to the fact that this feature does exactly what it is supposed to do; get the raw mouse data without anything interfering in between. "m_rawinput 0" is better than rinput.exe in all tests, sometimes rinput.exe has triple the loss of "m_rawinput 0". Rinput 1.2 seems to yield a slightly better result than 1.31, especially at 1000 Hz. Vsync has a huge impact on everything except "m_rawinput 1". It's important to note that 1% loss does not necessarily mean that you move 1% shorter. When you play, the packets sent from you mouse will vary greatly in size, ranging from 1 to over 1000 depending on your settings. If you lose a 1 count packet, it won't make much of a difference, but if you lose a 1000 count packet, it will make a huge impact on how far you move. If you want accuracy, there is no doubt; use "m_rawinput 1". Around 1-2 percent packet loss is quite significant, especially since the actual loss fluctuates, and the movement will be inconsistent. If you want some other tests done, please let me know! View full update