The NSMB Hacking Domain

Pages: 1

Ninjifox

Posted on 12-02-12, 04:42 am in Technical info about the collision detection stuff

Link
ID: 19347
+10

Micro-Goomba

Karma: 572
Posts: 9/19
Since: 06-19-11

Not a whole lot but I was trying to compare stuff between Wii and DS and figured I'd post this instead of just forgetting it and letting the info rot... It's really similar. MUCH more so than I expected! Also, this post is a bit of a mess/not very well written. Sorry about that, I just kept adding things and finding more stuff as I went along

The collision sensor class from NSMBW is located at offset 0x1D0 within the actor class and seems to work pretty similarly. 20AB010 is the "init" function (accepts as params: actor pointer, info for "below" collider, info for "above", info for "adjacent" and one more thing I don't know about that doesn't exist on Wii)

This is the header for the Wii class, almost complete but missing a few methods at the end: http://pastie.org/private/iwpn4yn8yja2jy5xisbb5w
And this is the source, in two parts because it was too big for Pastie, sorry: http://pastie.org/private/obbg438ionp5izbiacfy0g http://pastie.org/private/9fgoiswxshj4dtjcsib8w

I don't have a ton of info on the changes between both, but one thing I can detail is tile behaviours. In both games they're dealt with as large unsigned numbers.
In NSMBW they are 8 bytes (u64), and split into two parts: I like to call them "Flags" and "Properties". Properties is further split. Here's how they're sorted:

FFFFFFFF __SSCCPP

F are flags, _ are unused/unknown, S are the "subtype", C are the pipe colour (not used elsewhere afaik? not relevant on DS?) and P is a type-specific "param". The presence and possible values of P depend on what type is chosen through the flags. So a param value 1 could mean totally different things depending on the flags.

The subtype is not a set of flags, but it's a number used to choose several different flags- documented in the header file, as are most of the flags.

A few days ago I studied the DS behaviours thread to compare stuff and it seems that DS has an extra subtype in one of the slots- no idea what it means though and I'm not sure exactly which one was removed for Wii. For example, No Sliding is 10 in Wii but 11 in DS.

In DS the types are like this, as far as I can figure out. One issue is that NSMBe treats them as an array of four bytes (my fault

) when in reality they're a little-endian 4-byte (32-bit) number. This is in the PROPERLY decoded-from-little-endian format:

FFFF S_PP .... where F are flags, _ are unknown (POSSIBLY an extra flags nybble? 2 here means a Donut Lift, I've noticed, whereas it's 20000 in Wii), S is the subtype and P is the param.

So here's everything else I've mapped...

ctor: 20AB13C
dtor: 20AB110
deleting dtor: 20AB0D4
clear1: 20AB0B0
clear2: 20AB05C
init: 20AB010
checkBelowAsPoint: 1FFF86C??
checkBelowAsLine: 1FFF700??
checkSpecificPosForBelow: 1FFF290??
tryActivateBlockFromAbove: 1FFEFF4 (Seems a bit similar, maybe tryActivateQuestionBlock and tryActivateBrick weren't separate funcs in DS)
setStoredX: 20A9D3C?

I know it's not a lot but I'm clutching at straws for quite a bit of this

but hopefully it can help anyway.

What else..

The class at 0x288 is what I call dRSomething (don't ask), it's for checking collisions against non-tile solid-on-top platforms (This includes ridable enemies)

The class at 0x120 is a dComplexCollider_c (not the real name either but that's what I've named it), this is for collisions between enemies and more complex sprites like players. There's a bit too much to write up about it atm but here's the basic gist of it: It's got a ctor/dtor and a vtable, that much is obvious (and easily found out :p) it's created as part of dStageActor_c.

20A47A0 is the main init function which accepts a struct that's formatted like this:

struct CCInfo {
  s32 xDistToCenter, yDistToCenter, xDistToEdge, yDistToEdge;
  u8 category1, category2;
  u16 bitfield1, bitfield2, unknownShort;
  void *callback;
};

Callback is a function pointer that accepts two CCInfo pointers as params, and is called when the two things collide. Category1 and 2 and bitfield1 and 2 are used when collision checking, it's a bit complicated, but simplifying it a bit (there's more to it than that) it checks (oneObj.bitfield1 & (1 << otherObj.category1)) and vice versa. And in NSMBW (may be different in DS), if the result of that AND is 2, then it also checks category2/bitfield2 in a similar way. Let me know on IRC if you want to see the code...

There's also a collision check type, which is stored as a byte at field 0xAA in DS (confirmed), it has the following possible values on Wii: 0 = normal, 1 = round, 2 = vertical trapezoid, 3 = horizontal trapezoid (One of the last two is used for icicles but I can't remember which, and that's the ONLY time it's used)

