Super Mario 64 forum moderator
For next: 15760
From: Montreal, Canada
Since last post: 1.3 years
Last activity: 64 days
|As many experienced TT64 users found out, when you try to apply behaviors from an enemy to a different model, you usually end up with an epileptic and glitchy character. For example, applying the Goomba Walk behavior to MIPS the rabbit result in the mutant rabbit you've seen in the TT64 2007 demo patch.
The reason why it happens is that the animated rotation values are applied to the wrong joints, and if the model you use has more joints than the behavior animates, the rest will end up pointing up to unrelated values in RAM, which creates seemingly random glitchy movements in the remaining joints.
I used to think that the relation between the behavior and model was hard-coded in the ASM behavior functions, and thus would be hard to modify or transfer from one model to the other.
But I found it's not quite the case since rstewart215804 found a very interesting command used in behavior scripts.
The command is 0x27. I updated my "decompiled" behavior script document to reflect this new find.
  [00 00]  [00 61 6C]
The 0x27 command points to animation data which is usually found in the same bank where the related model polygon data is (most of the time, it's just after the polygon data for a given model).
I don't know the exact format of this data, but it often includes jump offsets so the data is not linear, and I assume it's structured in a hierarchy fitting the model body part structure.
If you want to take a look at this animation data, and maybe try to find more about its format, here's how to find it:
Let's take the Goomba animation data as an example.
The "Goomba Walk" behavior pointer is 1300472C.
The behavior script bank (0x13) is loaded from 00219E00 in ROM. So 00219E00 +00472C= 0021E52C.
You can use the SM64Behavior.txt document to look it up.
Here's the Goomba Walk behavior script from the document:
ROM Addr: 0021E52C Hex Behav: 1300472C
You can see that the 0x27 command is found at 21E538 in the ROM.
27 26 00 00 08 01 DA 4C
It means that the animation data is found at offset 0x01DA4C in bank 0x08.
Where is bank 0x08? You'll have to use TT64 to find out.
Open a ROM in TT64, and load a level where you can put Goombas, it could be Bob-Omb Battlefield, but let's use Castle Ground in this example, which as most of you know can also contain Goombas.
So load the Castle Grounds level if it's not already loaded.
Set the Commands mode to Expert and click on the "0x17 Copy Data to RAM Bank" line in the command menu.
Set the mode to Hexadecimal by clicking on the appropriate checkbox.
Look at the 0x17 commands list. The 12th line is "012 i h08 h00A8181C".
If you click on it, you can see that in this levelbank 0x08 is loaded from data found in ROM, starting at 0x00A8181C and ending at 0x00AAA40C. The important number here is 0xA8181C, since it's the begining of the bank in the ROM.
If you add 0x01DA4C (Goomba animation data offset) to 0xA8181C, you'll end up with 0xA9F268, and this is where the animation data entry point is in an extended ROM.
Looking at 0xA9F268 in the ROM with an hex editor, the first four bytes you can find are 08 01 DA 34.
Hmm... 08, what a coincidence, it's the bank number we're at! 01DA34 is indeed a valid offset inside this bank. To make it easier to find where it is in the bank data without having to add 0xA8181C each time you encounter an offset in bank 08, what you can do is copy all the data from 0x00A8181C to 0x00AAA40C and paste it into a new empty document (in your hex editor). That way you can easily find an offset in bank 08 just by looking at the address column on the left.
Like I said, I don't know much about the actual format there. Outside of the offsets, which seems to make the data jump around the place in that bank, there are some sequence of data which seem to be series of angles.
If you want to help cracking the format, and have previous ROM hacking experience, this could be your starting point.
But let's get back at the 0x27 command level, since we don't know the animation data format.
By swapping around 0x27 commands in behavior scripts, we can do very very interesting things...
Let's say we want to make a MIPS rabbit that acts like a Goomba.
Start with a freshly extended ROM.
In TT64, in Castle Grounds, select a butterfly. Make sure you're in the Expert Paramater Bar mode so you can see the Model ID and Behav params. (That's just below the Activate Level Select check box).
Click on the menu icon for the Model ID param, and select MIPS as the model(Model ID 100). Then, click on the menu icon for the Behav param, and select the Goomba Walk behav (18220).
Click on Save. Try the ROM in your favorite emulator.
Ok so while MIPS acts like a Goomba, it's all glitched and mutant...
That's because the game applies the animation data from the Goomba (the 0x27 command found in its behavior script) to the MIPS model, and its body part hierarchy simply doesn't match.
Let's try to fix that with what we know now...
Take another look at this document: http://homepage.mac.com/qubedstudios/SM64Behaviors.txt
We try to find the MIPS behavior script.
Here it is:
ROM Addr: 0021E2FC Hex Behav: 130044FC
Ok, so MIPS' animation command is 27 26 00 00 06 01 57 24.
Looking at the Goomba Walk behavior script:
21E538/004738 27 26 00 00 08 01 DA 4C
We see that the Goomba Walk animation command is at 21E538 in the ROM.
Open the ROM you just modified, go at 21E538, and replace 27 26 00 00 08 01 DA 4C with 27 26 00 00 06 01 57 24. Save the changes.
Load the ROM in the emulator, go to Castle Ground... Oh! That's better, MIPS is no longer a mutant, and he acts like a Goomba!
The only thing is that he seems to be stuck in his "idle" animation routine while he walks, instead of his walking animation, so he looks like he's sliding, while looking around. He does have a different animation when he starts running toward you, and it's pretty funny. It's not perfect but it's still much much better than the mutant version.
But there's a big problem. We've now modified the Goomba Walk behavior script so that it uses the MIPS animation. What happens if you put a Goomba in Castle Ground using this ROM? Well he'll be glitched...
And what happens when you go to Bob-Omb battlefield in this ROM? It crashes... That's because the Goomba Walk behavior script now relies on the animation data from MIPS, which is expected to be found in bank 0x06. But in other levels (except inside the castle) bank 0x06 in RAM doesn't contains the MIPS polygon data and its animation data, it contains some other bank.
So when swapping 0x27 commands, you really have to know what you're doing. You must be sure that the content of the bank which is referred by this 0x27 command will always be present in levels where this behavior script is used. Always work on backups, don't try to experiment with this on the only copy of your masterpiece TT64 mod.
Also, if you're a n00b and try swapping 0x27 commands, don't come here to complain that it crashes your ROM.
Because of all these potential issues, it would be hard to integrate any fool-proof method of editing the 0x27 commands in TT64.
A way to get around some of these problems would be to extend bank 0x13 (the behavior script bank) and duplicate existing behavior scripts to create new ones that could be only used in a particular level. Still, managing all this would end up being very complicated.
Eventually, managing and editing behavior scripts and animation commands will be possible in TT64, but certainly not soon.