Pause-menu testing is inconsistent. #12
Description
UI elements like the pause screen have RnG... (ffs)
They can be slightly shifted left, right, up, and down, and apparently this is recalculated every now and again... or perhaps every level load? Not sure.
In any case, this means that the single-image used currently for matching the pause menu isn't enough if high match-percentages are used.
So it's going to mean either more pause-menu shots to compare against; (which is a bit ridiculous considering what it is after being threshed) a larger test area possibly, although the shifted state of things will translate so I anticipate increase to match percent to be negligible; or some kind of algorithmic solution.
As for algorithmic concepts, the first that comes to mind is to do something akin to what splitRP used to do in the old build... locate the first white/black pixel after a thresh and recenter/recrop. This is a bit too outside the idea behind the new splitRP, though, and would need a row/column sum analysis that adds processing time and would produce weird results on non-matches without significant foresight.
The second that comes to mind is a shake-test. Ostensibly, re-cropping from various positions left, right, up, and down of center and testing those as well. This would add multiple comparative checks to the processing window, and the amount of "shake" would have to be determined somewhat arbitrarily.
That said, a shake process could reduce the number of level complete images required as well. And that makes it a bit more of a viable idea, I think. The shake could be done at load time on the stored image, and the amount (in pixels) declared in the .rp file. But if one shake created 4 images to test, each image would have 5 and that's 5 tests and... Just 2 images would result in more than we're already using.
The other way would be to shake the screen-capture, which would be done by cropping, likely requiring buffer-space between the test area and the larger capture area. I suppose its ultimately the same scenario, just the crop being done live or ahead of time.
The TLDR is: Not sure yet how to handle it, but the idea of a 'shake' function is intriguing.