20CAACC is a function table for checking colliders against each other, it's something like FunctionToUse = Table[(one.checkType * 4) + two.checkType]

20A3D78 creates that table. The first collider is chosen depending on the current Wrap setting- at least that's what it does in Wii, I can't confirm if it's actually using the Wrap value in DS or not... (Look at the xrefs to this function

)

1FFDED0 seems to be the function that does ALL checking of these colliders against every other collider. All active instances of CC are stored in a linked list.

20A44B0 seems to be a bit similar to 1ffded0 but it only checks one collider against all others, instead of checking all possible combinations. Not sure what it's used for, it doesn't exist in Wii. Seems to be stuff related to Mario judging by the xrefs...

20A46BC adds a CC to the global linked list
20A4658 removes a CC from it

That's about all I've got to write up here atm... but there's more than this, I just haven't written it up/don't feel like doing it right now. I've also got decompiled code for the Wii versions of MOST of it, let me know on IRC if you're curious.
_________________________
Insert generic signature here

Ninjifox	Posted on 09-05-14, 09:27 pm in 3ds New Super Mario Bros. 2 Hacking (rev. 1 by ImageBot on 11-21-16, 03:04 am) Hi. Link ID: 38502 +7
Micro-Goomba Karma: 572 Posts: 19/19 Since: 06-19-11	_________________________ Insert generic signature here

Ninjifox	Posted on 06-19-11, 09:43 pm in The obligatory introduction thread Hi. Link ID: 15 +5
Micro-Goomba Karma: 572 Posts: 1/19 Since: 06-19-11	Yeah, I might as well make this. Every board needs one eventually! _________________________ Insert generic signature here

Ninjifox	Posted on 09-11-12, 03:59 am in World map icons. Hi. Link ID: 15834 +2
Micro-Goomba Karma: 572 Posts: 5/19 Since: 06-19-11	Documentation for the BNCD format I just whipped up: http://treeki.rustedlogic.net/JNCD.txt A little incomplete but it's a good start. _________________________ Insert generic signature here

Ninjifox

Posted on 11-08-12, 05:24 am in oct 22 to nov 6 Garmichael's Level Design Contest!

Link
ID: 18094
+2

Micro-Goomba

Karma: 572
Posts: 7/19
Since: 06-19-11

So here you have it. My crap critiques

1-1 (MarioFanatic64) ----

I thought this level was really fun at first, but I got frustrated pretty quickly at what seems like several cheap shots throughout it. For example, I kept dying at the start while I was unfamiliar with the level - not that this is a bad thing per se - but I died several times on the starting zone just because I was sick of waiting a couple of seconds after every death while the two Goombas sauntered off-screen.

I can't really fault the first ruins area, aside from one issue which killed me unfairly the first time I got there: the swinging ropes are placed in such a way that you can glitch into the ground. The first rope sent me into the ground and I fell down to my doom. The rope next to the Star Coin allows you to go even further into terrain, but at least that won't kill you...

The midway grassland area also feels like a cheap shot to me- the piranha plant and koopa are placed there so that you pretty much ALWAYS have to be hurt, until you figure out that you have to wait for the koopa to turn around and go a safe distance away.

Another thing that I really didn't like is that there's various pits which entice you in to look for secrets and then kill you because it looks like you'll be able to walljump out... and then you can't. At one point, there's two pits which both look the same- one takes you onwards in the level, the other one kills you. That's not fun

On the design front, the level looks good, doesn't feel repetitive and I couldn't find any tiling or camera errors. It could do with some tweaks and fixes, but I'd already consider it an above average level.

