What I have in mind is basically a brute-force with a whitelist (always on) and blacklist (always off) to constrain the explosion of possibilities. The general form should be O(c
n), where n is the number of inputs not on either list and c is (max button states * number of frames).
E: Here's the SMS table.
"P1 B1": "False"
"P1 B2": "False"
"P1 Down": "False"
"P1 Left": "False"
"P1 Right": "False"
"P1 Up": "False"
"P2 B1": "False"
"P2 B2": "False"
"P2 Down": "False"
"P2 Left": "False"
"P2 Right": "False"
"P2 Up": "False"
"Pause": "False"
"Reset": "False"
14 inputs, so for one frame's worth of bruting it's 2
14. In practice, it's only 13 inputs as the reset button is a BAD THING.
Constraining to P1 only would instead yield this table.
"B1": "False"
"B2": "False"
"Down": "False"
"Left": "False"
"Right": "False"
"Up": "False"
6 inputs, so for one frame this would be 2
6 - 64 possible results before black/whitelisting. For two frames this would be 4
6 because then you have four possible state combinations for each button rather than two - off-off, on-off, off-on, or on-on. This is 4096 results before black/whitelisting, which is obstructively large. For that reason, it's best to both minimize input frames and maximize button locks - taking even one button out of the hypothetical 2-frame check brings it down to 4
5 - 1024 possibilities.