Pages: 1
|
|
Posted on 05-29-25, 10:51 am
|
|
☭ coffee and cream
Karma: 10622 Posts: 2796/2818 Since: 06-26-11 |
3 is blue
anyway I randomly got some interest in this again, and wondered if I could get this working in a production level - for reference: https://nsmbhd.net/thread/3157-multibg-ii-the-return/ - what we know so far: * unused level 3 uses this * it's broken af * structure for BG info block was somewhat different at the time VRAM layout: 0x06000000: Jyotyu tileset 0x06003000: level tileset 0x0600A000: end-castle tileset 0x0600C000: top BG tileset 0x06011000: bottom BG tileset 0x06018000: BG2 tilemap (FG) 0x0601A000: BG3 (top BG) 0x0601C000: BG1 (bottom BG) 0x0601E000: empty (space for the extra crap to land, apparently) now for pure speculation * secondary background tilemap would have been loaded at 0x0601E000. this would have allowed a simple, one-layer background (prolly sufficient for a small sub-area like in the unused level). * not clear where the tileset for said BG layer would have been loaded. maybe the different BG layers shared a same tileset. * the level tileset for the sub-area would have been loaded at 0x0600A000, where the end castle is loaded. - the code * the tilemap address for the BG layers is set based on which BG info block is active. 0x0601A000/0x0601C000 if the ID is 0 or 3, 0x0601E000 otherwise. * prior to that, the tilemaps are loaded -- the code goes through each BG info block and loads the associated tilemap. the issue is that they all get loaded at the same VRAM address (which is inferred from the current BGxCNT setting). * have not yet looked into level tilesets. _________________________ Kuribo64 - zrghij |
|
|
Posted on 05-29-25, 05:41 pm
|
|
☭ coffee and cream
Karma: 10622 Posts: 2797/2818 Since: 06-26-11 |
I'll post some info and wild speculation... nothing too new.
comparing the layouts of various level header blocks against a pretty normal level, 1-2. block0 (general shit)
unused3:
00 00 00 00 2C 01 00 00 03 00 FF FF 00 00 03 00 FF FF 00 00 FF FF FF FF 00 00 00 00 00 00 00 00
1-2:
00 03 00 00 90 01 03 00 FF FF FF FF 03 00 FF FF FF FF 03 00 FF FF FF FF 00 00 07 00 00 00 00 00
block2 (bottom BG)
unused3:
00 00 00 03 00 00 FF FF FF FF 03 00 07 00 00 00 00 00 00 00
01 00 03 04 FF FF 03 00 FF FF 00 00 04 00 00 00 00 00 00 00
1-2:
00 00 03 00 03 00 FF FF FF FF 02 00 02 00 00 00 00 00 00 00
block3 (FG/level)
unused3:
00 00 00 00 00 00 FF FF FF FF FF FF FF FF 00 00 00 00 00 00
01 00 00 00 FF FF 03 00 FF FF FF FF FF FF 00 00 00 00 00 00
1-2:
00 00 00 00 03 00 FF FF FF FF FF FF FF FF 00 00 00 00 00 00
block4 (top BG)
unused3:
00 00 FF FF 00 00 FF FF FF FF FF FF FF FF 00 00 00 00 00 00
1-2:
00 00 03 00 03 00 FF FF FF FF 01 00 01 00 00 00 00 00 00 00 so obviously, our unused level has two entries in block2 and block3. view parameters (unk1/unk2/unk3) determine which one to use (tho not all places use it). but also: block0 clearly has multiple tilesets defined for bottomBG and FG. the structure implies that each layer could have up to 3 tilesets loaded, although it's unclear how it would work and what the VRAM layout would be. possible it was limited in ways -- unused3 has no top BG defined. we observe a similar oddity in block2 and block3: in each, the second entry has the palette ID set to FFFF, which would skip loading a palette entirely. however, the next u16 is set to 0003, which suggests that there were more palette slots available (probably up to 3, too). then we also see something in the MSB of the tilemap ID: they are set to 0300 and 0403. the game code ignores the MSB. not sure what this is all about. this implies that the various BG layers involved would have to be made to work with a given VRAM layout in mind, or that there would be code for fixing tilemap entries as needed when loading graphics. there is code for setting the tilemap base address for BG layers based on which BG block is in use, but it doesn't set the tileset base address. I'm digging a bit in the code to see if I can find remnants of this multiBG stuff, because it's interesting. but there isn't a lot. the code for loading tilesets and palettes only loads the first entry. the code for loading tilemaps can load multiple, but they're all loaded to the same address, which defeats the point. _________________________ Kuribo64 - zrghij |
|
|
Posted on 05-30-25, 08:41 am
|
Fire SnakeEugene Karma: 3825 Posts: 1161/1163 Since: 11-29-11 |
By multiBG, do you mean having more layers than the current three (1 tileset for the ground, 1 for the top layer bg and 1 for the bottom layer bg)?
Or do you mean that different views in the same area could originally have different tileset graphics? Or something else? |
|
|
Posted on 06-01-25, 10:57 am
|
|
☭ coffee and cream
Karma: 10622 Posts: 2798/2818 Since: 06-26-11 |
|
|
Posted on 06-06-25, 08:04 pm
|
|
☭ coffee and cream
Karma: 10622 Posts: 2801/2818 Since: 06-26-11 |
was digging through old shit, and
https://nsmbhd.net/thread/991-multibackground-experiments/#14314 looked at level 3-A and I do notice that the tileset values are: 0030 0000 FFFF same goes for the palette entries in block 4: 0030 0000 FFFF I guess that's one oddity, but that level's palette stuff is unrelated to the multiBG stuff I think the game just knows that the tileset's palette file is bigger _________________________ Kuribo64 - zrghij |
|
|
Posted on 06-06-25, 11:56 pm
|
Nipper PlantI do things sometimes Karma: 1210 Posts: 388/416 Since: 08-07-17 |
Posted by Arisotura looked at level 3-A and I do notice that the tileset values are: 0030 0000 FFFF |
|
|
Posted on 06-07-25, 10:49 am
|
|
☭ coffee and cream
Karma: 10622 Posts: 2802/2818 Since: 06-26-11 |
Pages: 1
Fire Snake
Nipper Plant