1. We aren't in 2015 yet.
2. You didn't make the game. You don't own it. Don't shit over Nintendo's copyright notice just to plaster your name over the thing.

Oh and you don't own Newer either. When you hack a game to remake another game, you really don't deserve to remove copyright notices or credits like that.
_________________________
Kuribo64 - RH-fucking-cafe - Kafuka

zrghij

blarg
_________________________
Kuribo64 - RH-fucking-cafe - Kafuka

zrghij

No shit like P-Switches and events either. Guess this shit is really only meant to let kids have some fun.


I'm still curious to see if it will fuel the ROM hacking scene, though.
_________________________
Kuribo64 - RH-fucking-cafe - Kafuka

zrghij

Why are you asking for credit when all you did was replace textures with other textures you found from other games?
_________________________
Kuribo64 - RH-fucking-cafe - Kafuka

zrghij

nikos, calm down.

Thierry, you're not a moderator, so don't act like one.


Thank you.
_________________________
Kuribo64 - RH-fucking-cafe - Kafuka

zrghij

This thread will meet the same fate as the K64 one I'm afraid. The whole 'BlargBoard XD' adventure looks like a bunch of preschoolers trying to build a rocketship out of a bus.
_________________________
Kuribo64 - RH-fucking-cafe - Kafuka

zrghij

omg Dirbaio I will have to ban you for backseat modding Tierage's self backseat modding

oh wait
_________________________
Kuribo64 - RH-fucking-cafe - Kafuka

zrghij

Did you know that you two just gave out your secret anti-CSRF keys?


(changing your passwords will reset them, even if you enter the same password again)
_________________________
Kuribo64 - RH-fucking-cafe - Kafuka

zrghij

Interesting that this shit is finally somewhat possible.


I dislike that you took so long to release the documents, though. Even if as you say, "50% of the board won't be able to understand it", the remaining 50% could make good use of it. You look like you're just hiding the information so you can be the ones who come up with the amazing tool and get all the fame.

Maybe I'm wrong, but I'd much rather have gotten the documentations much earlier, even in a messy state. You see, releasing documentation isn't about "hey look, we have nice clean documentation noone else has, we're the best", it's about helping the community move forward. Just look at my finding dump threads. They're far from organized or anything, but they'll be useful to anyone with enough knowledge.

There is no point in keeping information for yourselves other than making yourselves look like some NSMB hacking messiah.


But either way, great job.


Is it also possible to add more levels, paths and whatnot? From what I remember, that was stored in overlays and it was a pain to add more.
_________________________
Kuribo64 - RH-fucking-cafe - Kafuka

zrghij

Thank you for showing us that you can do math.
_________________________
Kuribo64 - RH-fucking-cafe - Kafuka

zrghij

We don't care how users get their ROMs (it is possible to get them legally, I already did it), that is entirely up to them.

Thing is, generally the people who download ROMs don't get in trouble. The ones Nintendo goes after are those who distribute the ROMs.

This is why we insist that users don't post ROM links or share ROMs via the board.
_________________________
Kuribo64 - RH-fucking-cafe - Kafuka

zrghij

I commented out the crash line and set the nybble to 7 and this happened:



along with pretty bad slowdown


the game crashes if you try to free them, btw
_________________________
Kuribo64 - RH-fucking-cafe - Kafuka

zrghij

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 - RH-fucking-cafe - Kafuka

zrghij

it is possible that some of the reads are wrong because the blocks had a different structure back then
_________________________
Kuribo64 - RH-fucking-cafe - Kafuka

zrghij

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 - RH-fucking-cafe - Kafuka

zrghij

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 - RH-fucking-cafe - Kafuka

zrghij

re: people afraid to post because of me, or whatever


My moderation style aims at getting rid of bad users quickly. "Bad users" being those who aren't willing to improve, or are just too dumb to understand what we're telling them.


I also don't shoot users down just for the hell of it. I try to be constructive about it, and more or less subtle depending on the context. I generally get blunt when you did something really stupid, missed something that is obvious, or keep screwing up despite previous signals.


Don't be afraid to post just because I moderate. Don't constantly ask me if it's okay to post X or Y, either. There's one simple rule that keeps you out of trouble: use common sense.
_________________________
Kuribo64 - RH-fucking-cafe - Kafuka

zrghij

should be possible if both sprites are going to use the same code

then you'd need to modify said code so that it checks the sprite ID (or some sprite parameter) and uses a different model if needed
_________________________
Kuribo64 - RH-fucking-cafe - Kafuka

zrghij

this is what NSMBHD has come to



spamspamspamspamspamspam
_________________________
Kuribo64 - RH-fucking-cafe - Kafuka

zrghij

hint, PixelFox


your worth to the community is measured by the quality of your contributions, not by your postcount
_________________________
Kuribo64 - RH-fucking-cafe - Kafuka

zrghij