This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
return_of_samus:technical_information:level_data_banks [2015/05/01 03:30] – [MAGIC!] rt-55j | return_of_samus:technical_information:level_data_banks [2022/04/28 05:22] (current) – [Screen Transitions Indexes] rt-55j | ||
---|---|---|---|
Line 2: | Line 2: | ||
{{..: | {{..: | ||
- | Metroid II has 7 banks dedicated to level data and they all follow the same format. An 0x500 byte header, and the remaining 0x3500 bytes for level data chunks. | + | Metroid II has 7 banks dedicated to level data and they all follow the same format. An 0x500 (dec: 1, |
===== Bank Header ===== | ===== Bank Header ===== | ||
==== Level Data Pointers ==== | ==== Level Data Pointers ==== | ||
- | The first 0x200 bytes of the bank header deal with creating the actual layout of the room, you can think of Metroid II as having 7 huge 16x16 rooms, with smaller rooms that have been fitted into it Tetris style. | + | The first 0x200 (dec: 512) bytes of the bank header deal with creating the actual layout of the room, you can think of Metroid II as having 7 huge 16x16 rooms, with smaller rooms that have been fitted into it Tetris style. |
- | There are 256 2 byte pointers (reversed) which point to the Level Data Chunks inside the same bank, if we look at [[..: | + | There are 256 2 byte pointers (little-endian (i.e. reversed)) which point to the Level Data Chunks inside the same bank, if we look at [[..: |
< | < | ||
00 4F | 00 7E | 00 7E | 00 62 | 00 45 | 00 45 | 00 45 | 00 4F | 00 4F | 00 7E | 00 7E | 00 62 | 00 45 | 00 45 | 00 45 | 00 4F | ||
Line 48: | Line 48: | ||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||
</ | </ | ||
- | In theory, this means you could probably make a 16x16 room in Metroid II, I have not tested this yet, as thats a fair bit of editing but I will when I got more time, it looks like adding in more rooms is as simple as creating more of these level banks. | + | In theory, this means you could probably make a 16x16 room in Metroid II, I have not tested this yet, as that' |
==== Scroll Pointers ==== | ==== Scroll Pointers ==== | ||
- | The next 0x100 bytes are scroll types, each byte corresponds with a screen and dictates how the scrolling works on that screen. | + | The next 0x100 (dec: 256) bytes are scroll types, each byte corresponds with a screen and dictates how the scrolling works on that screen. |
In binary, each byte is formatted like this: | In binary, each byte is formatted like this: | ||
Line 87: | Line 87: | ||
</ | </ | ||
Say you had a hallway like this and wanted to make a transition between the two rooms, you would need to set screen 01 to 0D and 02 to 0E, when Samus moves to the edge of 02, the game will scroll samus into 01 in a room transition style. | Say you had a hallway like this and wanted to make a transition between the two rooms, you would need to set screen 01 to 0D and 02 to 0E, when Samus moves to the edge of 02, the game will scroll samus into 01 in a room transition style. | ||
+ | |||
==== Screen Transitions Indexes ==== | ==== Screen Transitions Indexes ==== | ||
- | The next 0x200 bytes form another 16x16 array of two byte values. They serve two functions: | + | The next 0x200 (dec: 512) bytes form another 16x16 array of little-endian |
+ | |||
+ | - The twelfth bit of the value (set/ | ||
+ | - The value itself specifies the screen transition number that the screen uses. The data that governs what each screen transition does is located in bank 5. | ||
+ | |||
+ | For more information on how the transition data works, see [[return_of_samus: | ||
- | - They are (byte-swapped) indexes to a pointer table that begins at the ROM address 0x142E5 (in Bank 5). These pointers refer to the actual data that governs screen transitions, | ||
- | - One of the bits of the value (bin: | ||
===== Level Data Chunks ===== | ===== Level Data Chunks ===== | ||
- | I know how this works, but I gotta write it down first. | + | the next 0x5900 (dec: 15104) bytes are the 59 level data chunks. each chunk is 16x16 bytes. each byte is one tile, and they are orginized 100% linearly. take the final chunk for example (which is, ironically, the first screen you ever see): |
+ | < | ||
+ | 7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f | ||
+ | 7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f | ||
+ | 7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f | ||
+ | 7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f | ||
+ | 7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f | ||
+ | 7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f | ||
+ | 7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f | ||
+ | 7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f | ||
+ | 7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f | ||
+ | 3c|0c|0d|0e|0f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f | ||
+ | 15|16|17|12|18|19|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f | ||
+ | 20|21|22|23|24|25|26|7f|7f|7f|7f|7f|7f|7f|7f|7f | ||
+ | 2d|2e|2f|30|31|32|33|7f|7f|7f|7f|7f|7f|7f|7f|7f | ||
+ | 37|05|06|07|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f|7f | ||
+ | 7f|7f|7f|7f|7f|7f|7f|76|7f|71|70|74|73|76|70|7f | ||
+ | 39|39|39|39|39|39|39|39|39|39|39|39|39|39|39|39 | ||
+ | </ | ||
+ | all you really need to know to understand what I mean is that 7f is air tiles, and 39 is ground tiles. if you DO want to have a breakdown of tiles hex values, see [[return_of_samus: |