Cool then I’ve been testing it right.
So the point of creating a database of each game’s internal input lag would be to automate the setting of how many frames to runahead, correct?
Seems to me that could be automated without a database, although not with a 100% certainty:
- Two instances of the same game could be ran simultaneously at fast forward, with one of them autofiring “start” at every frame and the other having no input.
- Each frame generated with one instance is compared to the frame of the other instance, if the two are running in sync and they differ even by a single pixel, that means that the input was registered and had an effect on the game (doesn’t matter what effect exactly).
- Register the frame in which the change ocurred and the frame in which the input ocurred, and count how many frames there were between the two.
I said “start” because that’s the usual button that is more likely to have an effect as soon as the game boots, there could be a set amount of frames (for example 30secs, i.e. 1800frames) after which this script would then try another retropad button, like “A”.
The problem with this is that some games have different input lag in-game than they have for example in the menu, so it wouldn’t always be accurate. Also, I don’t know how resource intensive this could be, if it takes too long to have the user waiting for it to finish then at least a similar method could be used to automate the creation of an internal input lag database to ship with retroarch.
Given how easy it is to measure internal input lag it sounds hardly worth the trouble to me, but I guess some users might care about that.
EDIT: I forgot to mention one thing, the above method would not be able distinguish which of the frames in which the input ocurred was resposible for the change in later frames, so it should be:
- Same as above, but store saves states of the last 7 frames.
- Same as above.
- Register the frame in which the change ocurred. Load state for 2 frames before, and repeat the test from that point. If there is a change on the same frame as it happened on the first test then the game has 1 frame of input lag, finish the test. If not, then load the state for 3 frames before and repeat the test, and iterate like this until the maximum possible amount of internal input lag is determined. (currently it’s 6)