Hi Calamity,
Thanks for looking into this.
I can't elaborate it right now, but it's not a matter of GM being laggy when input is polled later in the frame, it's actually the Amiga which doesn't get input on time when input is polled early in the frame
Would have been interesting to know a little bit more of your reasoning.
Not sure if I follow you because the Amiga hardware results seem to fit the expected values for the testcases on real hardware quite well.
Button 26 - expectation vs realizationTheoretical best case: button activated at line 25 (LED is filmed to go off), line 26 test: yes button pressed, program waits for vsync at line 310, turn screen yellow, first visible yellow line on camera comes then after blanking at rasterline 26. Lowest possible latency on real Amiga thus 313 lines or ~ 1 frame of latency
Worst case: button activated at line 27 (LED is filmed to go off), line 26 test is just missed, 1 frame will elaps before test at line 26 registers button press. So worst case is "best case + 1 frame" = 2 frames latency.
Latency results for a test with random button presses will be a randomization between best and worst case with an expected value of the average between the two, i.e. (1+2)/2 = 1.5 frames of latency. Any random button test should approach that value if the test is working correctly. Results with real Amiga was 1.7 frames for 10 button presses. Close enough an approximation with 10 button presses I think.
Button 260Same reasoning for button 260 test on real Amiga:
Theoretical best case is button activated at line 259 (LED on camera off), registered at 260, wait to 310, turn yellow, first visible yellow lines on camera at line 26 in next frame. Lowest possible latency on real hardware for button 260 test is (52+26)/312 = 0.25 frame
Worst case is button activated at line 261 (LED on camera goes off), line 260 check just missed, 1 frame will elaps before 260 line test will register button press, etc. So worst case is "best case + 1 frame" = 1.25 frames.
Expected value of randomized button presses is thus randomization between best and worst or (0.25 + 1.25)/2 = 0.75 frames of latency. The measured result was 0.8 frames of latency for button 260 test on real hardware. Again close enough an approximation.
Based on this I expect the button test to be valid.
I'll come back to this later when I have some time.
That would be nice.
In any case, I've been doing an additional testcase without the button test. I did a game test that I also did previously for WinUAE. It's the Turrican II main character "jump" test. Real hardware versus GM with framedelay 7. Test is simply on startup of the game the main character jumping. Average of 10 button presses.
Turrican 2 "jump" test:Real Amiga: 2.2 frames of latency, rounded 2 frames
GM fd7: 3.3 frames of latency, rounded 3 frames
So also in this test GM is lagging one frame versus real hardware. If I speak for myself, the pattern seems obvious. Button 26 is one frame short of where it should theoretically be. Button 260 is lagging by a frame, Turrican 2 is lagging by a frame.
To be honest I think I'm getting a bit tired with the topic. It happens I guess. So I'll leave it until someone else comes around to show something different for a change: hardware like response with Amiga emulation.
In any case, I guess now's a good time to return to some good old Arcade gaming with GM!