The 1 second periodicity was only an example. You could trigger it every 10 seconds. What matters is whether the game responds to the 1ms wide pulse whenever it is issued. If it doesn't then the game simply isn't sampling at a rate that guarantees a sample is read within a 1ms window - ie it isn't sampling at 1kHz. By gradually increasing your pulse width to the point where you get a consistent response (eg 9 in 10 pulses trigger the action) then you know you are in the right approximate resolution of the application's sample rate.
...
I do have some source code for games that just poll the joystick without waiting for VBI. In the case of River-raid, it does not let you fire again until the missile hits its target or is off the screen.
>As for the rest, they could but that still does not demonstrate that any particular game title samples this quickly. You need to actually test with real applications that were written, not software you write purely to demonstrate that it is possible.
They are both useful. See if they exist in existing applications and to show that it's more accurate to sample at higher rates.
>PS, see my other crazy idea to allow 1kHz sampling an analogue joystick. In case you can't find it, a quick recap:
>Use the X/Y potentiometers to adjust the left/right volume of a simple hardware oscillator running at several kHz that is sampled by the soundcard at 44.1 kHz. Calculate the RMS power for frames of 441 samples (one frame for left and one frame for right) and look up the RMS value in a suitable calibration table to determine X and Y position.
Computing an on-going RMS may slow things down though. How about, just looking for a max/min value every millisecond or so and using up 4 channels to get a digital joystick out of it.