So this is a (lame?) attempt and showing the newbies how the actors in NSMBDS really work. Now this tutorial assumes that you've already learned some C, C++, and ARM assembly. If you haven't learned any of these (but really ARM in general if you just want to get a tiny grasp), you should exit this thread and try to learn these languages. Oh, and you also have to have a version of IDA. I use 6.8 (used to use 6.1 but now the idb fails for some reason.)

So to actually figure out how an actor works, you first have to find the pointer to it's profile in the profile pointer list. This is located at address 0x0203997C in the game's code (I think it's US region, correct me if I'm wrong, and to get to this address you hit "g" in the IDA view, and then paste that address). The profile pointer list literally points each entry to the actor's constructor, which is what we'll get into later. Now during the 10 minutes I spent looking at the IDB, I'm not sure how one would calculate how to find an actor. But for the sake of example, we will use the Jumping Cheep Cheep's pointer. This pointer is at 0x0203997C.



if you're using a outdated IDB, it will appear as this. Highlight off_2228F10 in IDA and hit "n". In the field, simply type in "JumpingCheepCheep__Profile" and hit enter. Then it should show up as this:



and if it looks like that, highlight it and hit enter OR just double click on the name. After you click on it, you should get something like this, except that JumpingCheepCheep_ctor is labeled something else. Highlight it and name it what I have below.

Now to actually break this down. The first line, DCD, means to pretty much load into memory. So in this example, the constructor is loaded into memory and accessed. The second line just says that to get to this position, you had to come from the profile pointer table.



After renaming the routine, double click on it. You should have something like this:


yeah, that's a lot of information for you at once. But to be pretty blunt, this is what the code does:


So really, the constructor sets up the actor to be able to function, and it also "preserves" memory for it to work. It also has a pointer to the vtable, which contains all of the methods that the class uses. This will also lead us into inheritance and methods. If you see what I see, double click on "JumpingCheepCheep__vtable". You should get something like this:



yep, even more crap to worry about. However, we can walk through it. This table is a table full of methods that the actor uses. For instance, "Actor__SetXPosition" sets the actor's position. This function is a part of the Actor class, so it inherits that method to use in the Jumping Cheep Cheep class. It saves memory! However, there is something called "Method Overriding", where instead of inheriting a method from a previous class (or even many many classes if the inherited class doesn't use their own method either), the current class overwrites it with something else. This can be seen when the entry starts with "JumpingCheepCheep__", which means that the method is overridden. For example, "JumpingCheepCheep__executeState0". So instead of using something like EnemyActor::executeState0(), it uses JumpingCheepCheep::executeState0().

Since we know how method overrides work, we can now look at important methods that most sprites use.

Method Name	Purpose
beforeCreate	This method is executed before the actor is created onto the current scene.
afterCreate	This method is executed after the actor has been created.
beforeDelete	This method is executed before the actor is deleted.
onDelete	This method is executed once the actor has been deleted.
afterDelete	This method is executed after the actor has been deleted.
beforeExecute	This method is executed before the actor is executed.
onExecute	This method is executed once the actor has been executed.
afterExecute	This method is executed after the actor has been executed.
beforeDraw	This method is executed before the actor is drawn onto the current scene.
onDraw	This method is executed once the actor has been drawn.
afterDraw	This method is executed after the actor has been drawn.

Something common would be to click on a function and then see this:



this pretty much means:



which pretty much does nothing. I'm not sure what returns 2 and 3 do, but I think one of them deletes the actor. If not, then whoops, I overlooked something. But that's how NSMBU does it.

That's all I can really provide at the moment. I'll go deeper later, but this is my attempt at partially explaining it.

Some notes;


Perhaps it would be so, except that allocFromGameHeap, or, more specifically, allocFromHeap2, jumps to OS_Panic() when it fails to allocate memory. So that defeats that.



It would, but it doesn't. This function is NEVER run and I can only assume is leftover from zee beta.

wow, that is pathetic.