Challenge Requirement Met: 10/10

Design: 13/20
Polish: 17/20

1-2 (Freeze) ----

This is a pretty awesome level that's unfortunately marred by some issues. The first area abuses Boomerang Bros, which are a pain to dodge because of the tight passageways and the boomerangs following you around for what seems like ages.

Other than that, I quite enjoyed the various explorable areas and the large amount of camera flourishes (though they are glitchy at times). There was one noticeable tiling error in the midway grassland area which I'm surprised was missed.

I can't really complain about the gameplay, aside from the Boomerang Bros- I wish those would have been toned down a bit; it makes the level hard to explore without constant deaths.

Challenge Requirement Met: 10/10

Design: 17/20
Polish: 17/20

1-3 (Nothing) ----

This level is a bit of a mixed bag. There were no tiling errors or camera issues, but the star coins were practically impossible to find. The ruins also seem to have somehow disappeared. It did get the "Sky" bit down right, though, so I'll give them that.

Challenge Requirement Met: 1/10

Design: 3/20
Polish: 19/20

1-Tower (RiksKing) ----

I was not impressed by this level. Progress paths are broken and there are strange camera glitches. I felt like I was getting lost- I somehow wound up in the midway point zone after falling and the camera screwing up badly -and the layout made little sense.

The terrain is almost completely devoid of decoration and there are a ton of unrelated sprites used. There were a ton of little things I saw that didn't look good to me: repeated mushroom tiles in the grassland areas, the strange "loose arrow" sprite with no backing tiles, background ruin bricks with cut-off edges, bushes with parts growing out of thin air...

You can get stuck and have to restart if you throw your springboard into a bottomless pit in the first area.

Challenge Requirement Met: 10/10

Design: 9/20
Polish: 5/20

1-4 (Dirbaio) ----

This level is full of Goombas and Koopas, and... not much else. One big beef I have with it is that there's a few points where you can have a Goomba unexpectedly fall from above- this shouldn't happen! I also noticed a few tiling errors in the grassland areas, and progress paths don't work.

One thing I quite liked, though, was that there was an underground themed area to differentiate the level a bit from the others. The colour changes in the ruins tileset were also pretty cool.

Now for the bad part... the maze is cool at first, but as a rather bad Mario player, I found it ridiculously exasperating. I kept dying on the huge amount of Goombas and Koopas and got sick of having to repeat everything over and over again. And why isn't there a midway point?!

Challenge Requirement Met: 10/10

Design: 13/20
Polish: 18/20

1-5 (Piranhaplant) ----

I really enjoyed this level. I don't have a whole lot to say here... it was simple and straightforward but it looked good and was fun to play. Difficulty was well balanced and there weren't any cheap tricks that caught me out. I didn't find any tiling or camera errors.

Challenge Requirement Met: 10/10

Design: 19/20
Polish: 20/20

1-Castle (Hiccup) ----

Ah, yet another one. Progress paths are broken. Should have expected that...

Otherwise, it's a bit of an interesting level. There were some different mechanics in play which I liked, but I think they could have been executed better. I think the tiling could have made better use of the ruins tileset as well. It's also a little strange to see the swinging platforms outside a castle level and the punchy enemies outside a snow level, though I don't think that really makes the level worse.

Challenge Requirement Met: 10/10

Design: 12/20
Polish: 15/20

2-1 (MarioSunshine) ----

WORKING PROGRESS PATHS! YES!

This level was pretty nice and made good use of the tilesets. I liked the climbing zone in the first grassland area, and the use of zooming cameras in the rest of the level.

One thing which bugged me a bit was the low Y scrolling bounds, but I can live with that. On the other hand, it wasn't really a problem because there were few enemies in the level which could catch you out. One of the critiques mentioned that as a bad thing, but I actually think it made the level a lot more fun- I could actually focus on exploring the level instead of being killed constantly.

There are a lot of different platform sprites used, and a couple of them look a bit out of place (like the closing yellow draw bridge) but I won't let that detract from it.

Challenge Requirement Met: 10/10

Design: 18/20
Polish: 19/20

2-2 (Py_hacker) ----

This level can only be described as object soup. Not fun to play or to look at, really. There's not much else I can say...

