Difference between revisions of "Subpixels"

Revision as of 12:43, 20 July 2018

This game uses subpixels for its movement. This is how Link gets the movement speed of 2-1-2-1 on normal ground etc.

tl;dr: You have a "base speed" for any type of movement (0-4), and sometimes you get an extra pixel boost. If you move in the leftwards or upwards direction the pixel boost happens earlier (and in fact, it will always happen on the first frame of movement, this is why pumping is a thing).

How the coordinate and subpixel is updated during movement

Speed

See the table below for what speed Link has in different situations.

The speed values only applies to one axis, so for diagonal movement or movement into a slope, the total speed will be higher.

• Getting damage boosted/recoiled gives different speeds for different angels. Each axis can move in a maximum of $18 or 1.5px/f. The best angle in terms of speed would be a completely diagonal one, which would give $18/$18.
• When walking leftwards or upwards, the speed is reversed ($18 becomes $E8)
• The most significant digit (1 in the case of walking on normal ground) is added to the coordinate directly, no matter what.
• The least significant digit (8 in the case of walking on normal ground) is shifted left four times (8 becomes $80), and added first to the subpixel. If this causes the subpixel to overflow/wrap, we add an additional pixel to the coordinate.
• Example: The speed value of 16 (or $10 in hex) represents a clean 1 pixel per frame. 17 ($11 in hex) would be 1 pixel per frame, with an additional pixel being added every 16th frame.

Subpixel

• The game will reset Link's subpixel whenever you change direction of movement. A movement after a standstill counts as changing the direction of movement.
  • The game only looks at your dpad to find out if the direction changed. So if you walk upwards alongside a wall, and then press up and rightwards into the wall, it will treat this as a change of direction, even though Link is still moving upwards.

This means that pumping into a wall will function as two pumps, both when you press (from ^ to ^>) and when you release (from ^> to ^).

• Starting/executing a dash will not reset the subpixel. But if you cancel the dash with a movement, it will be reset.
  • If you however start a dash that ends up transitioning to another screen, the subpixel is not reset unless you start moving in a different direction on the next screen.
• Some items resets your subpixel and others do not.
  • Does not reset subpixel: Using sword, boomerang, hammer, rod, hookshot, dropping a bomb or picking it up.
  • Resets subpixel: Using medallion, powder.

Example: Walking on ground (movement speed is $18)

• Downwards
  • frame 1: Subpixel = 0x00 + 0x80 = 0x80. Coordinate = 0 + 1 + 0 = 1
  • frame 2: Subpixel = 0x80 + 0x80 = 0x00. Coordinate = 1 + 1 + 1 = 3 (subpixel overflow)
  • frame 3: Subpixel = 0x00 + 0x80 = 0x80. Coordinate = 3 + 1 + 0 = 4
  • frame 4: Subpixel = 0x80 + 0x80 = 0x00. Coordinate = 4 + 1 + 1 = 6 (subpixel overflow)
  • Etc

• Upwards
  • frame 1: Subpixel = 0x00 - 0x80 = 0x80. Coordinate = 0 + 1 + 1 = 2 (subpixel overflow)
  • frame 2: Subpixel = 0x80 - 0x80 = 0x00. Coordinate = 2 + 1 + 0 = 3
  • Etc

Example: Walking on stairs (movement speed is $0B)

• Downwards
  • frame 1: Subpixel = 0x00 + 0xB0 = 0xB0. Coordinate = 0 + 0 + 0 = 0
  • frame 2: Subpixel = 0xB0 + 0xB0 = 0x60. Coordinate = 0 + 0 + 1 = 1 (subpixel overflow)
  • frame 3: Subpixel = 0x60 + 0xB0 = 0x10. Coordinate = 1 + 0 + 1 = 2 (subpixel overflow)
  • frame 4: Subpixel = 0x10 + 0xB0 = 0xC0. Coordinate = 2 + 0 + 0 = 2
  • Etc

