I finished some testing with a build that Calamity sent me to verify improvements to frame_delay, and the results look good.
First let me note my experience with XP64. I was able to get some decent results at one point, but then found that I couldn't achieve this consistently. The amount of lag seemed to vary randomly after each time I rebooted the PC. I didn't troubleshoot this extensively. It may have been fixable, but I didn't want to spend much more time on XP because my goal was to confirm the viability of 7 for myself and, if so, make the change to 7 permanently. Your results may vary with XP. The data points I used for XP represented the best I could gather from one continuous run in GM.
In any case, these tests were all performed in GM 155 with the game "Thunder Cross" at frame_delay 7. The number of frames refers to frames of gameplay at 60Hz. I collected 40 data points for each test to find an average. I had about 75 data points for the first test in Windows 7, but found that the average of all the points was within 1% of the average of only the first 40 points, so I decided 40 would be enough as the standard for my tests. A spreadsheet with the full results is attached, but I'll summarize here:
-GM 155-
XP64 - average: 2.200 frames, average with outliers removed: 2.044 frames.
7x64 - average: 2.025 frames
-GM 155_test-
7x64 - average: 1.913
The average with outliers removed for XP was determined by omitting occasional data points of 3 or 3.5 frames (6 or 7 of 120 fps video). Notice that there is no such value for Windows 7. This is because the delay NEVER exceeded 2.5 frames in Windows 7. Windows 7 was much more stable all around. I got the exact same behavior after restarting GM and the PC a bunch of times. Again, your results with XP may vary, but I can at least vouch for quality in Windows 7.
Also notice that lag in the test version is even lower, "statistically." I don't really know how important these averages actually are. Given the low amounts of lag that Calamity is achieving (
), the amount of time that comes down to chance (at what point in the frame the button is pressed, the delay until the LED is captured by the camera, the timing offset between the camera and the CRT) becomes relatively high. I think the most important thing that can be said about these results is that there is usually a visible on-screen response to the physical button input within 1.5-2 frames, 2.5 at most (in Windows 7), and that the new test build is at least as good if not better.
Setup:
ASUS HD4350 -> TC1600 -> KV-27FS120
Kade Encoder - USB Keyboard Mode
XP64
Core i3-2130 Sandy Bridge Dual-Core 3.5GHz
Asus P8Z68-M Pro
2x4GB DDR3 SDRAM @ 1333MHz
7x64
Core i3-4370 Haswell Dual-Core 3.8GHz
Asus Z97-M Plus
2x4GB DDR3 SDRAM @ 1600 MHz
*** rename attachment to .xlsx, I had to change the file extension to allow attachment ***