LOL I used to own a computer game center and had two dedicated T1's bonded and traffic managed. The CS players would complain if the ping time spiked from 20ms to 25ms to a server and would say it was causing them to miss shots. I reviewed the connections for jitter and all sorts of things and they would never believe that the 5ms didn't make the difference.
To prove the point I downloaded a simple javascript stoplight app that would measure reaction time and told them if anyone could beat my times I'd give them an all day pass. And it never happened.. not even once.. and the times were lucky to be in the 210+ms range. 5ms wasn't causing them to miss the shot..
If CS was a game where the players would just pop up out of nowhere (and then stay static) that would be somewhat comparable but when you aim at player you take lots of things in consideration, and most importantly - aiming and hitting a player has very little to do with reaction times. To hit a player that walks into your crosshair can probably be done with few ms of precision, that's because we extrapolate the movements and we subconsciously even takes things like input lag into consideration.
Not saying that those 5 ms are important, if anything constant 25 ms is better than 20 ms with +5 ms spikes, but reaction times have very little to do with actually hitting the other player. But when you have server side hit detection the lag is really important.
>Not saying that those 5 ms are important, if anything constant 25 ms is better than 20 ms with +5 ms spikes, but reaction times have very little to do with actually hitting the other player. But when you have server side hit detection the lag is really important.
Lag correction is key here.
Competitive CS is at a very high framerate(often around 120Hz). So at a 20ms ping, the client is around 2.4 frames behind the server. At 25ms, it's almost exactly 3 frames behind. That means that, on average, the client is going to be rendering 20% less lag corrected frames with the lower ping, which is a pretty huge amount for player movement.
That test is very cool. A better test may be to count down from 10 lights changing and try to click exactly and time when the last one changes. Under perfect timing (no variation between each light lit) I would think the average person could get the last light much better than the 250ms I am getting on the rttest01 test.
Now, to expand this scenario, add random delay between each light. first 10ms, 15ms, 50ms, etc. Then see how well a person can click when that last light lights up. This could be a better test for measuring 'Human Response Time vs Jitter Delay' or what ever the appropriate term is that we inherently use subconsciously in FPS games.
I can easily tell the difference between 40ms and 80ms playing CS. but I doubt my reaction time is that low (not to mention the time until my finger clicks).
It's absolutely terrible in rhythm games like RockBand when video and input have a delta, and even worse when you add audio desync into the mix. Fortunately you have a few knobs in the game options.
That's different--quakeworld did client side prediction so your local side was updating with no lag (ie, move the mouse and your view would rotate with very very little lag, just like you were playing a local fps). The positions of players was lagged because their canonical positions were controlled by the server, but that manifests itself totally different than display lag.
I am not sure if you are trolling or remembering through rose glasses. you CAN play qw with such a ping but you would not stand a chance against anyone with a ping of 30. projectiles and players jitter all around the place.
This is a very skewed test I think. While your result and intuition are likely to be true, the test does not prove it. The streetlights test measures the response to a sudden change with no previous indication. While playing an FPS, you get multiple sources of information which converge before a specific event.
To be more precise, you know what to expect and when - even without counting exact seconds, if you see someone running, then disappear behind something - you know when to expect him to enter your view again. Then you've got sound which additionally helps you in orientation. Then you've got the time it takes between you spotting something and getting the correct aim, while you see the target moving - you're aligning your aim with the moving object and deciding when they meet, rather than just measuring a response to an impulse.
Small bug report: If I click start over, then use space as my key, it records the time, then starts over.
You should return false from your event handler to prevent that (but only do that during an actual test, not all the time). Or remove the focus from the start over button.
Oddly I was faster if I concentrated on the vanishing red light (210-220 ms) instead on concentrating the lightening of the green light (240-260 ms).
I also tried out not focus (aren't the rod cells on the edge of your vision faster in detecting movement than the cone cells in the center?), but it didn't amount to much.
Since your account is only 84 days old, maybe you're not aware that jokes are generally frowned upon and will usually get you down voted. Live and learn :)
To prove the point I downloaded a simple javascript stoplight app that would measure reaction time and told them if anyone could beat my times I'd give them an all day pass. And it never happened.. not even once.. and the times were lucky to be in the 210+ms range. 5ms wasn't causing them to miss the shot..
For those who are interested:
http://getyourwebsitehere.com/jswb/rttest01.html