Just to make sure I understand : displaying a square in LUA is not rendered through the same "pipeline" as emulation stuff ? So oomek's data just measures the time it takes between pressing the button and displaying some acknowledgement square on the screen ? Which means "My rig has an input lag of XXms, which doesn't include emulation/natural emulated system lag" ? Which also means "This measured input lag is probably increased by the game itself, but we can't measure this yet". Am I right ?
Indeed as he says oomek's test is for everything that affects delay on top of the game's emulation itself (afaik: video sync, input polling)
I don't know about the generated square's reliability, but the figures he got at the very least match the theory behind Groovy's use of d3d9ex and frame_delay very well.
But yeah for measuring the delay of an emulated game system itself, usually people use a LED wired to a button and record with a high-speed camera, etc, but it's bothersome and how to use and count varies with people, settings, hardware...
The drivers made by MAMEdev aim at accuracy, so if we could manage to more reliably and easily measure delay of the core emulation like that, taking out the other lag sources (OS, controls pcb, monitor, vsync, etc) the values collected should match the 'natural' original delay of the games running on the original arcade boards.
(or at least pretty close, MAME emulates in frames and is not 100% accurate, also sometimes it uses other emulated devices and other specialized drivers in conjunction with the game/system's core, which can add lag...I think? anyway that too would be revealed)
The many, many individual games/system's delay in MAME is one of the biggest black holes in the world of emulation, and at the source of a lot of confusion and conflicting narratives, it would be great if someday a testing method could shed enough light on this. A database of measurements could then be built and easily updated.