I've never heard of anything like this. Do you have any examples?
I've played with SNES emulators source code in the past...
It's hard to provide simple examples, but it's not that hard to explain.
Fondamentally, an emulator keep the state of the original console, and perform the very same operations. For the emulator to work properly, the processor that run the emulator must be able to do the same operations in less time than the original, even if it doesn't have the instructions for it (for example, SNES has special video modes that allow sprites and background tiling. A PC don't have specific mode for this, any "automatic" operation on images has to be recreated with OpenGL or similar set of commands).
That's the easy part of emulation.
The hard part comes from timings. Assuming you have a PC "powerful enough" (we'll discuss that later), each instruction/operation is done faster on the PC than on the regular hardware. So the PC has to "wait" the exact time so that it doesn't run faster than the original hardware.
For example :
Code:
Original
----A----|---B---|-----C-----|--D--|-----E-----|...
PC :
--A--|-B-| wait |---C---|-D-| wait|---E---|...
You can't do this for all instructions. IIRC, ZSNES synchronize something like a million time per second to get proper emulation, and that's still not perfect. Because of higher speed in PC, you'll get some bugs, which are circumvented by recognizing the game and tweaking the timings. It's even worse when the PC has to emulate several chips: if one emulation is in advance on another one, you'll get bugs, so you need to synchronize everything all the time.
Better emulators like BSNES synchronize
one hundred million times per second, so you won't see any difference. Nearly all instructions are processed exactly at the correct time.
Now, about input lag in console. There's input lag in any game/console, because it's the time between the press of a button, and the moment the image is sent to TV. Since input readings are done at specific times, and they have to be processed, you'll always have input lag.
For example, an old game could do a single input read for each vertical blanking of the screen, so the input lag would be something like 15ms. Modern games have double, triple buffering, input filtering, etc., and input lag has skyrocketed (it's over 100ms in some games, like GTA for example... that's the game lag, not the display lag).
Now, the fun part. There's lag in old games because the processors were slow. You had to compute the motion of the sprite on screen after the button press, and before displaying the result. It takes time.
By tweaking the timings, you can move the "wait" states in the emulation just after the blanking and before the button press.
Again, the example. For eample, A is input reading, B, C and D are computations, E is displaying
Code:
Original
----A----|---B---|-----C-----|--D--|-----E-----|...
PC (normal) :
--A--|-B-| wait |---C---|-D-| wait|---E---|...
The input lag is the time between A and E, and in this proper emulation, the input lag is the same in emulation and in original hardware.
But imagine you're doing this:
Code:
PC (tweaked) :
wait |--A--|-B-|---C---|-D-|---E---|...
in this case, the input lag is lower in the emulation, because the input readings have been done later, which is allowed by the fact that the computations are done faster.
It's not that hard to implement in emulators, you just play with the synchronization steps, letting the PC think it's later than it really is in the ms just after the V-blank.
That being said, you'll introduce plently of bugs (some strange ones). That's definitively not proper emulation, but technically, you'll reduce input lag. Should you solve all the strange bugs introduced by this trick, you could improve the response time of a game.
In fact, I've even worked on negative input lag (meaning the game react "before" you press)... Of course, there's glitches, but the idea is that you have a thread that try to predict your inputs in advance, so that it can display the results in advance. Should it fail, you run the last milliseconds in another thread that recompute the last milliseconds. You'll have a glitch on screen, when the software correct the error, but except in those moments, the game actually run before you ^_^ That's the kind of tricks many online games do to hide the latency (when the error of the prediction is corrected, you see opponents doing things they shouldn't be able to do, like running faster for a time, till they reach their correct position, or even warp).
