FPS like reaction speed test

download (366kB) Version 2006/10/29

Version 2006/10/29:
- made crosshair smaller
- if it finds image files 'crosshair', 'target', 'wall1', 'ceil', 'floor' either as .jpg or .bmp in the reaction.exe directory it will load and use them. These images have to have 2^n pixel size, for instance 256x256. Black is interpreted as transparent.

Version 2005/03:
- more accurate timing
- no dependency on the 'wait for VSynch' anymore. I have taken care to compare your reaction with what is actually visible on the screen at any time (except delays of the monitor).

This is a toy program to test your reaction speed or, more precicely, your eye-to-hand delay time under 'realistic' conditions. You could call this delay time your 'personal ping' from eye to hand as it is also expressed in milliseconds (ms). The program is written in Delphi and uses OpenGl. Todays graphics cards should have no problem with rendering that few polygons with full refresh rate. You are free to enable 'wait for vsynch' in the graphic cards properties.
For a physicist like me the project is interesting because the program can determine you personal amplitude and phase response.

While working on this, I wondered why I got results differing by ~20ms when running the program on my notebook and my full grown PC. The essence is, my large TFT screen adds another delay time to the graphics output! It seems to store at least one full frame before displaying it! For a pro gamer this effect should make a huge impact and ought to be considered by selecting a monitor and should be covered in tests and hardware reviews! For assessing this I implemented a function to the program that can measure the intrinsic delay of the whole loop: drawn graphics - display on screen - optical mouse - mouse driver and windows message system. More about experimenting with the screen-mouse loop-back.

You must try to follow the unpredictably moving target analogous to the way you must aim on a wildly jumping opponent in a first person shooter game. I wrote this program because I was interested in how much faster a skilled player is than I am, the untrained once-in-a-while player. (As long as I spend my spare time coding OpenGL I will not get any better.) I admit to achieve at best 200ms of delay time. Most people also achieve values in this region, non-gamers maybe 50ms longer and pro-gamers up to 30ms shorter. To get a clearer picture of the span of reaction times please mail your result to the email address below!
The path that the target follows is a random walk. While you try to catch the target, the actual position of your crosshair is logged and compared afterwards with the path of the target.

The easiest way to start the test is to simply press the 'quick start>>!' button. The program will switch to fullscreen mode and then it gives you 3 seconds to prepare for the chase. Then the target begins its dance. You just try to follow the target and stay as close as possible to the center. You don't have to shoot at it, its a pacifistic program! The random walk takes about 16s. If you want to use the program in windowed mode press and hold right mouse button to look around.

After the chase the program switches back to windowed mode and calculates the delay between the 'excitation signal' and your response. This is done by shifting excitation and response to each other in time and calculating the mean (RMS) distance to the target. The curve of all that RMS-distances against the applied time shift can be seen in the expanded window and has a minimum where the searched for time lag is. You can see more of the data extraction when clicking on 'more info'. The value in the second line shows your average (again RMS) distance to the center of the target. For comparison: the diameter of the whole target is 12°.

Technically the whole process is called a network analysis. A system (you) is fed with a distinct excitation signal and its response is recorded. The result could be the amplitude and phase response over the tested frequency range. (This will be included sometime.)
In this case the excitation signal is a random walk, a kind of noise, because it behaves very similar to an unpredictable opponent in a FPS game. A random walk has a 1/f frequency characteristic, that means that low frequencies have higher amplitudes than high frequencies. This random walk is symmetric, after half of the time it goes the same way back. This is not necessary for the current least square calculation but is favorable for a cross correlation approach. (not used at the time) Because supposedly noone can follow a random walk with frequency components much higher than 5Hz, I cut off all frequencies above a configurable frequency, at default 5Hz. The movement of the target becomes nicely smooth by this.
Another possible and not yet fully implemented approach would be the calculation of the cross correlation between both signals. Other interesting informations could be extracted then too, like phase and amplitude response and the frequency dependance of the time lag.
Mind the small moving dots in the lower left graph when you move the mouse cursor over the x/y-time trace (upper left). With the checkbox below you can choose between an authentic replay of your moves and an animation with your lag compensated.

The settings for resolution, colordepth and display frequency will normally need no change or are self explanatory. Also the renderer settings are there more for completeness.
You can shift 'mouse sensitivity' to the left if you prefer more physical work with your mouse.
The checkbox 'restrict to horizontal movement' does exactly that if you like that touch of realism.
Some people prefer an inverted control for the vertical look, thats what the other checkbox is for. The editbox 'exc. freq. lowpass' accepts values between 2 and 20Hz. The lower the value the smoother the motion of the target. The motion contains less high frequency components. But towards 2Hz the motion becomes more predictable and the resulting reaction time bcomes shorter.
Up to now the prog does not save the configuration data so you have to make the selections after every start again.

