This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
return_of_samus:technical_information:level_data_banks [2015/05/01 03:21] – [Scroll Pointers] rt-55j | return_of_samus:technical_information:level_data_banks [2016/07/18 12:53] – [Screen Transitions Indexes] zero_one | ||
---|---|---|---|
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. | ||
- | ==== MAGIC! (also known as fucking god damnit transitions) | + | |
- | Fuck this.. | + | ==== Screen Transitions Indexes |
+ | The next 0x200 (dec: 512) bytes form another 16x16 array of little-endian two-byte values. They serve two functions: | ||
+ | |||
+ | - One of the bits of the value (bin: | ||
+ | - 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: | ||
===== Level Data Chunks ===== | ===== Level Data Chunks ===== | ||
I know how this works, but I gotta write it down first. | I know how this works, but I gotta write it down first. |