Challenge Requirement Met: 10/10

Design: 6/20
Polish: 3/20

2-3 (TRS) ----

The camera jumped a bit, but otherwise I couldn't find any issues. This was a nice little level with good design, just nothing particularly unique (though it's hard to come up with something new after having seen so many levels...)

Challenge Requirement Met: 10/10

Design: 17/20
Polish: 19/20

2-4 (Garmichael) ----

A pretty excellent level, there's nothing I can complain about. It shakes things up a bit by using the forest background for the grassland zones.

Challenge Requirement Met: 10/10

Design: 20/20
Polish: 20/20

2-Tower (Gridatttack) ----

Once again.. I don't have much to say. This is an awesome level, I found no issues in it.

Challenge Requirement Met: 10/10

Design: 20/20
Polish: 20/20

_________________________
Insert generic signature here

Ninjifox	Posted on 09-05-12, 04:45 pm in The Ask Dirbaio™ Thread! Hi. Link ID: 15527 +1
Micro-Goomba Karma: 572 Posts: 3/19 Since: 06-19-11	If you were totally done with NSMB hacking and there was nothing else to discover or do or edit... what game (if any) would you hack? _________________________ Insert generic signature here

Ninjifox	Posted on 09-22-12, 01:46 pm in help needed! Soundset listing project! Hi. Link ID: 16234 +1
Micro-Goomba Karma: 572 Posts: 6/19 Since: 06-19-11	I read you talking about this in IRC last night, and it sparked my curiosity and I decided to check out the sdat file in Nitro Player... It turns out that sound sets map directly to Groups, which in turn load different banks. The last valid sound set is 0x38 if I counted right. I'll post the bank/group lists later if you're curious... _________________________ Insert generic signature here

Ninjifox	Posted on 11-12-12, 11:34 pm in oct 22 to nov 6 Garmichael's Level Design Contest! Hi. Link ID: 18359 +1
Micro-Goomba Karma: 572 Posts: 8/19 Since: 06-19-11	Maybe this is a bit predictable. But oh well, it works :p #1: gridatttack #2: Garmichael #3: Piranhaplant _________________________ Insert generic signature here

Ninjifox	Posted on 04-02-13, 11:40 am in Wii Mini Hi. Link ID: 22418 +1
Micro-Goomba Karma: 572 Posts: 11/19 Since: 06-19-11	I have to say I find it rather ironic that you posted this in ROM Hacking when the Wii Mini is entirely unable to be hacked... Would never get one. _________________________ Insert generic signature here

Ninjifox

Posted on 06-24-13, 04:25 pm in NSMB Class Hierachy

Link
ID: 23821
+1

Micro-Goomba

Karma: 572
Posts: 12/19
Since: 06-19-11

As far as I know, the 3 methods state machine is the same in every game that uses this engine (SM64DS, NSMB, NSMBW, Animal Crossing on DS and Wii, maybe more...?)

I haven't checked, but I see no reason why it would change... This is how I decompiled it from NSMBW:

int fBase_c::processOperation(funcPtr onFunc, funcPtr beforeFunc, paramFuncPtr afterFunc) {
  int afParam;
  int result = this->*beforeFunc();

  if (result != 0) {
    result = this->*onFunc();
    if (result == 0)
      afParam = 3;
    else if (result == 1)
      afParam = 2;
    else
      afParam = 1;
  } else {
    afParam = 0;
  }

  this->*afterFunc(afParam);
}

The vector thing is crazy. I guess it does make RE easier though

It's no longer virtual in the Wii games, though.
_________________________
Insert generic signature here

Ninjifox

Posted on 06-24-13, 10:30 pm in NSMB Class Hierachy

Link
ID: 23847
+1

Micro-Goomba

Karma: 572
Posts: 13/19
Since: 06-19-11

Posted by Powerline

I never found any clue about NSMBWii using the same enigne when I looked into it. Do you have any info about it that can help me? Like any disassembly, and locations for actors and how they are called?

Too much to list, I could probably spend months writing docs about it... I've ripped apart huge parts of the game, I probably know more about its internals than anyone else outside Nintendo EAD :p I'll be releasing tools and header files for compiling custom code for the game later this year.

