User Tools

Site Tools


return_of_samus:technical_information:screen_transitions

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
return_of_samus:technical_information:screen_transitions [2023/05/29 20:51] rt-55jreturn_of_samus:technical_information:screen_transitions [2023/07/02 17:36] (current) – [B* - Load Graphics Page] rt-55j
Line 1: Line 1:
 ====== Screen Transitions ====== ====== Screen Transitions ======
-{{..:data_locations:rosamus.png | MII Samus}} Here we shall discuss how to dissect these pesky screen transitions, hopefully once and for allIt is advised that you first read the page on [[return_of_samus:technical_information:level_data_banks |Level Data Banks]] before continuing on.+{{..:data_locations:rosamus.png | MII Samus}} Screen transitions (sometimes referred to as "doors") in Metroid II use a bytecode interpreter to perform the various actions needed when moving between different rooms, such as changing the tileset, activating a fadeout, and so forthA basic knowledge of the screen transition bytecode language and how to easily edit it are essential skills for making more elaborate hacks of this game.
  
-Now, as discussed on the previously linked page, every screen has a screen transition index assigned to it. The index refers to a pointer table that starts at 0x142E5 in the ROM. These pointers point to scripts that define the transition's behavior. The scripting "language" used in these transitions will be described below.+It is recommended that you have a basic understanding of [[return_of_samus:technical_information:level_data_banks |Level Data Banks]] before continuing on.
  
-===== The Language =====+===== Internal Workings =====
  
-Once the game identifies the script to use, it copies it to $D700 in RAM (which is the easiest place to inspect how they work)From there, it interprets the script byte by byte in a big loop.+Each screen on each map has a screen transition index associated with it. As long as the index is not zero, the screen transition corresponding to the room will be activated once Samus touches any edge of the screen(The pointer table indexed by the transition number starts at 0x142E5 in rom.)
  