Just out of couriosity I integrated an aimbot, an automatical aiming system. The aimbot only 'sees' where the target was in the last displayed image and trys to follow the target with the same controls you have. It has no unfair advantage - besides sheer thinking speed. The PID parameters of its regulation loop determine how fast it reacts - between 'dead horse' and supernatural. Aimbot parameters are best set in windowed mode. Don't cheat yourself! :-)

keys:
f: toggle fullscreen/windowed
esc: return to windowed mode
a: aimbot on/off
space: start chase

mouse: aim, use RMB in windowed mode

Send your results and comments to:

Please excuse if it takes a few days to answer the mail.

The program is no visual gem, is not finished and most probably contains bugs!

Hall of Fame

Here I compiled some results people published in usenet or sent to me by email.

name/nick range
ms average
ms average distance to target
degrees

Adam Balogh - 80 3.7

med1xza - 89 1.9

Alexander G.
sonyfreak - 154 4.8

Paul Brocklehurst 156 156 4.1
Benjamin Stanka
age 30 163 163 4.5

bryan keleman
Team1hp_jetset 165 165 3.8

Sami "some" Jokela
age 24 165 - 170 167 -

Matvey "TBAPb" Smolovich
age 21 165 - 175 170 3.5

Nicholas Borelli 162 - 180 170 4.0

Nikk Lovekin
Kinematix age 17 167 - 170 170 4.5

Apox77 169 - 191 170 4.5

Torben Maurer
miez - 170 4.9

Jean Bibeau
Wrebb 172 172 3.8

John "F474L" Burrell 172 - 185 175 4.8

Federico Nose 177 177 -

William "R34c710N" Register 174 - 185 180 4.4

Tanter
Ralf Richter 179 - 188 182 5.0

Kevin Lin 180 180 3.9

Nathan Moye 186 186 4.3

Pjotr K.
Presley - 195 4.3

Peter Hill 194 - 209 200 4.4

Greason Maddox - 200 4.5

myself
EMwave in Steam 195 - 210 205 4.8

Terrance Schultz 207 207 4.0

matt hydes 211 211 4.6

These results were gained with a previous version of the program, where all times came out up to 20ms longer. You should test yourself again with the new version of the program, sorry.

nick range average

fungus 190 190

-=[SFS]=-[Zaknafein] 197 197

Allan Bruce 200-210 205

FaMiNe 202, 226, 218, 197 211

Cookie McCrumble 218, 218, 218 218

Poison64 230 230

Lief 235 235

myself
EMwave in Steam 220..245 235

Andrew Lovern 260 260

Jethro 270 270

Cannon Fodder (67 years old) 285, 255, 273 271

Jordi Xucla 278 278

2014/05/05

download (366kB) Version 2006/10/29


