Pages: 1
|
|
Posted on 10-03-15, 10:52 pm (rev. 3 by
|
|
☭ coffee and cream
 Karma: 10415 Posts: 1789/2768 Since: 06-26-11 |
just aiming at documenting that junk more properly
IDs in block2/3/4 do matter setupBgParallax accesses header block3, reads from the right entry (getUnk2ForView) reads the tilemap ID setupStuffForPlayer accesses block2 (getUnk1ForView) and block4 (getUnk3ForView) reads X scroll and Y scroll sub_20AEDA0 accesses block2 reads tilemap ID and unknown at 0xE and Yscroll sub_20BAA2C accesses block2 reads tilemap ID seems to choose jyotyu palette?? sub_20AE4AC accesses block4 reads tilemap ID and unk 0xE and Yscroll levelActor_loadNSCs accesses block4 reads Yscroll (??) loadNCGs tileset IDs are taken from block0, area settings ignored (offsets fixed) FG tileset ID is stored by 020B02AC, called by Class20c940c::onCreate which does all the tileset init (and also calls loadNCGs later) levelActor_loadNCLs loads palette IDs from block2/3/4, selects first block (area settings ignored) levelActor_loadNSCs loads tilemap IDs from block2/4 (and also reads Yscroll??), repeats for each block entry (but loads at the same place every time!!) sub_20BAA2C gets jyotyu palette #, does it right (reads area data / getUnk1ForView/getBlock2PointerById) called by loadSomeCrapPalettes StageScene_setupCrap: called when entering any area, responsible for reloading palettes (among other things) _________________________ Kuribo64 - zrghij |
|
|
Posted on 10-03-15, 11:03 pm
|
|
☭ coffee and cream
Karma: 10415 Posts: 1790/2768 Since: 06-26-11 |
|
|
Posted on 10-04-15, 12:25 am (rev. 6 by
|
|
☭ coffee and cream
Karma: 10415 Posts: 1791/2768 Since: 06-26-11 |
who is responsible for loading palettes:
when loading a level/area: StageScene_setupCrap when switching views: sub_211870C when loading a level: palettes are loaded before the rest StageScene_setupCrap is called before Class20c940c::onCreate both called from initStuff or initLotsaThings it only reloads the jyotyu palettes when switching views; code to reload graphics is missing maybe you were supposed to have one big tileset and multiple tilemaps referring to it, although where said tilemaps would have gone is a mystery (and sounds wasteful) BG tilemaps get offsets depending on the slot # selected by the view params: (they AND the ID with 3 and then check if it's <= 5. what the fuck, Nintendo) bottomBG: 0: 0x18 (0x0601C000) 1: 0x1C (0x0601E000) 2: 0x1C 3: 0x18 4: 0x1C 5: 0x1C anything else: 0x18 topBG: 0: 0x14 (0x0601A000) 1: 0x1C (0x0601E000) 2: 0x1C 3: 0x14 4: 0x1C 5: 0x1C anything else: 0x14 global screen base is at 0x06010000 notice the conflicts between topBG and bottomBG for values >0, both land at the same place. Hinting that either the VRAM layout was different, or this is experimental and was never finished. 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) oh and while we're at it, ext. palettes in slot2: 0-1: Jyotyu 2-5: level tileset 6-7: end-castle 8-9: shrug 10-14: empty(?) 15: some little thing for silver coins maybe the same VRAM layout was used and this was actually limited, ie: * load two Nohara BGs + one underground BG, taking up all the tilemap slots * load all needed tilesets together (no end-castle tileset -> more free space to load tilesets. TODO check out where those would land) * same goes for palettes? but then the palette IDs predefined in Map16 become a problem. either a) correct them when loading tilesets or b) have tilesets all preset to work together. Looks more like b). or we just happened to lose the code that loaded new graphics when switching views (if not gonna use it, why keep something that slows things down?) more like that; even if you remove the end-castle tileset, there isn't enough space in this VRAM layout to fit more tilesets (unless they're all packed together) _________________________ Kuribo64 - zrghij |
|
|
Posted on 10-04-15, 03:11 am
|
|
☭ coffee and cream
Karma: 10415 Posts: 1792/2768 Since: 06-26-11 |
unused level 3: view 2 (the underground room) has bottomBG and FG blocks set to 1, topBG 0
block2 has the following BGs: 0 -> 0300 0000 1 -> 0403 FFFF block3: 0 -> 0000 0000 1 -> 0000 FFFF block4: 0 -> FFFF 0000 block0: bottom BG tileset: 0000 0003 FFFF FG tileset: 0000 0003 FFFF top BG tileset: 0000 FFFF FFFF it appears there was a mechanism for selecting different tilesets tilemap/etc IDs also look wrong, appears the structure was different back then _________________________ Kuribo64 - zrghij |
| Asprok |
Posted on 10-04-15, 05:11 pm
|
|
I Am Not Inteligent
Karma: 979 Posts: 92/380 Since: 03-04-14 |
I don't actually understand any of this, but I see you are REALLY into this. All of this will help a lot in level designing. I believe there'll be no limitation of tileset using in an area, if this is the motive of the research. It's very interesting how Nintendo coded this and left it out from the original release. And I needed to post this 'cause it seemed like nobody supported this. REALLY GOOD JOB, man. Thanks for the investigation.
I could not… |
|
|
Posted on 10-04-15, 05:12 pm
|
 Birdo Karma: 2754 Posts: 1466/2091 Since: 06-26-11 |
Its only useful if it can be fixed. It is interesting though.
|
|
|
Posted on 10-04-15, 05:17 pm
|
|
☭ coffee and cream
Karma: 10415 Posts: 1793/2768 Since: 06-26-11 |
Pages: 1