As a speedrunning fan, I've watched hours of Super Mario Bros speedruns, and have heard the term "lag frame". I don't think it's similar to typical computer lag, but instead an extremely technical reason why the game skips a frame at a specific point in the game for seemingly no reason. In speedrunning, this is most commonly known as the "lag frame".

My question is if games on the TurboGrafX16 suffer from lag frame in any way, and if this can be avoided in a future re-implementation of the machine using modern technology.


  • 2
    Can you please give some examples? Like youtube links with timecode.
    – lvd
    Oct 24, 2018 at 5:57
  • 4
    The comment to youtube.com/watch?v=tD6fCPPmBMA says "You can easily see that if the gamemode routine takes too long, the V-Blank routine cannot update for the next frame, so a lag frame is needed to allow the gamemode routine to finish", so I think a lag frame is when processing takes so long that you miss your PPU access window for the next frame, and end up with a one-frame stutter.
    – Tommy
    Oct 24, 2018 at 18:27
  • 1
    @JackKasbrack: If calculations take too long, one of a few things may happen: 1. The screen loses vertical synchronization (I think the Atari 2600 is the only system where that happens); 2. The game may crash; 3. The action may be delayed one (or some integer number) of frames; 4. The action may be delayed by some other amount, possibly causing slight visual disruption if items which are supposed to be changed (or erased and redrawn) during vertical blank are updated during the visible frame. Of those, #3 is generally considered least disruptive. What sometimes varies among systems...
    – supercat
    Oct 24, 2018 at 18:49
  • 1
    ...and publishers is the extent to which programmers limit game complexity so as to avoid letting worst-case update times get long enough to affect game speed. If there isn't enough time to do everything that needs to be done, though, something's gotta give.
    – supercat
    Oct 24, 2018 at 18:51
  • 1
    It's certainly possible to design games that can always have this problem ... E.g. a game with variable number of enemies that continues spawning them until it runs out of time to deal with them. I don't know if anyone actually did this, though.
    – Jules
    Oct 25, 2018 at 9:35

2 Answers 2


I don't know if any TurboGrafX16 games suffered from this problem, but they were not fundamentally immune. Any game pushing the limits of a console in this era could have lag frames, even if the limits are higher. A bug could cause it even in a game that doesn't come anywhere near to pushing the limits. A NES with a faster CPU could potentially fix the lag frames in Super Mario Bros but it would likely cause compatibility problems with a wide range of games.

The explanation for the lag frame is actually not that complex. Console games of the pre-3D era were all tightly synchronized to the TV screen refresh rate. Games needed to fully update the display in a single screen refresh (1/60th of a second on NTSC consoles, 1/50th of a second on PAL consoles). If took longer than this then the game would display the same frame for twice as long as normal (or more if it took even longer), but the game's internal logic would behave as if only a single frame had elapsed. So if Mario was moving across the screen at the rate of one pixel every frame, a lag frame would cause Mario to stop moving for one frame. In a second he would move 59 pixels across the screen instead of the 60 he should have, assuming an NTSC console and just one lag frame.

Every 1/60th of a second (1/50th PALs) the console would start the process outputting a frame to the TV. This process would end with the vertical retrace, where the CRT beam would be turned off and moved back up to the top of the screen. At this time games would read the player's controller and update the display as necessary. Normally most games wouldn't have to do much to update the display, just move a few sprites, and change a few tiles. On most consoles, the Atari 2600 a notable exception, the actual output of the display was handled in the background by the graphics chip. After updating the display, the game program would simply wait until the next vertical refresh.

Pseudo-code for the logic of most games looks like this:

while not game_over:

If updating the display took so long that the vertical retrace happened during the update then the game would simply not notice. The game logic would assume the update_display code was being called after each and every vertical trace.

I don't know what would cause Super Mario Bros to sometimes take longer than normal to update the display. Normally games try to finish updating the screen by the time the vertical retrace reaches the top in order to prevent tearing, leaving a lot of extra time left over. It could be that there's a lot that needs updating, or it maybe its unpacking graphic or audio data from ROM into RAM. It could just a bug that causes something to take much longer than it should. Given that the lag frames you mention appear to be the result of glitches exploited by speed runners, it's probably the later.

  • "virtual retrace" should be "vertical retrace" Oct 25, 2018 at 2:12
  • Minor correction in the case of Super Mario Bros and other NES games: Lag frames happen when the game logic takes too long, not the display update routine. Every frame, Super Mario Bros. updates the display, reads the controller, updates the audio engine, and runs the game logic, and the game logic took the bulk of the time. (If the display logic took too long, graphics data and configuration would become corrupted because the CPU and PPU would be simultaneously modifying the same address registers.)
    – NobodyNada
    Nov 6, 2018 at 0:07
  • @NobodyNada I've ignored sound and folded the game logic into "updating the display" because ultimately that's what its doing.
    – user722
    Nov 6, 2018 at 0:12
  • @RossRidge Got it. On the NES, there’s usually a big distinction between game logic and display logic because writes to the display were only allowed during vertical blanking. Game logic would run during the visible part of the picture, updating the state of the level, player, and enemies, while vertical blanking was a rush to copy needed tile updates before the start of the next frame.
    – NobodyNada
    Nov 6, 2018 at 1:05

Yes, all machines of the era could have this kind of lag frame.

The issue here is that under certain very specific circumstances the Nintendo console can't finish all the processing it needs to do in one frame. Normally the game limits the amount of processing to be done so that it all finishes in one frame, but if a particular glitch used in speed running (the "Bullet Bill glitch") happens when the player's score contains certain digits it takes slightly longer to update the score display, and processing spills over into the next frame.

This results in the game having a duplicate "lag" frame, where the in-game timer does not advance. That timer controls how Bowser acts at the end of the game. In reality N frames have been displayed, but because one was a duplicate lag frame the game behaves as if N-1 frames had passed.

Many games of the era used this scheme for timing, on all 8 and 16 bit systems. Any game that could occasionally slow down could experience lag frames. PC Engine / TG16 games were not immune.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .