Seattle, WA
Quoted from benheck:Two things could cause this:
1) Linux lag. An OS checks I/O when it feels like it - you don't have control over this. They use the Beagle Bone Black for these, which is an ARM SoC with (2) built-in 32 bit microcontrollers I'd assume they use for low-level control, but there still might be I/O polling delays.
2) Locked emulator frequency. What if they said "it runs the emulator at 200FPS and that's faster than anybody needs!" And certainly, like if it were a NES or Atari emulator you'd say "I don't need 200FPS it only ran at 60 originally!"
And yeah it sounds super fast but it would mean an entire "game logic loop" is 5ms, which is a very long time at a hardware level. Consider this psuedo-code, with each action taking 1 ms:
ms0: Do stuff
ms1: Check flipper buttons
ms2: Energize coils if button pressed.
ms3: Do other things
ms4: Do other stuff
OK now your human input is completely random, it could happen anywhere during this cycle. So if you pressed the button around ms0 or ms1, you'd get a very fast response. But if you "just miss" the window and press it on ms2-4, you'd have to wait the entire loop for it to come back 'round again and read your input. This could be the cause for the range of response times.
I was thinking about the cause as I read thru this and came to conclusion #2 as well although Ben beat me by 15 minutes posting it much more eloquently 
That def. explains the randomness of the delay. Although I don't know jack about Linux so maybe the issue is two-fold.. but if it's problem #2 than one would think the clock could be adjusted, although that might mean some rewriting/editing if code was hard coded in in relation to the clock?
Kudos to OP for scoping this - very interesting to see!
Saint John, NB
