I’ve been having a hard time trying to reconcile approaches that seem mathematically correct with the actual output from the Retail version of EMI. To figure out exactly what was going wrong, I decided to go back to the debugger and probe the internal values generated by the Retail version of EMI to compare with the results that are being produced by ResidualVM.
To begin with, I needed to figure out how the Retail version maintained the actor’s position. To find this out, I investigated the Lua entry point for SetActorRot to find where in memory the rotation information was stored. After some inspection, it turns out that in EMI, the rotation information is converted from the Euler Angles that were passed in from the Lua to a rotation matrix located 0xA0 bytes from the beginning of the allocated Actor. How do we know where the start of the allocated Actor is? For C++, the X86 ABI uses the convention that the object being referenced is passed in the ECX register when calling an object method. We can be fairly certain that in this case, it is the Actor object because the Lua/C++ interface passes in the actor handle as the first parameter, and when that actor’s handle is used to retrieve the Actor object, the return value is saved into the ECX register.
How did I know that the rotation was stored in a rotation matrix? I observed that after the Euler Angles were passed in, a series of floating point operations occurred, resulting in writing to nine values in the Actor object. Writing nine values was likely to be a 3×3 matrix, so I checked these values for Guybrush in the set wed by setting the debugger to break when SetActorRot is called and the actor handle matched the integer stored in hActor for Guybrush, which seems to always be 4. To be sure that this was Guybrush, I also checked the actor’s position at offset 0x94, which matched with the results from guybrush:getpos().
Here’s the rotation matrix for Guybrush in the scene wed, before any movement, in the Retail version:
| Guybrush Rotation Matrix | ||
|---|---|---|
| -0.34202039 | 0.0 | -0.93969256 |
| 0.0 | 1.0 | 0.0 |
| 0.93969256 | 0.0 | -0.3402039 |
This rotation matrix was created by setrot(0, 110, 0). So, I then tested and found that there were multiple Euler Angle Orders that can reproduce this matrix. This is because there’s only one rotation axis that’s being changed, so there is ambiguity between the other two.
So, lets investigate the more complex attaching and detaching scenario that I outlined in the previous post. We’ll start with only the first actor, and check that rotation matrix first. First, I needed to identify the actor handle ID, so I ran the rotation script and checked the value of hActor for at1, at2 and at3. The actor handles for each, after running the script for the first time in the set wed, are: 106, 107 and 108, respectively. Recall that the first actor is rotated with the call setrot(5, 15, 25). This results in this matrix in the Retail version:
| Actor1 Rotation Matrix | ||
|---|---|---|
| 0.87542605 | 0.40821794 | -0.25881907 |
| -0.40056604 | 0.9123922 | 0.084185995 |
| 0.27051076 | 0.029975513 | 0.96225017 |
In this case, there should be no ambiguity, with only one rotation that produces the correct result because each of the rotations are different. The rotation that produces the correct result in ResidualVM is:
Math::Matrix4 m;
m.buildFromXYZ(getRoll(), getYaw(), getPitch(), Math::EO_ZYX);
m.transpose();
With this approach now reproducing the same results, in the next post, we’ll examine attaching again with the extra information we’ve learned here.