By James S.
King Bob-omb
Added: 3/4/9
King Bob-omb is the boss of Bob-omb Battlefield and the first boss Mario has to fight in SM64. I did a code where King Bob-omb appears instead of a Koopa shell when you stomp the Koopa; the code also makes Koopa think that King Bob-omb is his shell. The strange thing is, after you defeat King Bob-omb and the star is placed in the usual place, Koopa keeps diving at the air near where King Bob-omb was when he was defeated.
What Nintendo did was to hide King Bob-omb when he is defeated rather than remove the actual object, since you would normally collect the star and thus end the course there is no great consequence for not removing the King Bob-omb object.
King Bob-omb is made invisible by changing the value at offset 0x02 in the object to the value 0x0031. If you change it to 0x0021 King Bob-omb appears, still animated.
Koopa
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