I'd like to explain a general but in most games probably at most restrictively applicable method to effectively ''trade frame perfect inputs'' [which may sound strange and questionable at first if one hasn't heard of that concept before, but I'll elaborate on it below] that can be involved in (speedrun) tricks, for the purpose of transforming bio-mechanically (in the sense of the physical and speed related limits to the human hand) impossible (or at least extremely difficult) to perform TAS-only input patterns required for in-game tricks into more realistic or even decently executable new versions of input patterns for those tricks. I guess one could see it as a separate, advanced step in the same direction in which theory crafting goes for constructing setups that calibrate or normalize various parameters to make performing certain tricks easier.
The idea for this method is to add a suitable frame perfect input for pausing the game to the execution of a trick in order to allow to either simulate a frame perfect immediate button press release (of another input part of a trick) or to be given more time to switch the held inputs up and buffer them through unpausing the game.
If this method can at all be used in a game may depend on the following factors, among others: ° How pausing works in a game: Namely if pressing the pause button halts gameplay instantly or if gameplay is interrupted after a short delay (and in this case what the game's lag behavior is), provided pausing even is an option in the situation or even just in the game in general. ° How the game treats a trick that involves a longer gameplay process when it is interrupted by a pause in the middle of it rather than without a pause (since in some cases the game may react to pausing and continue in terms of game mechanics different than how it would without it, so that pausing doesn't solely delay gameplay).
A rather simple but good example for this that was already independently of my own separate theory crafting found in another community would be Wario World Super Jumps ( ), in which normally about 8 frames after initiating a Dash with an input the jump button has to be pressed, then released in the next frame and pressed again (and then can be held) in the next frame of this 60 Hertz game (for NTSC), in order to get the most jump height out of this (rather than lower jump heights with further off input timing). And to make this trick doable in this case, the frame perfect release of the jump button is avoided and instead a frame perfect pause is introduced in the same frame as the first jump press to create a longer time gap between the first and the second jump press. And while this version of doing the trick stays equivalent in terms of the count of frame perfect inputs, the advantage comes from not being forced to move the finger fast enough anymore for the 2nd jump press in relation to the first and the button release in between, but just having to press it at the right time and in isolation from the first jump press; and this ''de-coupling'' of frame perfect inputs in a chain of inputs is the crucial point here.
More concrete distinguished situations that may be resolvable with this method might be cases like the following ones: ° Cases where one is required to press a direction button in 1 frame and one has to steer away or press another button to input the complete opposite direction in the very next frame (rather than having the lenience for it to take more frames, or especially in cases where one is using a control stick with ''analogue'' inputs, i.e. a fine input field within which joystick positions are polled, rather than just a binary check for e.g. each of 4 different directions for if the direction is held or not) and is not allowed for the input polling to happen anywhere within the process of moving the control stick from 1 side to the other, resulting in the signal sending a value for an intermediate control stick position. And this also includes cases in which an immediate direction switch has to happen again immediately afterwards. ° Especially cases in games that run at very high frame rates like 60 Hertz or 120 or more Hertz, it can make a big difference to break frame perfect input chains required for a trick up (e.g. in a simple case that may be just two different positions of a control stick with 360° movement freedom in 2 consecutive frames), by turning a situation in which one would otherwise need to steer the control stick into another direction at proper angle and inhumanly fast into a situation via pausing the game at the right frame ahead of time or together with the first directional input (depending on how the given game's pause mechanic works, if one can even pause at the time), and then buffering the 2nd directional input through the unpausing process. ° Cases where an input needs to happen for only 1 frame but not longer, and in those cases pausing may allow to cut the active gameplay time off and allow to just press and hold that button input rather than having to release it after pressing it for 1 frame. ° Cases where one has a chain of inputs that need to happen in rapid succession within few frames, where the input chain would be possible to be executed up to some frame but continuing with what follows wouldn't manually be possible when one is forced to execute the 2nd part immediately afterwards; and where one would be able to execute the 2nd part on its own as well, provided one wouldn't be forced to execute the 1st part of it and interruption-less chain that into this 2nd part (because in that case, introducing a buffer time inbetween may be able to resolve this).
Disambiguation: The purpose of the method I'm trying to help giving insights into - while it may also be closely related to other useful applications like providing audio cues or visual references for afterwards as side effect - is not about pausing for the purpose of gaining information or feedback from the game (that one then due to the game pause can actually process and react to in time for use of it later) e.g. to get a better orientation on one's position and surroundings while they are frozen in place or to know when (in relation to unpausing) the next inputs should occur, or if one should pause again (e.g. in a bufferable manner when possible) to let 1 or a few frames pass until one can unpause safely to be able to buffer the next input for a trick (outside of maybe the pause button presses involved in the trick, assuming the trick doesn't require pausing in and of itself, if perfect machine-like inputs are provided like in tool-assisted superplays). Neither do I mean to address cases where the pauseless execution of a trick was previously thought to be impossible but later turned out to be possible to be performed by someone else or with more practice, muscle memory, and different cues (without qualitatively changing the manner in which the trick is attempted to be done), or where the difficulty and associated inconsistency of getting a trick was just too high without pausing, for the plain purpose of separating the input chain (rather than for also getting visual or audible cues), which are their own separate cases. But instead, the sole point here is meant to address cases where the trick in question otherwise can manually just not be performed in general, for cases where this is due to the bio-mechanical limits of human hands, for example, where any amount of practice, cues, muscle memory or reaction times may lead to performances that may be close to successfully executing a trick but turn out to be still unsuccessful. This is the kind of ''dead end'' stuck situation I'm having in mind here, with this alternate method of approaching such situations.
In particular, while this ''input decoupling'' method, or ''frame perfect input trading for bio-mechanical benefits'' also involves pausing the game, it's purpose is not the same as for what's generally referred to as a plain Pause Buffer: ''Buffering a command out of a paused game. Runners can repeatedly pause a game to find the exact frame they want to execute an input on for frame perfect tricks''.
However, I think a method like this also presumably would only be worth considering (in a speedrunning context) for otherwise extremely hard or impossible to in real time execute tricks that at the same time would lead to significant time-saves by making a glitch/trick performable or making an extreme case of a speed-technique doable (like maybe certain backwards longjump setups in Super Mario 64 or something along those lines), e.g. in order to make a short-cut accessible, or to trigger ''game-changing'' effects that allow important new possibilities (like opening up a new category / speedrun branch for a game or making an existing one more extreme, for changes that aren't time-saves but change the category-defining limits of a category). Of course, a pause typically would also cost time and may in speedrunning contexts be part of the trade-off for making a trick possible and/or easier to execute.
For the game Super Metroid and a romhack of it there is in total (so far) 2 more situations for which I realized myself that this method can be very useful, and I'll go into one of them as example below:
Trick: Saturn Climb (named after a tool-assisted speedrunner):
Here is a visualization (using the SNES TASing emulator lsnes) of the TAS inputs around the critical part of the trick (for which some of the inputs need to be as shown in the following screenshot, but not all):
For Super Metroid (running at 60 Hertz) on NTSC there exists this tricky walljump that is highly precise in the vertical and horizontal sub-pixel range for Samus' positioning from where the walljump has to be executed, as well as extraordinarily precise in directional input timing and the rapid changes of that. The critical part that appears to be impossible to perform in this manner are two immediately consecutive required instantaneous direction switches (from holding Right to holding Left within 1 frame and only for 1 frame, and holding Right again immediately after that, as one can see in the screenshot at the frame rows from 49600 to 49602).
Now (leaving out some details about previously also required frame perfect inputs which however would only need to happen in isolation from each other), by pressing Start about 1 second ahead of time (since in this game pressing Start doesn't pause it immediately) frame perfectly (which adds/introduces another frame perfect input that is not present normally), 2 new variants of this trick emerge from doing so, which would allow to overcome this rapid input hurdle:
(i) Either the earlier Start press makes the game enter the pause menu in the frame 49601, meaning that the gameplay frames relevant to Samus' movement end with frame 49600 (before frame 49601), in which case the first (frame perfect) Right (>) press can be held into the menu (which takes out the otherwise required frame perfect release of the button press), and from there one can buffer Left (<) through unpausing the game and then is only anymore required to instantly switch to pressing and holding Right (>) in the correct frame [which is a type of execution that has been shown to be doable on SNES controllers before].
(ii) Or the earlier Start press makes the game enter the pause menu 1 frame later, namely in frame 49062, and in this case after pressing Right frame perfectly, one would have to instantly switch to pressing Left at frame 49601 and can hold it into the pause menu, followed by being able to buffer holding Right (>) throughout all of the unpausing process in order to continue.
Also, when it comes to making precise tricks possible to execute, while games where initiating a pause makes the game stop instantly may in some cases have the advantage that the pause input can be pressed together with another critical input for a trick, so that doing both at the same time may come close to just pressing 1 button frame perfectly; games where initiating a pause happens with a delay may in probably more rare cases have the advantage that a convoluted input pattern doesn't get even more condensed with a pause input having to happen in the middle of it, because the pausing input can happen in isolation beforehand.
What I would hope could come from this would be the revisiting of previously as impossible to perform thought of tricks in games that were thoroughly tested for the respective input windows involved in them, for which this approach makes the difference, but also the same for tricks that haven't been looked into yet regarding the actual difficulty of performing them and associated input lenience windows for success, but are known to exist (e.g. from tool-assisted speedruns) already.
From what I read in the first part I'm pretty sure you're just describing pause buffering
TLDR but yeah, this literally sounds like pause buffering, you just called it something else lol. Games like OOT have been doing this for years to buffer inputs so achieve what is normally a frame perfect action. But of course this really only works if the game has some form of un-pause lag that allows you to buffer inputs, otherwise you're just pausing with no benefit.
Lieutenant_Boo and Timmiluvs, contrary to both of your (partly correct, but incomplete) understandings of what I attempted to explain, while the method I described does indeed also include certain cases of applications of the well-known pause buffering (namely those cases in which the direction, that is held with a control stick with 360° movement freedom, is for the gameplay instantaneously drastically changed, and only for those cases among these that otherwise would not be possible to be performed, namely without pausing the game), the method that I tried to explain is more general than that so this would only be a particular special case of it. In particular (and maybe I should have made this even more clear in my elaborate post), I am not referring to any pause buffer application cases that are doable without pausing the game already, which includes cases in which pause buffering is solely used for slower approaching of a critical gameplay frame in which a certain button needs to be pressed or released frame perfectly and in isolation from other potentially existing, for a trick necessary frame perfect inputs, because to release or press a button in the right frame (without there being other conditions about inputs that need to be made around the same time) does not require pausing the game for making such a trick humanly doable. The idea that I tried to explain is not just about turning a frame perfect input into an input with a larger input lenience window for successfully executing a trick by introducing a pause, but is focused on cases where introducing a pause is absolutely necessary (solely for reasons that lie within the limitations of the movement speed of the human hand) in order to perform a trick without tool-assistance. And Maybe this clears this up further, so that it is not confused as solely being that kind of pause buffering.
I didn't really understand the post, but I did see the line " but is focused on cases where introducing a pause is absolutely necessary (solely for reasons that lie within the limitations of the movement speed of the human hand) in order to perform a trick without tool-assistance", but wouldn't that still pause buffering? Cause to me at least it seems like your pausing the game for the sole purpose to execute certain inputs on certain frames, so in that case, I would still consider that pause buffering, since you are buffering an input
^ What Unbones said. Wind Waker HD uses pauses to do manual super swims by swapping control stick direction on each pause. Now technically that is possible to do without the pausing, but the pausing does make it massively easier. Now regardless of whether or not the trick is possible without pausing, using a pause to change the input is still pause buffering
Yes, Unbones, buffering an input through unpausing a game would also be included in this, but to quote my original post: ° Cases where an input needs to happen for only 1 frame but not longer, and in those cases pausing may allow to cut the active gameplay time off and allow to just press and hold that button input rather than having to release it after pressing it for 1 frame. This would also fall within the method I tried to describe, and in this case no input is held through unpausing the game (although admittedly one could also think of no input being held as also being a buffered kind of empty input).
And yes, while one may still use the name pause buffer for this, I frankly find the terminology ''pause buffer'' to be very vague, non-descriptive and non-explicit (and I don't think the whole ''spectrum of its applications'' is generally well-known yet even among experienced speedrunners, especially when there may be not many elaborate explanations that go into different cases covered by it). Hence I tried to think about other aspects that make up the differences between two (or more) qualitatively different versions of executing ''the same'' trick, where some versions involve pausing the game while others don't. Besides that, there is also games in which the gameplay can be halted by other means than pausing, or where there is multiple buttons that pause the game in different ways, so that is also why I tried to use a different wording, namely ''trading [or interchanging] frame perfect inputs'', before going more into the details and the goal that I had in mind, namely the avoidance of having to execute a trick in a manner that requires some inhuman hand movements.
Interesting, Lieutenant_Boo. I do have heard of super swim for Wind Waker HD speedruns, but didn't know very well about the specific execution of it, and yes that does appear to be an example of what I meant (although being related to a control stick, I guess, which I think is probably the most well-known type of pause buffer usage).
I also made a reddit post about this (in here https://www.reddit.com/r/speedrun/comments/hzqjdb/trading_frame_perfect_inputs_as_method_to_make/ ) and explained a bit more about it in a discussion over there, which may go over lesser known cases of using it.