• Upwards
  • frame 1: Subpixel = 0x00 - 0xB0 = 0x50. Coordinate = 0 + 0 + 1 = 1 (subpixel overflow)
  • frame 2: Subpixel = 0x50 - 0xB0 = 0xA0. Coordinate = 1 + 0 + 1 = 2 (subpixel overflow)
  • frame 3: Subpixel = 0xA0 - 0xB0 = 0xF0. Coordinate = 2 + 0 + 1 = 3 (subpixel overflow)
  • frame 4: Subpixel = 0xF0 - 0xB0 = 0x40. Coordinate = 3 + 0 + 0 = 3
  • Etc

How it affects slope dashes

Dashing on a slope is a fairly volatile thing when you frame advance through it. Link will move anything from 0 to 3 pixels in both the horizontal or vertical direction, seemingly at random. And you will get random 1px/f in only one direction, and sometimes 0px/f in both directions. It is not completely understood.

One cause for the slowdowns seems to be the same mechanic as "corner nudging". The game thinks Link needs to be better aligned (too close to the wall in one direction) and moves him 1px in one direction away from the wall. This seems to happen less if your subpixels for both axes are the same, and you are moving in either a "pumping direction" or "antipumping direction" for both axes (<^ or v>). The main reason for this is that Link's coordinates updates equally in both directions in this case, since the subpixel will overflow/wrap at the same time throughout the length of the dash. So when the game auto-corrects Link's position, the dashing pattern doesn't mess with it afterwards. It still can happen though.

Another cause for slowdowns seems to happen when Link hits the very first pixel of a 8x8 corner tile (when his hex coordinates ends with 0 or 8). This can cause a 1px movement and sometimes a 0px movement.

What is certain is that the subpixel you have when a dash is started will affect how the slope dash ends up working out. You can get pixel boosts in either directions quicker/slower depending on what the subpixels are when you hit the corner, which would alter the path Link takes through the slope and create a Butteryfly effect. So even if you start your dash from the exact same coordinate, the slope dash can go fast or slow depending what the subpixel value is before the dash.

One way to make sure you get the same subpixel every time is to hit diagonal before starting the dash (Link would actually have to move diagonally too) This is because you 1. get a change in direction, resetting the subpixels, and 2. diagonal movement is a clean 1px/f so the subpixel will remain 0.

Bomb Clips

Since a criteria for performing a Bomb Clip is that you are positioned exactly below the explosion, your subpixel value will matter just as much as your coordinate when you start the slope dash, since different paths through the slope might or might not include the coordinate you need to visit.

Some setups works the same for all subpixels, in which case only the coordinate matters.

Swimming

The below is mostly just some observations from frame advancing in emulator, and might not be 100% accurate.

• Swimming is 100% acceleration based.
• The acceleration seems to be around 1/32 pixels per frame. So after 4 frames of holding >, you will have the speed 1/8 pixels per frame (or 0.125 pixels per frame).
• Deacceleration seems to be around 3/64 pixels per frame.
• The acceleration does not change by pressing A/B/Y, instead you get a higher max speed.
• Max speeds:
  • Dpad movement, Cardinal: ~0.9px/f
  • Dpad movement, Diagonal: ~0.65px/f
  • Mash A/B/Y, Cardinal: 1.5px/f
  • Mash A/B/Y, Diagonal: 1px/f
• Since pressing A/B/Y doesn't change how fast you get to ~0.9px/f, you should wait until you've hit the normal max speed (0.9px/f) before starting to mash. That way you will stay longer at the higher max speed before having to mash again.

Worst case (pressing A right after pressing dpad from a standstill) you only spend 1f on 1.5px/f. It takes around 31f from a standstill to reach 0.9px/f.

• After reaching absolute max speed (1.5px/f) and it starts decelerating back to 0.9px/f, repressing A/B/Y works weirldy: If you press it at 23/16 pixels per frame, you get back up at 24/16 (or 1.5px/f). But if you press it at e.g. 21/16 pixels per frame, the next max speed will be 22/16 (1.375px/f). Basically it rounds up to the next even sixteenth.

Worst case, if you let Link deaccelerate for ~12f before repressing A/B/Y you will be stuck with a max speed of ~1px/f for a while, until it deaccelerates down to 0.9px/f again.

So there's multiple reasons to mash as fast as you can when swimming (or time it).