Jump to content

Glitch City RAM manipulation (buffer overflow techniques): Difference between revisions

no edit summary
(Created page with "Combining the data of a Glitch City sourced from RAM with a buffer overflow technique that depends on the contents of the screen (or a related screen buffer) allows the player to have more control over the desired corruption; because the RAM is not fixed and is writable during gameplay. For example, a form of Glitch City RAM manipulation is used during oobLG. In Yellow, this is with the help of 6F (a screen-saving glitch item), a Glitch City ([...")
 
No edit summary
Line 1:
Combining the data of a [[Glitch City]] sourced from RAM with a buffer overflow technique that depends on the contents of the screen (or a related screen buffer) allows the player to have more control over the desired corruption; because the [[RAM]] is not fixed and is writable during gameplay.
 
For example, a form of Glitch City RAM manipulation is used during [[oobLG]]. In Yellow, this is with the help of [[ItemDex/Y:091|6F]] (a screen-saving glitch item), a Glitch City ([[Expanded bag item documentation (Generation I)|with manipulation of the top-left block pointer D35E/D36F to a RAM pointer]]) and an [[Unterminated name Pokémon (Generation I)|unterminated name Pokémon]]. For one method in Yellow, bag item 14's quantity (in RAM) becomes the Pokémon encounter. In the [[blockoobLG]] it is the quantity of item 23 that defines a block on the screen; based on the sub-tiles of the block, and the contents of y=0C, x=0A defines the Pokémon in the screen buffer.
 
Though Glitch City RAM manipulation has its benefits, there may still be some limitations.
Cookies help us deliver our services. By using our services, you agree to our use of cookies.