How Frames Work

How Frames Work

There's a lot of misconception about the ramifications of "frame perfect." I had to draw little diagrams in order to understand it myself, so I'm going to (crudely) reproduce similar illustrations here.

Melee runs at 60 frames per second. A frame becomes our unit of time within the game. In order to discuss consistency with very tight input windows, it is important to recognize how frames relate to actual time.

Let's look at a simple example.
The illustration above describes zelda short hopping out of shield on frame 6. In the "input" row, red signifies a hard R press and gray signifies a Y press. In the "in game" row, red signifies shield, gray signifies jumpsquat, and light gray signifies airbourne.

At every vertical line (spaced 1/60th of a second apart), the gamecube reads the state of your controller, then applies this information to the following frame. This means that in order to jump out of shield on frame 6 you have to press and hold Y sometime after frame 5 starts but before frame 6 starts. Similarly, in order to do a short hop, you need to release Y at any point between the start of frames 6 and 12.
This is simple enough and the takeaway is that in actuality button presses must be started before the frame that they are intended to influence.

Let's look at a trickier situation.
This is what perfect multishining might look like.

Here, in "inputs" light gray is down on the analog stick, red is B, dark gray is Y. In "in game" blue is shine and dark gray is jumpsquat.
In order to grounded multishine, fox needs to shine on the exact frame following his 3 frame jumpsquat. It is very difficult to move from Y to B so quickly.
It is also effectively impossible to perform any frame-perfect inputs with 100% consistency.

The inputs in the following diagram are identical with the exception of the 3rd B input, which has been delayed a minuscule amount, less than .01 seconds. The in game results, however, are dramatically different.
Because of the slight delay in the third B input, melee registered one frame of airborne fox (noted in yellow) after the second jump. The third shine is not grounded, and jumping from it (with identical timing with the first multishining example) results in a double jump from shine (noted in orange) and then by a fox hanging helpless in the following shine.

When we play melee we are forced to approximate exactly when in real time the transitional lines between frames occur. Because you are not capable of knowing exactly when the inputs for frame 16 are read (because you don't have an internal metronome so precise and more importantly you have no way of syncing your internal rhythm with that of your gamecube), slight lapses as described above are impossible to avoid with certainty.

When theorycrafting please remember to consider these points and account for the inherent risk in frame perfect links. With practice the risk will be greatly reduced, but it will always be present in a 60fps evironment.


On console melee's controller polling is inconsistent, which means for us that in addition to the human element, there is a mechanical randomness to the time within the frame that your controller is polled, further nerfing frame perfect inputs.

1 comment:

  1. This post is so perfect. Now I can link this whenever somebody questions about why certain in game windows should be 2 frames instead of 1 (not JC shine of course) Do you think increasing the controller polling would help this discrepancy?