I haven't looked into much of the code in SM64DS and NSMB; 99% of my work has been with NSMBW. I'm not as familiar with ARM as with PPC, and I just haven't had much reason to look into those (especially with the overlays).

In the Wii game, -everything- happens inside onCreate/onExecute/etc. Here's an example of a custom sprite I wrote, if seeing some actual code helps.

Also, I forgot to mention two more uses of the same engine before- Zelda: Skyward Sword and the MotionPlus demo video player are also based off this thing. Apparently EAD really likes it.
_________________________
Insert generic signature here

Ninjifox

Posted on 06-25-13, 11:25 am in NSMB Class Hierachy

Link
ID: 23858
+1

Micro-Goomba

Karma: 572
Posts: 14/19
Since: 06-19-11

Posted by Powerline

That is awesome! Gives me a pretty good idea how a platform works. I am a platform freak, and NSMBW is really interesting when it comes to platforms because of the 4 player support and bilinear filter rendering.

... bilinear filter rendering? You lost me there

Posted by Powerline

And the very well written and awesome working camera stage wrapping system written in NSMBDS were no longer supported in NSMBW because of floating point.

I don't think this has anything to do with floating point... It still exists in NSMBW :p

Posted by Powerline

Two classes in your code:

Physics and StandOnTopCollider

are very interesting to me.
[...]
You seem to have a good understanding of how sprites are rendered as well. That is quite interesting!

Yep, this stuff is practically identical between DS and Wii as far as I know.

I really need to come up with better names for those classes - I considered renaming the former to SimpleCollider but I haven't changed that in the Newer codebase yet.

Physics is the class used to add a solid box or round object that other actors can collide with, like the rotating blocks, moving platforms (not the ones you can jump through!), and so on. (Fun fact: the giant rotating gears in 1-Castle are composed of something like 10 of these. There's a round solid object for the centre, and each tooth is a rotated rectangle.)

StandOnTopCollider is.. just that. It's a line which is only solid on one side. Quite simple.
_________________________
Insert generic signature here

Ninjifox

Posted on 08-05-13, 11:43 pm in NSMBe Java port

Link
ID: 25426
+1

Micro-Goomba

Karma: 572
Posts: 15/19
Since: 06-19-11

Why not do something similar to the Reggie interface?

In Reggie...

- Object and sprite types are immutable
- Everything can be painted by right clicking (except for views, which are not editable through the main window)
- Path editing is... OK, it works, but maybe you could come up with something better
- Shift+Click is multiple select; Ctrl+Click clones an object
- Entrances and Paths are listed in their corresponding tabs in the Palette

_________________________
Insert generic signature here

Ninjifox

Posted on 08-06-13, 12:17 am in NSMBe Java port

Link
ID: 25430
+1

Micro-Goomba

Karma: 572
Posts: 16/19
Since: 06-19-11

Posted by Dirbaio

- Object and sprite types are immutable
... I'm not sure if I quite like that. Maybe you'd have to change the sprite type but keep its settings? Or change the object type in lots of objects...

Been a while since I wrote that, I just remembered that it actually is supported in Reggie, but not done in the same way as NSMBe so it's extremely hard to trigger by accident.

Selecting an object or sprite from the Palette while Alt is pressed changes the types of all the selected things.

Posted by Dirbaio

- Path editing is... OK, it works, but maybe you could come up with something better
How does it work? (Sorry, I don't have NSMBW and reggie here right now, and internet is crap)

Oh, I forgot

Path nodes are handled in a similar fashion to sprites/entrances - you select one and the settings for it come up in a panel. If you right click while a path node is selected, then a new node is created for that path. If no path node is selected, then a new path is created with a new node.

Also, the Palette shows a list of all paths which you can click on to jump to a specific one.

Posted by Dirbaio

- Shift+Click is multiple select; Ctrl+Click clones an object
That's nice

I'd rather make Control+Click multiple select, and Control+Drag clone, it's the standard behavior pretty much everywhere.

That does sound better. I /think/ we might have done this because I couldn't figure out how to detect drag vs. click...

_________________________
Insert generic signature here

Pages: 1