-First it checks if it has reached the terminating operator ($FF), and exits if that'the caseAfter that, it masks the right nybble of the current byte (e.g. $B2 becomes $B0), and then goes through the low-level equivalent of a switch statement (or rathera bunch of if-else statements) to find the routine that matches the operator. After processing the operator's operands, the interpreter loops back to the beginning, where it processes the next operand.+Once the game identifies the script to use, it copies the next $40 bytes to ''$D700'' in RAM (which is the easiest place to inspect how they work)From there, it interprets the script byte-by-byte in a big loop. (Note that this means the //maximum// effective size of a door script is 64 (0x40) bytesbut you will probably never hit that limit.)
  
-Scripts are limited to 64 (0x40bytes in lengthbut you'll literally never hit that limit.+The interpreter first checks if it has reached the end of the script ($FF), and exits if that is the case. After that, it masks out the lower nybble of the current byte (e.g. $B2 becomes $B0), and then proceeds through a bunch of if-else statements to find the routine that matches the upper nybble (the "B" in $B2, for example), and then executes the command. After executing the command, the interpreter loops back to the beginning and repeats the process for the next operation.
  
 (Note that all 16-bit values (pointers, etc.) are assumed to be little-endian, as usual.) (Note that all 16-bit values (pointers, etc.) are assumed to be little-endian, as usual.)
 +
 +===== Tokens/Operators =====
 +
 +Here is a list of valid tokens/operators used by the bytecode interpreter
  
 ==== FF - Terminating Operator ==== ==== FF - Terminating Operator ====
Line 22: Line 26:
 Copies a block of data starting at a specified bank and address to somewhere in RAM. Copies a block of data starting at a specified bank and address to somewhere in RAM.
  
-Cases:+Syntax:
  
-   * 01 bb ssss dddd llll - Saves bb:ssss as the source of a BG tileset (necessary for saving properly+   ''01 bb ssss dddd llll'' - Saves bb:ssss as the source of a BG tileset (meaning the tiles will be loaded when reloading a save
-   * 02 bb ssss dddd llll - Saves ssss as the source of a sprite tileset (necessary for saving properly+   ''02 bb ssss dddd llll'' - Saves ssss as the source of a sprite tileset (meaning the tiles will be loaded when reloading a save
-   * 0* bb ssss dddd llll - Just copies the data.+   ''0* bb ssss dddd llll'' - Just copies the data.
  
 Operands: Operands:
Line 40: Line 44:
  
 Copies the desired metatile table to $DA00-$DBFF in WRAM. Copies the desired metatile table to $DA00-$DBFF in WRAM.
- 
-The metatile table pointer list begins at 0x23F1A in ROM. 
  
 <code> <code>
Line 56: Line 58:
 </code> </code>
  
-(For some reason, these pointers slightly out of order compared to how the data is stored in the rom.)+The lava caves adjust their lava levels by changing their metatiles to sets with more or fewer lava tiles during door transitions. 
 + 
 +The metatile table pointer list begins at ''0x23F1A'' in ROM. (For some reason, these pointers slightly out of order compared to how the data is stored in the rom.) 
 ==== 2x - Select collision table ==== ==== 2x - Select collision table ====
  
 Copies the desired collision table to $DC00-$DCFF in WRAM. Copies the desired collision table to $DC00-$DCFF in WRAM.
- 
-The collision table pointer list begins at 0x23EEA in ROM. 
  
 <code>Collision Tables <code>Collision Tables
Line 72: Line 75:
 6 - ruinsExt 6 - ruinsExt
 7 - finalLab</code> 7 - finalLab</code>
-==== 3x - Select solidity indexes ====  
  
-Copies the desired solidity indexes to WRAM.+The collision table pointer list begins at 0x23EEA in ROM.
  
-The solidity indexes are stored in a table starting at 0x23EFA. Each entry row is four bytes wide, though only three are used.+==== 3x - Select solidity indexes ==== 
  
-The bytes are copied to these locations: +Copies the desired solidity indexes to WRAM, for Samus, enemies, and Samus' projectiles.
- +
-   * $D056 & $D812 - Samus' solidity index +
-   * $D056 & $D813 - Enemy solidity index +
-   * $D08A & $D814 - Projectile solidity index+
  
-Basically, for Samus, the way it works is that if an 8x8 tile is less than the specified index, then it is treated as a solid. It works the same for enemies and projectiles as well.+Basically, the way it works is that if an 8x8 tile is less than the specified index, then it is treated as a solid. While Samus, enemiesand projectiles may use different values, the process remains the same.
  
 <code>Solidity Values <code>Solidity Values
Line 97: Line 95:
  
 Note that (by default) these match up perfectly with the collision values previously. Note that (by default) these match up perfectly with the collision values previously.
 +
 +The solidity indexes are stored in a table starting at 0x23EFA. Each entry row is four bytes wide, though only three are used.
 +
 +The bytes are copied to these locations:
 +
 +   * $D056 & $D812 - Samus' solidity index
 +   * $D056 & $D813 - Enemy solidity index
 +   * $D08A & $D814 - Projectile solidity index
 +
 ==== 4* - Warp ==== ==== 4* - Warp ====
  
 Warps Samus to the specified map and screen. Warps Samus to the specified map and screen.
  
-Form4byx+Syntax''4b yx''
  
 Operands: Operands:
Line 121: Line 128:
 ==== 6* - Change acid & spike damage ==== ==== 6* - Change acid & spike damage ====
  
-Form: 6* xx yy+Syntax''6* xx yy''
  
 Operands: Operands:
Line 128: Line 135:
    * yy - spike damage    * yy - spike damage
  
-I'm not sure if this is ever used, but it's cool at least.+This is used towards the end of the game to increase the acid damage from $02 to $06.
  
-For reference, the default starting values are $02 and $08.+For reference, the default starting values are $02 and $08. (Note that damage values for Samus in this game are binary-coded decimal.)
  
 ==== 7* - Exit Room After Last Boss Death ==== ==== 7* - Exit Room After Last Boss Death ====
Line 139: Line 146:
   - Disables LCD interrupt from last boss fight   - Disables LCD interrupt from last boss fight
   - Reloads the status bar into the window   - Reloads the status bar into the window
 +
 ==== 8* - Transition to the Queen Fight ==== ==== 8* - Transition to the Queen Fight ====
  
 Handles a lot of special stuff regarding the queen fight, but not everything. Handles a lot of special stuff regarding the queen fight, but not everything.
  
-Form: 8a bbbb cccc dddd eeee+Form: ''8a bbbb cccc dddd eeee''
   * a: Bank for current room ($F)   * a: Bank for current room ($F)
   * b: Scroll Y position ($F48)   * b: Scroll Y position ($F48)
Line 149: Line 157:
   * d: Samus Y position ($F02)   * d: Samus Y position ($F02)
   * e: Samus X position ($EDE)   * e: Samus X position ($EDE)
 +
 ==== 9* - Conditional Operator ==== ==== 9* - Conditional Operator ====
  
-Form: 9* nn xxxx+Syntax''9* nn xxxx''
  
 Operands: Operands:
Line 171: Line 180:
  
 Forms: Forms:
-   - B1 bb xxxx - Load BG graphics page (128 tiles) to $9000 in VRAM. +   ''B1 bb xxxx'' - Load BG graphics page (128 tiles) to $9000 in VRAM. 
-   - B2 bb xxxx - Load Sprite graphics page (64 tiles) to $8B00 in VRAM.+   ''B2 bb xxxx'' - Load Sprite graphics page (64 tiles) to $8B00 in VRAM
 + 
 +Note that these opcodes update the variables that keep track of what tilesets to use when loading a save.
  
 Operators: Operators:
Line 274: Line 285:
 For reference, the macros the disassembly uses are as follows: For reference, the macros the disassembly uses are as follows:
  
-Opcode Macro |+Opcode Macro ^
 | 00 bb ssss dddd llll | COPY_DATA | | 00 bb ssss dddd llll | COPY_DATA |
 | 01 bb ssss dddd llll | COPY_BG | | 01 bb ssss dddd llll | COPY_BG |
return_of_samus/technical_information/screen_transitions.1685393510.txt.gz · Last modified: 2023/05/29 20:51 by rt-55j