Page 20 of 44
Re: flood's input lag measurements
Posted: 02 Mar 2015, 05:01
by flood
well i think that the main difficulty is that to theoretically model some things, you'd need to have a good understanding of what's going on at a pretty low level (like way lower than anandtech's article). i think that for this, with a good understanding and a good model, you can predict the impact on input lag without monte carlo simulations or stuff. but it definitely can be useful to get a feel for what to expect and what to interpret from input lag measurements
and the things we're all missing are the psychological aspects of this. e.g.
the effect of input lag, stutter, whatever on one's performance at aiming, tracking, whatever
how anecdotal claims (valid or not) propagate and affect one's mindset when using a mouse
Re: flood's input lag measurements
Posted: 02 Mar 2015, 07:12
by Sparky
If you want an anecdote, I was capping framerate long before I understood how it impacted input lag, it just looked/felt better. Back then I thought the qualitative improvment was just caused by more consistent frame intervals.
Re: flood's input lag measurements
Posted: 09 Mar 2015, 02:34
by flood
alright i'm back
was browsing ocn today and saw this post
http://www.overclock.net/t/1531877/fina ... t_23624579
Glad you are enjoying the replacement Max.
On a different note, i would like to once again inform the community of something our team has found. (this actually isnt in regards to the FinalMouse)
We have reason to believe that CS:GO raw input is currently bugged. We are not sure if it is a result of a patch or not at the moment. We are still heavily investigating the issue and we will have more details soon once we can test further.
In the meantime we recommend to all mouse owners to keep raw input in CS:Go OFF.
Kind Regards,
FinalMouse Jude
it looks like they've found something disturbing but are not sure of the reasons yet... and as a company they don't want to risk hurting their credibility by reporting something they're not yet sure of
i'm gonna see if i can find anything tonight...
Re: flood's input lag measurements
Posted: 09 Mar 2015, 03:56
by spacediver
interesting!
Re: flood's input lag measurements
Posted: 09 Mar 2015, 04:37
by flood
i don't yet have anything to say concerning input lag but i can guarantee you that m_rawinput 0 drops movement samples. happens at 1000hz and 500hz
video coming soon
k:
https://www.youtube.com/watch?v=hwVjDNmBVos
Re: flood's input lag measurements
Posted: 09 Mar 2015, 17:34
by spacediver
nice tests. Curious about what this potential bug is, and whether it's drastic enough to warrant dealing with the dropped samples you've shown.
Re: flood's input lag measurements
Posted: 09 Mar 2015, 18:42
by lexlazootin
flood, couldn't you prove/disprove his claim by drawing a square with your software like you do in that video and too check if the mouse pointer lands on the same points it started?
Re: flood's input lag measurements
Posted: 09 Mar 2015, 23:22
by flood
whose claim? finalmouse hasn't actually claimed anything yet..
drawing a square like that is not really different from bouncing back and forth between too points
Re: flood's input lag measurements
Posted: 10 Mar 2015, 01:19
by lexlazootin
flood wrote:whose claim? finalmouse hasn't actually claimed anything yet..
drawing a square like that is not really different from bouncing back and forth between too points
Wouldn't bouncing back and forth not show acceleration because they would land on the same points over and over regardless?
Re: flood's input lag measurements
Posted: 10 Mar 2015, 05:47
by flood
same for a square... i dont quite understand what you're thinking
if there is any dropped sample, either pattern will show it. unless it's two consecutive dropped samples, but that's really rare