SM64 Exposed The Objects in Detail

If you stomp the small Koopa in Bob-omb Battlefield or Tiny-huge island, you can take and ride his shell but Koopa will do his best to get his shell back. The Koopa shell that you can ride is not the same shell Koopa has on his back, instead Koopa has two different graphics, with and without his shell. When you stomp the Koopa his graphics change so it looks like he has no shell and then a Koopa shell is spawned at Koopa's position.

But how is Koopa able to chase after his shell? Koopa looks for and homes in on the nearest object with the Koopa shell behaviour (0x13001F3C). So the coding can be changed so that Koopa goes after an object with a different behaviour, even Mario (other objects would use the pointer to the Mario object to chase him, but it has the same affect).

When Koopa does get his shell back, the shell object is removed and then Koopa's graphics are altered again, this time so it looks like he has his shell. If, however, Koopa is made to chase an object with a different behaviour, upon contact the object isn't removed so Koopa keeps trying to 'put on' the object by diving into it. Most amusing is if the code is patched so that Koopa thinks a Bob-omb is his shell; when Koopa dives at the Bob-omb it explodes, killing Koopa as well!

Koopa the Quick

It turns out that when you stomp an ordinary Koopa, its graphics change to show he has lost his shell, and then when he gets his shell back, his graphics return to what they were previously. The point is that the Koopa shell you can ride is a separate object to the actual Koopa (and his shell) and this is the same with Koopa the Quick who is just an enlarged version of a normal Koopa (and with behaviour changes). A code I did altered Mr. Quick's graphics and so I raced him without his shell.

Tox Box

Those large boxes in Shifting Sand Land that have faces known as Tox boxes, follow a set path but they move due to values in memory, not due to collision with the ground below. In a Tox box object structure is a pointer to the values in the RAM that controls its movement as a repeated pattern.

To test, I modified the path values of the first Tox Box so it was now on a different route, showing that it's not affected by gravity. It got stuck a number of times thanks to me changing the values, including when it had met one of the level boundaries. Interesting is that although you can jump into the halted Tox Box with the hole showing you can't get on top of it when it's the other way up even though it wasn't moving.

Water Bomb

In Bob-omb Battlefield, there are two areas where a water bomb falls when Mario gets near and causes him damage upon contact. The water bomb graphic doesn't have a shadow, so for every water bomb two objects are spawned which are the actual water bomb and its shadow. I don't why there was the need for them to be separate but it worked to my advantage for a code I did which alters the coding to that the water bomb and its shadow are swapped with ten yellow coins and a single blue coin.

Have a look at the coding for the NTSC version:

80306174 LUI T2, 0x1300

80306178 ADDIU T2, T2, 0x4BA8 Water bomb behaviour

8030617C ADDIU T0, R0, 0x0054 Water bomb GFX ID

80306254 LUI A2, 0x1300

80306258 ADDIU A2, A2, 0x4BD4 Water bomb shadow behaviour

80306264 ADDIU A1, R0, 0x0055 Water bomb shadow GFX ID

Also, so that the coins keep falling, although with the possibility of the game crashing if there are too many coins, I NOPed the second instruction of the following:

80306270 ADDIU T8, R0, 0x0001

80306274 SW T8, 0x00F4(T6)

So the game would normally place a one to stop another water bomb from being spawned immediately.

Work elevator (Hazy maze cave)

(Added: 22/11/8)

In Hazy maze cave an elevator is used to help you get the eight red coins, it is moved by walking Mario over the direction switches. Firstly, the four direction switch are separate objects to the actual elevator but they move with it so it seems they are one object.

How is it then that the switches are able to 'talk' to the elevator to tell it which direction to move? A global variable (PAL 0x802FED54 NTSC 0x803327A4) is altered by the switch behaviour to tell the elevator what direction to move, the elevator behaviour then reads the variable to find out what it should do. The variable is also updated by the elevator behaviour for when it rocks upon hitting a wall or when it resets. The values used are:

0x00 Not moving

0x01 Moving backward

0x02 Moving forward

0x03 Moving right

0x04 Moving left

0x05 Rocking

0x06 Reset

The action value is used as an index to look up what function to call to perform the necessary action.

The elevator direction switches use the same behaviour, how the behaviour knows what direction to move the elevator is by looking up the value at offset 0x144 in the direction switch object. For e.g., the backward direction switch has 0x01 stored at offset 0x144 in the object. Actually, the value is stored as 32 bits in the object but copied as only a byte to the global elevator action variable. You can modify the action value in the direction switch object so that the elevator moves in a different direction or so it performs another action such as to reset.

All content of this and related pages is copyright (c) James S. 2008-2009