Overclock.net › Forums › Components › Mice › csgo m_rawinput 0 drops samples
New Posts  All Forums:Forum Nav:

csgo m_rawinput 0 drops samples - Page 25

post #241 of 285
Thread Starter 
https://github.com/VolsandJezuz/Rinput-Library
Quote:
Compiled with Visual Studio 2008, though you may be able to get it to work with other versions or compilers (Visual C++ 2008 Express Edition is available for free @ https://go.microsoft.com/?linkid=7729279);
main
(15 items)
 
old
(14 items)
 
 
CPUMotherboardGraphicsRAM
4770k maximus vii impact nvidia gtx 970 crucial ballistix tactical 16gb 
Hard DriveCoolingOSMonitor
crucial mx100 noctua nh-c14 windows 7 ultimate sony cpd-g520 
KeyboardPowerCaseMouse
kbp v80 matias quiet silverstone sx500-lg ncase m1 v3 logitech g100s with mcu replaced by teensy2.0 
Mouse PadAudioAudio
allsop raindrop xl chord mojo hifiman re-600 
CPUMotherboardGraphicsRAM
i7 920 evga x58 sli le galaxy gtx 460 crucial something 3x1gb 
Hard DriveCoolingOSMonitor
intel 330 180gb scythe kotetsu windows 8.1 pro sony cpd-g520 
KeyboardPowerCaseMouse
logitech k120 silverstone st75f-gs nxzt h440 evga torq x5 
Mouse PadAudio
allsop raindrop mobo 
  hide details  
Reply
main
(15 items)
 
old
(14 items)
 
 
CPUMotherboardGraphicsRAM
4770k maximus vii impact nvidia gtx 970 crucial ballistix tactical 16gb 
Hard DriveCoolingOSMonitor
crucial mx100 noctua nh-c14 windows 7 ultimate sony cpd-g520 
KeyboardPowerCaseMouse
kbp v80 matias quiet silverstone sx500-lg ncase m1 v3 logitech g100s with mcu replaced by teensy2.0 
Mouse PadAudioAudio
allsop raindrop xl chord mojo hifiman re-600 
CPUMotherboardGraphicsRAM
i7 920 evga x58 sli le galaxy gtx 460 crucial something 3x1gb 
Hard DriveCoolingOSMonitor
intel 330 180gb scythe kotetsu windows 8.1 pro sony cpd-g520 
KeyboardPowerCaseMouse
logitech k120 silverstone st75f-gs nxzt h440 evga torq x5 
Mouse PadAudio
allsop raindrop mobo 
  hide details  
Reply
post #242 of 285
Thread Starter 
here's a faq.
(6) explains how the new rinput fixes things

1. what's the difference between m_rawinput 0 and 1? Warning: Spoiler! (Click to show)
m_rawinput 0 uses the GetCursorPos and https://msdn.microsoft.com/en-us/library/windows/desktop/ms648394(v=vs.85).aspx]SetCursorPos functions.

every frame, the game gets the position of the windows cursor with a call to GetCursorPos, and then calls SetCursorPos to reset the cursor to the center of the screen. the total amount of mouse movement since the previous frame is equal to the difference between the coordinates of the windows cursor and the coordinates of the center of the screen.

m_rawinput 1 uses the Raw Input API, which allows the game to directly access the motion data the mouse sends without messing around with the cursor's coordinates.
2. what's wrong with m_rawinput 1? Warning: Spoiler! (Click to show)
for a long time there have been some people who claim that m_rawinput 0 feels more "raw" or that m_rawinput 1 feels "delayed" or something. and others who feel no difference and often claim that those who do feel a difference are experiencing something akin to placebo.

the first empirical evidence of any difference between m_rawinput 0 and 1 are in post 70 and 74 from this thread, where i found using my photodiode-input-lag-measuring-rig that for my computer, at my normal settings m_rawinput 0 is faster by roughly 100us and at maximally underclocked settings, m_rawinput 0 is faster by 1.5ms. while these differences are below what's perceptible, there remains the possibility that on another computer, or in a busier server (e.g. deathmatch), that the differences increase to a perceptible level.

the next piece of evidence is from some (admittedly very poorly controlled) abx testing using
http://www.overclock.net/t/1559213/csgo-m-rawinput-0-1-abx-test/0_100
where some people passed the test fairly convincingly.

and then we have wareya's testing but apparently he couldn't reproduce the difference on another computer.

given all of this, i think it's reasonable to say that
-there is a difference in response between m_rawinput 0 and m_rawinput 1
-the difference depends significantly on one's particular hardware and configuration (vague statement but whatever)
-in some cases the difference is perceptible

personally i believe that for most people's setups, the difference is not significant and not perceptible... but who knows.
3. so is m_rawinput 1 "smoothed"? or "buffered"? Warning: Spoiler! (Click to show)
with either m_rawinput 1 or m_rawinput 0, there is no smoothing or filtering in the sense that if the mouse sends a single packet saying it moved 100 counts to the right, the game will not move 50 counts in one frame and 50 counts in another. there is no averaging of the motion data from the mouse. proof: see video in OP where i set a teensy to move the cursor to the right by 10 counts, then left by 10 counts, etc... if there is any averaging, the frames wouldn't bounce perfectly between exactly two angles. some frames would have the crosshair in between, but clearly this doesn't happen.

http://www.overclock.net/t/1405271/regarding-mouse-optimization/0_100#post_20298262
Quote:
Controversy over added input latency or smoothing effect reported by users: Raw input regardless of game engine will almost always buffer polled rate faster than that of the average frame rate you pull in game. There may be an “unconnected” feeling for many users as movement is no longer based on in-game fps.

The only time where this is not the case is if you happen to use a lower polled mouse rate and render in-game frames at or above your buffered setting.
this makes no sense to me as far as how it could affect response. with m_rawinput 0, the "buffer" is the position of the windows cursor itself.
http://www.overclock.net/t/1529341/the-first-real-test-for-measuring-input-lag/0_100#post_23257215
in either case, you're simply adding up numbers. it doesn't matter whether the windows os adds up the numbers to shift the cursor position or whether the game adds up the numbers from raw input events.

the source of the difference between m_rawinput 1 and m_rawinput 0 has to be with timing of when the data are available. but at the moment it is unclear whether this is due to the source engine or due to windows.
4. k so what's wrong with m_rawinput 0? Warning: Spoiler! (Click to show)
first note that since m_rawinput 0 uses cursor information, it is affected by your windows mouse settings. generally this isn't an issue since most people use 6/11 with epp off anyway

the first issue with m_rawinput 0 is cursor clipping. when you try to move the mouse past the side of the screen, the mouse is still reporting motion but the cursor doesn't move further since windows clips the position of the cursor to within the screen. since the game resets the cursor to the screen center every frame, usually this isn't an issue. but if the framerate is low enough that during a frame's period, the cursor reaches the edge of the screen, the game is then unaware of motion past this and so the crosshair doesn't travel as far as it should.

not everyone is affected by this. the minimum speed you must move your mouse for this to occur is = framerate * 0.5*(screen resolution's width in pixels) / (dpi) * (0.0254 meters/1 inch). for instance, i play on 800x600 with a dpi of 1000 and a framerate of ~300, so the minimum speed my mouse needs to move in order to run into cursor clipping issues with m_rawinput 0 is 3.048 meters/second. but since my g100s already malfunctions at ~2.7m/s and in-game, i rarely ever swipe faster than 2m/s, i don't have to worry about cursor clipping if i use m_rawinput 0.

the second issue is more subtle and is the thing shown in the OP of this thread and here. basically, a small, but detectable, amount of motion data is ignored by the game when using m_rawinput 0. the reason for this is that if the cursor is moved right after GetCursorPos gets the cursor location, but before SetCursorPos resets the cursor to screen center, the motion in this brief interval is lost. for instance, if the interval is 10us, and the cursor moves every millisecond (as is the case with 1000hz mice), on average, 1% of motion would lie in the interval and be lost. I'm not exactly sure why DPI Wizard found higher loss at 250hz than at 500hz though.
5. and what's RInput? Warning: Spoiler! (Click to show)
afaik RInput was originally intended to address the cursor clipping issue. it accomplishes this by overwriting (probably wrong word to use here) GetCursorPos and SetCursorPos with its own functions that returns/resets the accumulator variables that store motion data gathered from Raw Input events. these accumulators are not clipped by the screen coordinates so no clipping occurs. additionally, since the Raw Input API is used, the windows mouse settings don't affect in-game response so you don't have to worry about accidentally enabling pointer precision or whatever.

the second issue of packet loss/drops is still present when using the original RInput versions. in DPI Wizard's testing, there is even more packet loss with RInput than without.
6. how does the new RInput fix packet loss? Warning: Spoiler! (Click to show)
the original idea was to reset the accumulators in RInput whenever GetCursorPos is called, so that there is no interval where motion data could get lost.

this has 2 issues:
-2d interfaces which call GetCursorPos but without calling SetCursorpos for resetting the cursor won't work, since the accumulators are reset every time GetCursorPos is called, so the cursor would remain stuck near the screen center. afaik csgo doesn't have any 2d interfaces that use GetCursorPos, but other games might.
-for whatever weird reason, csgo calls GetCursorPos an additional time every second, but the data from this additional call isn't used to move the crosshair or anything. if GetCursorPos simply resets the accumulators whenever it is called, this extra call would cause whatever data in the interval between the last normal call to GetCursorPos and the extra call to get lost. indeed, what Vols found in testing was an inverse dependence between the amount of packet loss and the framerate, since with lower framerate, the average length of that interval increases.

the solution which addresses both of these issues is to use a separate accumulator. when SetCursorPos is called, these new accumulators are reset. when GetCursorPos is called, the data from the original accumulators is added to the new accumulators, the original accumulators are reset, and GetCursorPos returns the data in the new accumulators. the Raw Input events still only affect the original accumulators, and since SetCursorPos doesn't touch the original accumulators, whatever interval between calls to GetCursorPos and SetCursorPos does not result in dropping Raw Input events. and since getcursorpos doesn't reset the new accumulators, a 2d interface that doesn't call setcursorpos will still work fine.
7. could RInput have the same issues with Raw Input that csgo has? Warning: Spoiler! (Click to show)
maybe. i don't think there's been much said about this, as most assume that it's only the source engine's implementation of raw input that is imperfect. one day i'll find out.

Edited by qsxcv - 10/18/15 at 4:07pm
main
(15 items)
 
old
(14 items)
 
 
CPUMotherboardGraphicsRAM
4770k maximus vii impact nvidia gtx 970 crucial ballistix tactical 16gb 
Hard DriveCoolingOSMonitor
crucial mx100 noctua nh-c14 windows 7 ultimate sony cpd-g520 
KeyboardPowerCaseMouse
kbp v80 matias quiet silverstone sx500-lg ncase m1 v3 logitech g100s with mcu replaced by teensy2.0 
Mouse PadAudioAudio
allsop raindrop xl chord mojo hifiman re-600 
CPUMotherboardGraphicsRAM
i7 920 evga x58 sli le galaxy gtx 460 crucial something 3x1gb 
Hard DriveCoolingOSMonitor
intel 330 180gb scythe kotetsu windows 8.1 pro sony cpd-g520 
KeyboardPowerCaseMouse
logitech k120 silverstone st75f-gs nxzt h440 evga torq x5 
Mouse PadAudio
allsop raindrop mobo 
  hide details  
Reply
main
(15 items)
 
old
(14 items)
 
 
CPUMotherboardGraphicsRAM
4770k maximus vii impact nvidia gtx 970 crucial ballistix tactical 16gb 
Hard DriveCoolingOSMonitor
crucial mx100 noctua nh-c14 windows 7 ultimate sony cpd-g520 
KeyboardPowerCaseMouse
kbp v80 matias quiet silverstone sx500-lg ncase m1 v3 logitech g100s with mcu replaced by teensy2.0 
Mouse PadAudioAudio
allsop raindrop xl chord mojo hifiman re-600 
CPUMotherboardGraphicsRAM
i7 920 evga x58 sli le galaxy gtx 460 crucial something 3x1gb 
Hard DriveCoolingOSMonitor
intel 330 180gb scythe kotetsu windows 8.1 pro sony cpd-g520 
KeyboardPowerCaseMouse
logitech k120 silverstone st75f-gs nxzt h440 evga torq x5 
Mouse PadAudio
allsop raindrop mobo 
  hide details  
Reply
post #243 of 285
Digging the dedication. Did you already confirm that the new method fixes loss? With the dll injection, can you say anything about the input read/apply timings? I assume since the engine thinks it's using standard input it will read and apply using the cursor-based timings? That's the one thing I can see RInput being better at than m_rawinput.
post #244 of 285
Thread Starter 
not sure if i understand you, but i don't think the engine is aware of the timing of input events at all... it just uses the latest data it can get
main
(15 items)
 
old
(14 items)
 
 
CPUMotherboardGraphicsRAM
4770k maximus vii impact nvidia gtx 970 crucial ballistix tactical 16gb 
Hard DriveCoolingOSMonitor
crucial mx100 noctua nh-c14 windows 7 ultimate sony cpd-g520 
KeyboardPowerCaseMouse
kbp v80 matias quiet silverstone sx500-lg ncase m1 v3 logitech g100s with mcu replaced by teensy2.0 
Mouse PadAudioAudio
allsop raindrop xl chord mojo hifiman re-600 
CPUMotherboardGraphicsRAM
i7 920 evga x58 sli le galaxy gtx 460 crucial something 3x1gb 
Hard DriveCoolingOSMonitor
intel 330 180gb scythe kotetsu windows 8.1 pro sony cpd-g520 
KeyboardPowerCaseMouse
logitech k120 silverstone st75f-gs nxzt h440 evga torq x5 
Mouse PadAudio
allsop raindrop mobo 
  hide details  
Reply
main
(15 items)
 
old
(14 items)
 
 
CPUMotherboardGraphicsRAM
4770k maximus vii impact nvidia gtx 970 crucial ballistix tactical 16gb 
Hard DriveCoolingOSMonitor
crucial mx100 noctua nh-c14 windows 7 ultimate sony cpd-g520 
KeyboardPowerCaseMouse
kbp v80 matias quiet silverstone sx500-lg ncase m1 v3 logitech g100s with mcu replaced by teensy2.0 
Mouse PadAudioAudio
allsop raindrop xl chord mojo hifiman re-600 
CPUMotherboardGraphicsRAM
i7 920 evga x58 sli le galaxy gtx 460 crucial something 3x1gb 
Hard DriveCoolingOSMonitor
intel 330 180gb scythe kotetsu windows 8.1 pro sony cpd-g520 
KeyboardPowerCaseMouse
logitech k120 silverstone st75f-gs nxzt h440 evga torq x5 
Mouse PadAudio
allsop raindrop mobo 
  hide details  
Reply
post #245 of 285
I mean, at some point in the simulation step the input data has to be collected and then at some other point the view angle has to be set according to that for the frame render. Ideally they happen at the same time and at the latest point possible, which I guess with standard input they do. But for m_rawinput there could be a disconnect there somehow.
post #246 of 285
Input is dispatched to the server on a thread in modern source engine so that is impossible.
post #247 of 285
I mean client-side rendering.
post #248 of 285
Yes, that's part of how input prediction works, but it's actually slightly worse for hitreg because of the threaded input updates wink.gif
post #249 of 285
Thread Starter 
Quote:
Originally Posted by HAGGARD View Post

Did you already confirm that the new method fixes loss?
yea i tried 10000 motion events. none were dropped. repeated 10 times and it was perfect.
Quote:
Originally Posted by HAGGARD View Post

I mean, at some point in the simulation step the input data has to be collected and then at some other point the view angle has to be set according to that for the frame render. Ideally they happen at the same time and at the latest point possible, which I guess with standard input they do. But for m_rawinput there could be a disconnect there somehow.
i see; yea for this rinput should be identical to the standard m_rawinput 0
main
(15 items)
 
old
(14 items)
 
 
CPUMotherboardGraphicsRAM
4770k maximus vii impact nvidia gtx 970 crucial ballistix tactical 16gb 
Hard DriveCoolingOSMonitor
crucial mx100 noctua nh-c14 windows 7 ultimate sony cpd-g520 
KeyboardPowerCaseMouse
kbp v80 matias quiet silverstone sx500-lg ncase m1 v3 logitech g100s with mcu replaced by teensy2.0 
Mouse PadAudioAudio
allsop raindrop xl chord mojo hifiman re-600 
CPUMotherboardGraphicsRAM
i7 920 evga x58 sli le galaxy gtx 460 crucial something 3x1gb 
Hard DriveCoolingOSMonitor
intel 330 180gb scythe kotetsu windows 8.1 pro sony cpd-g520 
KeyboardPowerCaseMouse
logitech k120 silverstone st75f-gs nxzt h440 evga torq x5 
Mouse PadAudio
allsop raindrop mobo 
  hide details  
Reply
main
(15 items)
 
old
(14 items)
 
 
CPUMotherboardGraphicsRAM
4770k maximus vii impact nvidia gtx 970 crucial ballistix tactical 16gb 
Hard DriveCoolingOSMonitor
crucial mx100 noctua nh-c14 windows 7 ultimate sony cpd-g520 
KeyboardPowerCaseMouse
kbp v80 matias quiet silverstone sx500-lg ncase m1 v3 logitech g100s with mcu replaced by teensy2.0 
Mouse PadAudioAudio
allsop raindrop xl chord mojo hifiman re-600 
CPUMotherboardGraphicsRAM
i7 920 evga x58 sli le galaxy gtx 460 crucial something 3x1gb 
Hard DriveCoolingOSMonitor
intel 330 180gb scythe kotetsu windows 8.1 pro sony cpd-g520 
KeyboardPowerCaseMouse
logitech k120 silverstone st75f-gs nxzt h440 evga torq x5 
Mouse PadAudio
allsop raindrop mobo 
  hide details  
Reply
post #250 of 285
Great work. Will start injecting and play around with it sometime next week when I get to my PC. Is my account safe?
Quote:
Yes, that's part of how input prediction works, but it's actually slightly worse for hitreg because of the threaded input updates wink.gif
Prediction is?
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Mice
Overclock.net › Forums › Components › Mice › csgo m_rawinput 0 drops samples