Version 2006/10/29: - made crosshair smaller - if it finds image files 'crosshair', 'target', 'wall1', 'ceil', 'floor' either as .jpg or .bmp in the reaction.exe directory it will load and use them. These images have to have 2^n pixel size, for instance 256x256. Black is interpreted as transparent. Version 2005/03: - more accurate timing - no dependency on the 'wait for VSynch' anymore. I have taken care to compare your reaction with what is actually visible on the screen at any time (except delays of the monitor). This is a toy program to test your reaction speed or, more precicely, your eye-to-hand delay time under 'realistic' conditions. You could call this delay time your 'personal ping' from eye to hand as it is also expressed in milliseconds (ms). The program is written in Delphi and uses OpenGl. Todays graphics cards should have no problem with rendering that few polygons with full refresh rate. You are free to enable 'wait for vsynch' in the graphic cards properties. For a physicist like me the project is interesting because the program can determine you personal amplitude and phase response. While working on this, I wondered why I got results differing by ~20ms when running the program on my notebook and my full grown PC. The essence is, my large TFT screen adds another delay time to the graphics output! It seems to store at least one full frame before displaying it! For a pro gamer this effect should make a huge impact and ought to be considered by selecting a monitor and should be covered in tests and hardware reviews! For assessing this I implemented a function to the program that can measure the intrinsic delay of the whole loop: drawn graphics - display on screen - optical mouse - mouse driver and windows message system. More about experimenting with the screen-mouse loop-back.
	You must try to follow the unpredictably moving target analogous to the way you must aim on a wildly jumping opponent in a first person shooter game. I wrote this program because I was interested in how much faster a skilled player is than I am, the untrained once-in-a-while player. (As long as I spend my spare time coding OpenGL I will not get any better.) I admit to achieve at best 200ms of delay time. Most people also achieve values in this region, non-gamers maybe 50ms longer and pro-gamers up to 30ms shorter. To get a clearer picture of the span of reaction times please mail your result to the email address below! The path that the target follows is a random walk. While you try to catch the target, the actual position of your crosshair is logged and compared afterwards with the path of the target.
	The easiest way to start the test is to simply press the 'quick start>>!' button. The program will switch to fullscreen mode and then it gives you 3 seconds to prepare for the chase. Then the target begins its dance. You just try to follow the target and stay as close as possible to the center. You don't have to shoot at it, its a pacifistic program! The random walk takes about 16s. If you want to use the program in windowed mode press and hold right mouse button to look around.
	After the chase the program switches back to windowed mode and calculates the delay between the 'excitation signal' and your response. This is done by shifting excitation and response to each other in time and calculating the mean (RMS) distance to the target. The curve of all that RMS-distances against the applied time shift can be seen in the expanded window and has a minimum where the searched for time lag is. You can see more of the data extraction when clicking on 'more info'. The value in the second line shows your average (again RMS) distance to the center of the target. For comparison: the diameter of the whole target is 12°.
	Technically the whole process is called a network analysis. A system (you) is fed with a distinct excitation signal and its response is recorded. The result could be the amplitude and phase response over the tested frequency range. (This will be included sometime.) In this case the excitation signal is a random walk, a kind of noise, because it behaves very similar to an unpredictable opponent in a FPS game. A random walk has a 1/f frequency characteristic, that means that low frequencies have higher amplitudes than high frequencies. This random walk is symmetric, after half of the time it goes the same way back. This is not necessary for the current least square calculation but is favorable for a cross correlation approach. (not used at the time) Because supposedly noone can follow a random walk with frequency components much higher than 5Hz, I cut off all frequencies above a configurable frequency, at default 5Hz. The movement of the target becomes nicely smooth by this. Another possible and not yet fully implemented approach would be the calculation of the cross correlation between both signals. Other interesting informations could be extracted then too, like phase and amplitude response and the frequency dependance of the time lag. Mind the small moving dots in the lower left graph when you move the mouse cursor over the x/y-time trace (upper left). With the checkbox below you can choose between an authentic replay of your moves and an animation with your lag compensated.
	The settings for resolution, colordepth and display frequency will normally need no change or are self explanatory. Also the renderer settings are there more for completeness. You can shift 'mouse sensitivity' to the left if you prefer more physical work with your mouse. The checkbox 'restrict to horizontal movement' does exactly that if you like that touch of realism. Some people prefer an inverted control for the vertical look, thats what the other checkbox is for. The editbox 'exc. freq. lowpass' accepts values between 2 and 20Hz. The lower the value the smoother the motion of the target. The motion contains less high frequency components. But towards 2Hz the motion becomes more predictable and the resulting reaction time bcomes shorter. Up to now the prog does not save the configuration data so you have to make the selections after every start again.
Just out of couriosity I integrated an aimbot, an automatical aiming system. The aimbot only 'sees' where the target was in the last displayed image and trys to follow the target with the same controls you have. It has no unfair advantage - besides sheer thinking speed. The PID parameters of its regulation loop determine how fast it reacts - between 'dead horse' and supernatural. Aimbot parameters are best set in windowed mode. Don't cheat yourself! :-)

name/nick	range ms	average ms	average distance to target degrees
Adam Balogh	-	80	3.7
med1xza	-	89	1.9
Alexander G. sonyfreak	-	154	4.8
Paul Brocklehurst	156	156	4.1
Benjamin Stanka age 30	163	163	4.5
bryan keleman Team1hp_jetset	165	165	3.8
Sami "some" Jokela age 24	165 - 170	167	-
Matvey "TBAPb" Smolovich age 21	165 - 175	170	3.5
Nicholas Borelli	162 - 180	170	4.0
Nikk Lovekin Kinematix age 17	167 - 170	170	4.5
Apox77	169 - 191	170	4.5
Torben Maurer miez	-	170	4.9
Jean Bibeau Wrebb	172	172	3.8
John "F474L" Burrell	172 - 185	175	4.8
Federico Nose	177	177	-
William "R34c710N" Register	174 - 185	180	4.4
Tanter Ralf Richter	179 - 188	182	5.0
Kevin Lin	180	180	3.9
Nathan Moye	186	186	4.3
Pjotr K. Presley	-	195	4.3
Peter Hill	194 - 209	200	4.4
Greason Maddox	-	200	4.5
myself EMwave in Steam	195 - 210	205	4.8
Terrance Schultz	207	207	4.0
matt hydes	211	211	4.6

nick	range	average
fungus	190	190
-=[SFS]=-[Zaknafein]	197	197
Allan Bruce	200-210	205
FaMiNe	202, 226, 218, 197	211
Cookie McCrumble	218, 218, 218	218
Poison64	230	230
Lief	235	235
myself EMwave in Steam	220..245	235
Andrew Lovern	260	260
Jethro	270	270
Cannon Fodder (67 years old)	285, 255, 273	271
Jordi Xucla	278	278