Emulators generally offer a function called emu.lagged(), memory.get_lag_flag(), etc that says whether the current or previous frame is a lag frame.
Snes9x:
boolean emu.lagged()
Returns true if the last frame was a lag frame, false otherwise.
lsnes:
boolean memory.get_lag_flag()
Get the value of core lag flag. True if this frame has been lag so far, false if poll has been detected.
I'm wondering what this really means. If I am pressing some buttons just before a lag frame, can my input make some difference, or is it completely ignored? Reversely, can my input be ignored just before a non-lag frame?
Another thing: suppose that I'm playing and let X be the main character's position within the level. Is it possible for X to change during a lag frame, even so many other addresses remain constant? In this case, the lag frame wouldn't be negative during a TAS.
Lag often refers to delays experienced in computing communications. In console games, lag is the effect experienced when the game runs slower than usually. Lag is caused by there being too much action for the CPU to calculate in the time of 1 frame, and thus more what was supposed to take 1 frame, takes 2 or more.
Often, during lag, the game ignores the player’s input until the next frame. Objects usually also halt during the laggy frames. There might appear graphical anomalies, such as head-up displays appearing in wrong places.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Emulator Coder, Site Developer, Site Owner, Expert player
(3575)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Amaraticando wrote:
I'm wondering what this really means. If I am pressing some buttons just before a lag frame, can my input make some difference, or is it completely ignored? Reversely, can my input be ignored just before a non-lag frame?
In emulator the term "lag" refers to a frame in which input was not polled by the core. Assuming a flawless implementation of this concept, it means your input on a lag frame would have no effect on the game. In theory, one could remove all input on lag frames from a tas and get the exact same outcome.
Note that when you are tasing frame by frame, you input will happen on the NEXT frame. So if the current frame's lag status doesn't actually tell you any information about the input you are about to press.
Another thing: suppose that I'm playing and let X be the main character's position within the level. Is it possible for X to change during a lag frame, even so many other addresses remain constant? In this case, the lag frame wouldn't be negative during a TAS.
A TASer's definition of lag is bit different from that of the emulator. We generally are looking for input in which there SHOULD have been input polled but the CPU was too busy to do it. The lag counter will catch those instances but will also catch things like screen transitions and intros. We accept that tradeoff because it helps us catch actual "lag".
We are looking for this type of lag because generally during busy CPU lag frames, the screen/player doesn't move, or some other negative thing that costs time. However, sometimes the game can lag, but it still had time to move the screen or player, so that effectively there was no negative impact on the TAS. In my and Baxter's Super C TAS there's a lag frame exactly like this. By some fluke the player and screen move the expected 1 pixel, so there was no harm, and thus we didn't take any measures to remove it.
So in summary, the emulator lag counter is nice, but still rather subjective. You still have to have the experience and expertise to interpret what you are seeing and use it effectively .
Thanks for the information, that's exactly what I was looking for. I was trying to write a script to convert Snes9x movies into lsnes or Bizhawk's format without desyncs, by extracting the effective input (ignoring the lag frames) and injecting it into the new emulator frame by frame if, and only if, the next frame is not laggy.
Due to the difference between emulator lag and TAS'er lag, it still desynced after some time. So, it might be impossible or I should try another method.
The desyncs could also be caused by changes in emulation. As a crude example, if an SNES9x operation results in a pixel position of 16.999 and the corresponding operation in lsnes gets a position of 17.000, then that could be enough for some other calculation (e.g. collision detection) to return a different result, which could easily cause a desync.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
