Revision (current)
Last Updated by adelikat on 9/2/2023 2:59 PM
!!Useful addresses
||Addr||Size||What||
|004C|2 bytes|Camera X (screen position)|
|004E|2 bytes|Camera Y|
|005A|1 byte|Volatile controller-based RNG|
|005B|2 bytes|Bit shifting RNG (big endian)|
|005D|2 bytes|Frame timer|
|00C6|2 bytes|Fuel remaining|
|00C8|2 bytes|Weapon power remaining|
|0374|1 byte|Player facing|
|0336|1 byte|Player X speed direction (0=right, 1=left)|
|029B(lo) 02BA(hi)|2 bytes|Player X speed|
|0200(lo) 021F(hi)|2 bytes|Player X pixel position|
|0197|1 byte|Player X sub-pixel|
|0355|1 byte|Player Y speed direction (0=up, 1=down)|
|02D9(lo) 02F8(hi)|2 bytes|Player Y speed|
|025D(lo) 027C(hi)|2 bytes|Player Y pixel position|
|023E|1 byte|Player Y sub-pixel|
!!Movement
||What||Max p/f||Up||Down||Left||Right||
|Thrust|3.0|Angles 24 to 31, 0 to 8|Angles 8 to 24|Angles 17 to 31|Angles 1 to 15|
|Gravity|3.0|Inverted gravity|Normal gravity| | |
|Object swing|4.0| | | | |
The pod's maximum speed is 4.0 pixels per frame. This can only be done by tethering an object and having it pull you along. If your thrusters or the gravity attempt to accelerate the pod in the same axis, it will instantly reduce the speed to a maximum of 3.0 if the pod is traveling faster.
! Thrust
Thrusting enforces a maximum speed of 3.0 pixels/frame.
The default thrusters accelerate an unburdened pod at 16, when facing straight into some direction. Carrying an object will cut this acceleration by varying amounts depending on object mass.
Thrusting straight right (direction 8) or straight left (direction 24) will count some thrusting force upward, and will prevent reaching
Basic thrusting with default thrust or Double Strength Thrusters take 2 fuel per frame, or 16 fuel when using boosters. Efficient Engines reduce the costs to 1 or 8 fuel per frame, respectively.
! Gravity
Gravity enforces a maximum downward (or upward, if reverse) speed of 3.0 pixels/frame. Even zero gravity is counted as downward with zero acceleration, and will enforce the downward maximum.
Gravity usually pulls the pod down at a constant rate, depending on the planet. There may be areas on a planet submerged under a fluid of sorts. The only affect of entering one such fluid is a change in the acceleration of gravity. There's still no friction.
Anti-Gravity completely shuts off gravity when active. Downward acceleration, speed maximum, and tethered object will not be affected by gravity with this item in use.
! Angles
The pod can face 32 different directions.
Straight left (24) or straight right (8) is still counted as a thrust upwards of usually zero acceleration. If you desire to travel faster than 3.0 pixels/frame going up, avoid thrusting in these directions.
Straight down (16) or straight up (0) is not counted as thrusting either left or right. There will be no interference for horizontal momentum that exceeds 3.0 pixels/frame.
! Tethered objects
Tethered objects are impacted by gravity in an intuitive way. By accelerating in the opposite direction of the motion of a tethered object, player actions can also help increase the tethering speed. The faster the tethering speed and the heavier the object, the more it influences/accelerates the player's speed. Generally speaking, this is again done in an intuitive way. But please note that there are oddities in how the game calculates the resulting pod speed. For example, continuously thrusting in the opposite direction of the movement of the tethered object will not necessarily result in generating the most speed. Some thrusts have more impact for the speed than others. And some thrusts even have a negative impact on the speed, even though they intuitively should instead be contributing. The underlying mechanics have not been investigated in further details, but are important to take into account when TASing, even if it's only in the form of playing around with inputs by "trial-and-error".
So for example, when travelling to the right, a tethered object will accelerate the player when moving in front of the pod (doesn't matter if the object is moving clockwise or anti-clockwise around the pod), up to a speed of 4p/f. Once the tethered object crosses the vertical line of the pod to the left side, it will start to decelerate the player. If the object comes to rest, it will no longer impact the pod's speed, even if it's off-center with respect to the pod. This speed-up mechanic is significantly more efficient when traveling to the left than when traveling to the right. The reason for this has not been investigated.
Vertical motion is impacted by tethered objects in a similar way as horizontal motion. The main difference being that the gravity fields of the planets prevent the pod from speeding up above 3p/f (not applicable to large wormholes!). This limitation can be bypassed by activating the "anti-gravity" upgrade. To speed up for example downward movement, place the tethered object above the horizontal centerline (or below in an inverted gravity field), the higher the better, and let it freely fall down. When it's about to pass the centerline, ensure the pod's y-speed is already 3p/f and activate anti-gravity. While the object swings below the pod, it will accelerate the pod up to a vertical speed of 4p/f.
! The RNG
||005A|1 byte|Volatile controller-based RNG|
||005B|2 bytes|Bit shifting RNG (big endian)|
The value at address {{005A}} is affected by the following:
||0018| Player 1 immediate - Exact mirror of controller state|
||0019| Player 1 pressed - Bits are set if pressed now, but not held before|
||001A| Player 2 immediate|
||001B| Player 2 pressed|
||005D| Frame timer low-byte|
||005E| Frame timer high-byte|
||005F| Always zero?|
||0060| Looks like address {{005D}} MOD 8|
The thing that matters is the fact {{005A}} is affected by direct controller input. This includes Player 2, which has no effect anywhere else in the game. By using Player 2, it is possible to gain very strong control over how the RNG works.
The values at address {{005B}} and {{005C}} are left-shifted every frame. The bit shifted into {{005C}} is an XOR of bits 0x40 and 0x08 from {{005A}}, although it has been observed to, on rare occasion, shift in an opposite of this bit. The bit shifted out of {{005C}} is shifted into {{005B}}, and the bit shifted out of 005B is thrown away.
Since {{005B}} and {{005C}} are affected by what happens with {{005A}}, and {{005A}} is affected by controller input, this means you should have complete control over the RNG.
During game play, you have control every other frame, but the RNG runs every frame. As the RNG "ticks" twice for every frame you have control, this makes it somewhat difficult to set the RNG perfectly.
All three RNG addresses are used for various random events.
! Final boss
||038B-038F| Eye aperture states|
||0419-041D| Eye timers|
||0439-043D| Eye opening sequences|
||0458-045C| Eye health|
||0460-0464| Eye states|
The top eye can be despawned during the auto-scroller, well before the actual boss fight begins. This can be seen by monitoring the eye state address $0461. At the time of writing, the best description for what happens is found here: [Forum/Posts/367718] . There have been no reports of additional eyes being despawned (or other eyes than the one at the top). The bot 'Jaffar', created by TASer 'eien86', was able to quickly find solutions that despawned the top eye, but did not find any other variants.
When the window gets "close enough" to the boss, the eye timers get initialized one-by-one to 0 and will then start ticking up every 8 frames. This appears to be programmed in a set pattern, meaning the start order of the eye openings is always the same. Note that small variations have been observed, so there appears to be a little room for manipulation in the timing of the first eye openings, but this has not been investigated in detail.
When an eye timer reaches 0x20, the game will branch at instruction $C08C to the piece of code for the eye opening sequence. The sequence is split in 8 segments, each consisting of 8 frames. The first and last consist of the eye being half-open (and not vulnerable). When the eye opening sequence begins, the game will also re-initialize the timer for the next phase. This is done by comparing one of the RNG-addresses and 0x1F. The result is written to the timer and becomes its new start value. The eyes with index 0, 2 and 4 use $5B for this and the eyes with index 1 and 3 use $5A. Since the RNG-addresses can be manipulated (see section above), the player has control over all eye openings at any time, except for the first cycle as explained above.