Do TG16 games and software suffer from lag frame similar to NES Super Mario Bros?

Question

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.

sources:
https://www.speedrun.com/smb1/thread/yxs3c/1#gz6jx
https://kotaku.com/world-record-for-super-mario-bros-broken-by-a-single-f-1787319130

Answer 1

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:
    wait_for_vertical_retrace()
    read_controller()
    update_display()

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.

Answer 2

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.