Difference between revisions of "Subpixels"

From ALttP Speedrunning Wiki
Jump to: navigation, search
(Created page with "This is not 100% verified in code, but it describes what we see when frame advancing in emulator: * When the subpixel wraps, your movement speed gets a -1. * On normal groun...")
 
Line 1: Line 1:
 +
== Explanation on why the movement works as it does ==
 +
 
This is not 100% verified in code, but it describes what we see when frame advancing in emulator:
 
This is not 100% verified in code, but it describes what we see when frame advancing in emulator:
 +
 +
You can check this by looking at memory addresses 7E002A and 7E002B (subpixels) in emulator.
  
 
* When the subpixel wraps, your movement speed gets a -1.  
 
* When the subpixel wraps, your movement speed gets a -1.  
Line 27: Line 31:
 
* frame 3: Subpixel = 0x60 - 0x50 = 0x10. Doesn't wrap, so you get 1.
 
* frame 3: Subpixel = 0x60 - 0x50 = 0x10. Doesn't wrap, so you get 1.
 
* frame 4: Subpixel = 0x10 - 0x50 = 0xC0. Wraps, so you get 1 - 1 = 0.
 
* frame 4: Subpixel = 0x10 - 0x50 = 0xC0. Wraps, so you get 1 - 1 = 0.
 +
 +
== 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. We're not sure the exact rules, but it looks like different parts of the slope will give different pixel boosts.
 +
 +
Another factor is subpixels. Depending on what subpixel you have, you might or might not get an extra pixel boost at any point during the slope dash. This means that even if you start your dash from the exact same coordinate, the slopedash can go fast or slow depending on the subpixel value.
 +
 +
So you can make a save state during a transition, then test a slopedash to find the perfect pixel, but since your subpixel entering the screen was set to something specific, the position you found might not work the same in a run.
 +
 +
One way to make sure you get the same subpixel is to hit diagonal before starting the dash.

Revision as of 19:42, 11 January 2018

Explanation on why the movement works as it does

This is not 100% verified in code, but it describes what we see when frame advancing in emulator:

You can check this by looking at memory addresses 7E002A and 7E002B (subpixels) in emulator.

  • When the subpixel wraps, your movement speed gets a -1.
  • On normal ground, the default movement speed is 2.
  • On stairs, the default movement speed is 1.
  • Walking upwards increments subpixels, walking downwards decrements subpixels.

Example: Walking on ground (movement speed is 2), upwards

  • frame 1: Subpixel = 0x00 + 0x80 = 0x80. Doesn't wrap, so you get 2.
  • frame 2: Subpixel = 0x80 + 0x80 = 0x00. Wraps, so you get 2 - 1 = 1.
  • Repeats

Example: Walking on ground (movement speed is 2), downwards

  • frame 1: Subpixel = 0x00 - 0x80 = 0x80. Wraps, so you get 1.
  • frame 2: Subpixel = 0x80 - 0x80 = 0x00. Doesn't wrap, so you get 2.
  • Repeats

Example: Walking on stairs (movement speed is 1), upwards

  • frame 1: Subpixel = 0x00 + 0x50 = 0x50. Doesn't wrap, so you get 1.
  • frame 2: Subpixel = 0x50 + 0x50 = 0xA0. Doesn't wrap, so you get 1.
  • frame 3: Subpixel = 0xA0 + 0x50 = 0xF0. Doesn't wrap, so you get 1.
  • frame 4: Subpixel = 0xF0 + 0x50 = 0x40. Wraps, so you get 1 - 1 = 0.

Example: Walking on stairs (movement speed is 1), downwards

  • frame 1: Subpixel = 0x00 - 0x50 = 0xB0. Wraps, so you get 1 - 1 = 0.
  • frame 2: Subpixel = 0xB0 - 0x50 = 0x60. Doesn't wrap, so you get 1.
  • frame 3: Subpixel = 0x60 - 0x50 = 0x10. Doesn't wrap, so you get 1.
  • frame 4: Subpixel = 0x10 - 0x50 = 0xC0. Wraps, so you get 1 - 1 = 0.

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. We're not sure the exact rules, but it looks like different parts of the slope will give different pixel boosts.

Another factor is subpixels. Depending on what subpixel you have, you might or might not get an extra pixel boost at any point during the slope dash. This means that even if you start your dash from the exact same coordinate, the slopedash can go fast or slow depending on the subpixel value.

So you can make a save state during a transition, then test a slopedash to find the perfect pixel, but since your subpixel entering the screen was set to something specific, the position you found might not work the same in a run.

One way to make sure you get the same subpixel is to hit diagonal before starting the dash.