Post
by rainwarrior » Wed Jul 27, 2016 3:21 pm
Suggestions for the lag test, pardon me if they're a repeat, I didn't reread the whole thread to check:
The lag test discards all early presses. This biases the results toward lag by half the imprecision of the human user. The lag itself should be consistent, but human precision varies from tester to tester (and condition of the tester). Since you don't know in advance how precise the user is, the amount of bias is unknown, and can't be properly corrected for. I think early results should be included to balance out this bias.
I also think displaying an indication of how "good" your timing was improperly biases the results. No matter the lag, the user can always anticipate to reach approximately "marvelous" timing, and labelling it this way gives them incentive to try to do this. It's no longer a measure of the hardware lag, but of their ability to anticipate, unless they can mentally ignore this measure of success being presented to them. The documentation mentions "if you are skilled at rhythm games"-- rhythm game skill means exactly that you can learn to anticipate and hide lag, which is the opposite of what this test should measure!
Ideally the user should be blind to their results as their coming in. I would just display "X results received" as it counts up to 10, and if you're rejecting "bad" results, bad should just be sufficiently away from the target (e.g. +/-20 frames away), not the early results.
Additionally, audio lag and picture lag should be measured separately. The user should only be using the audio cue, or only the visual cue; using them both at once is a problem if they're not the same. Thankfully there is the option to turn the audio off, and you can close your eyes to do an audio-only test, but it would seem to be more appropriate to have 3 options: picture only (to test), audio only (to test), picture+audio (to watch, same goal as "audo synch test").
The "flash" visual cue is a good cue for picture lag and should happen whether or not audio is on. Why is it disabled when you disable audio? (This is very strange to me.) Randomness on the other hand is not applicable to an audio-only test (again would reduce it to a test of the human, not a test of the lag); it should just be trying to match a steady beat. Randomness is good with the visual test though.
Suggestion for sound test:
Periodic noise (and regular noise for comparison), since some revisions of the Famicom are missing it.
Suggestions for documentation:
START seems to pause a test and enter its documentation, but it also enters a test and exits its documentation. I found this a little confusing because I didn't know what START's function was, and repeated presses end up doing a different thing each time (it enters a test, but can't exit it, but it enters documentation and exits it). Not really an issue once you're oriented, but maybe it would be more intuitive if START from the menu to you directly to the documentation (and exiting returned to either the menu or the test, depending on where it was launched from)?
