Pages: 1
Posted on 12-02-12, 04:42 am
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
Pages: 1