Anonymous user
Luck manipulation (Generation I): Difference between revisions
→Overworld: I think I meant "step" instead of "frame".
>Bbbbbbbbba (Added hard-reset manipulations. I guess this article is getting too long for first time readers... Cleanup is welcome.) |
(→Overworld: I think I meant "step" instead of "frame".) |
||
| (2 intermediate revisions by 2 users not shown) | |||
Line 24:
At the very beginning of the game's startup process (before the copyright screen), hRandomAdd ($FFD3) and hRandomSub ($FFD4) are zeroed with the entire HRAM; apart from that, Random_ is the only place in the code that directly changes them. If the exact timings and circumstances (actually only the carry flag matters) of those calls can be predicted (e.g. in a TAS or shortly after a hard reset), then the results can be predicted too. That's the principle behind luck manipulation.
==Advancement of the RNG==
Usually, the RNG is advanced (i.e. Random_ is called) whenever a random number is needed. In addition, it is also advanced once per frame during the V-Blank interrupt. Since the game doesn't need random numbers very often, the majority of RNG advancements come from the V-Blank.
Line 34:
==DSum manipulation==
Two factors cause the DSum to change:
Line 45:
* A change of rDIV between the two reads is comparatively rare, and doesn't affect the DSum much. <!-- TODO: Estimation of frequency? -->
In summary, '''the DSum decreases in the overworld, and increases during a battle, by about 0.5
===Application===
Line 56:
|-
|
{| class="wikitable"
! Encounter slot !! hRandomSub Range
|-
Line 109 ⟶ 108:
===Overworld===
This is the main component of most manipulations. For the purpose of keeping up frame-perfect inputs, the player should be constantly walking, which also manipulates the RNG slightly compared to staying put. At the beginning of each step, the tilemap is updated so that the new row or column that appears on the screen is displayed properly, which delays the framely RNG advancement slightly. The time delta is either 8.1875 (row) or 7.984375 (column) rDIV periods, so a step generally adds 8 to the RNG state (for one time only), but it can be either 9 or 7 depending on the frame on which this happens. Plus, at the end of each
Another main factor that affects overworld RNG is sprites. The running time of PrepareOAMData depends on how many sprites are visible on the screen (and some static properties of them), which affects the framely RNG advancement. In addition, for sprites currently on screen, the RNG is called to determine the direction the sprite would walk in (even if it cannot actually walk), and the delay until the next movement. This cycle begins when the sprite is first loaded on screen. Notice that the movement state of sprites persists when it becomes off-screen and even after saving and resetting, as long as the player doesn't leave the map. Therefore all manipulations assume that all sprites involved are initially unloaded.
Line 135 ⟶ 134:
#[http://wiki.pokemonspeedruns.com/index.php/Pok%C3%A9mon_Red/Blue/Yellow_DSum_Manipulation DSum manipulation FAQ on Pokémon Speedruns wiki]
#[https://github.com/pret/pokered/blob/6ba3765c5932996f5da6417ae703794ff10bb1cb/engine/random.asm random.asm]
[[Category:Non-glitch exploits]]
| |||