Skip to content

code_digging.md

Latest commit

 

History

History
39 lines (26 loc) · 1.94 KB

code_digging.md

File metadata and controls

39 lines (26 loc) · 1.94 KB

Information extracted from code digging

Shift held and triggered

Internally, jump is considered differently if jump was just triggered, or maintained pressed. This can be used to produce glitched demo strings that attempts to jump once per frame (which does not allow for one jump per frame, however).

I digged into the code to check whether this can be done with inputs, but it's not the case. Relevant part of the code:

var v3 = inList[PINPUT_J];
inList[PINPUT_J] = Key.isDown(this.KEYDEF_J);
inList[PINPUT_JTRIG] = inList[PINPUT_J] && !v3;

Manual tests have shown that this code is only called once per frame. Increasing the framerate to 80 or 120 fps does not allow to reset inList[PINPUT_J].

Why we can't jump on every frame

There are two layers of protections against jumping on every frame:

  • when registering inputs (here and here in demos)
  • when using inputs to estimate whether to jump or not: logic returns if ninja is already in the jumping state (here)

The consequence of this is that even if we found some kind of pause-buffering trick to bypass the first layer, we would still be blocked by the second layer. One frame has to pass for the ninja state to change.

Even if we remove these 2 protections through hacks, chimney jumps are still not possible on a one-jump-per-frame basis because the walls are too far away.

L+R = nothing

We've been wondering for a while if holding left and right in a frame is strictly the same as doing nothing. It is:

if (inList[PINPUT_L] && inList[PINPUT_R]) {
    inList[PINPUT_R] = false;
    inList[PINPUT_L] = false;
}

Radius

Player radius is actually 12 * 0.8333333333333334 = 10.0000000000000008. See here.