Pause Buffering: Difference between revisions
No edit summary |
(Add more info) |
||
| Line 4: | Line 4: | ||
Pause buffering can be used to press inputs on two or more in-game-contiguous frames. There are three parts to a button input—[[Button press|pressing]], [[Button hold|holding]], and [[Button release|releasing]]. If the game detects that the button is being inputted on two frames in a row, it will detect that the button is being held, even if there were two separate presses. Furthermore, holding a button often does nothing. | Pause buffering can be used to press inputs on two or more in-game-contiguous frames. There are three parts to a button input—[[Button press|pressing]], [[Button hold|holding]], and [[Button release|releasing]]. If the game detects that the button is being inputted on two frames in a row, it will detect that the button is being held, even if there were two separate presses. Furthermore, holding a button often does nothing. | ||
In situations where it would be advantageous to press the same button for two frames in a row, those two in-game frames can be separated by opening the pause menu. This provides time for the game to recognize the release of the button, and be able to detect another press once the game is unpaused. In short, pausing allows an input to be released and pressed again without changing any in-game states. | In situations where it would be advantageous to press the same button for two frames in a row, those two in-game frames can be separated by opening the pause menu. This provides time for the game to recognize the release of the button, and be able to detect another press once the game is unpaused. In short, pausing allows an input to be released and pressed again without changing any in-game states. For example, a dive can be followed immediately by a dive recover, which is useful while holding an object [[handsfree]] in the [[A Button Challenge]]. | ||
Another application of pause buffering is in [[Pause Buffered Hitstun]], which lends itself to [[HOLP Preservation]] and thus releasing objects remotely. The player can avoid updating the [[HOLP]] by taking advantage of [[Mario]]'s [[Hitstun blinking|flashing effect]] after [[hitstun]], an effect that continues if Mario is inside an enemy [[hurtbox]]. After being hurt in any way but small [[fall damage]], Mario, along with a held [[ticket]], will become transparent on every second frame. His opacity depends on the parity of a [[global timer]], so he is not rendered on odd frames. The global timer is incremented on every frame, including paused frames. By pausing for the minimum three frames and unpausing for the minimum one frame when the timer is odd, Mario and the ticket will effectively not render until the blinking effect stops. Because the ticket does not need to render, the HOLP is not updated during that time. | Another application of pause buffering is in [[Pause Buffered Hitstun]], which lends itself to [[HOLP Preservation]] and thus releasing objects remotely. The player can avoid updating the [[HOLP]] by taking advantage of [[Mario]]'s [[Hitstun blinking|flashing effect]] after [[hitstun]], an effect that continues if Mario is inside an enemy [[Hitbox#hurtbox|hurtbox]]. After being hurt in any way but small [[fall damage]], Mario, along with a held [[ticket]], will become transparent on every second frame. His opacity depends on the parity of a [[global timer]], so he is not rendered on odd frames. The global timer is incremented on every frame, including paused frames. By pausing for the minimum three frames and unpausing for the minimum one frame when the timer is odd, Mario and the ticket will effectively not render until the blinking effect stops. Because the ticket does not need to render, the HOLP is not updated during that time. | ||
Revision as of 01:41, 14 July 2018
Pause buffering is a technique achieved by strategically pausing to cause unusual effects during in-game (unpaused) frames. Note that the process of pausing and unpausing in and of itself takes at least three frames, so typical pause buffering means that the game is being played at quarter-speed.
Applications
Pause buffering can be used to press inputs on two or more in-game-contiguous frames. There are three parts to a button input—pressing, holding, and releasing. If the game detects that the button is being inputted on two frames in a row, it will detect that the button is being held, even if there were two separate presses. Furthermore, holding a button often does nothing.
In situations where it would be advantageous to press the same button for two frames in a row, those two in-game frames can be separated by opening the pause menu. This provides time for the game to recognize the release of the button, and be able to detect another press once the game is unpaused. In short, pausing allows an input to be released and pressed again without changing any in-game states. For example, a dive can be followed immediately by a dive recover, which is useful while holding an object handsfree in the A Button Challenge.
Another application of pause buffering is in Pause Buffered Hitstun, which lends itself to HOLP Preservation and thus releasing objects remotely. The player can avoid updating the HOLP by taking advantage of Mario's flashing effect after hitstun, an effect that continues if Mario is inside an enemy hurtbox. After being hurt in any way but small fall damage, Mario, along with a held ticket, will become transparent on every second frame. His opacity depends on the parity of a global timer, so he is not rendered on odd frames. The global timer is incremented on every frame, including paused frames. By pausing for the minimum three frames and unpausing for the minimum one frame when the timer is odd, Mario and the ticket will effectively not render until the blinking effect stops. Because the ticket does not need to render, the HOLP is not updated during that time.