65
edits
Changes
From Final Fantasy Inside
m
Part I: Structures1.FF7FrameHeader2.FF7FrameMiniHeader3.FF7ShortVec4.FF7FrameBuffer Part II: Functions and Format1.GetBitsFixed()A. Format2.GetDynamicFrameOffsetBits(Wiki-fied by Halkun)3.GetEncryptedRotationBits(Small additions by Borde) Part III: Putting it All Together1.LoadFrames()2.A Sample Loop Part IV: Qhimm’s Input
2.==== A Sample Loop ====
magnitude of -1).
signed integer overflow). Small values will be stored using fewer bits, while larger values use more bits. The two smallest values, 0 and -1, are not encodeable but are instead handled using the previously mentioned scheme.
14 revisions imported
This file was written by me, L. Spiro, as can be seen by the proper grammar and perfect spelling.
=== Part I: Structures ===
<code><pre>
typedef struct FF7FrameHeader {
DWORD dwBones; // Bones in the model + 1(unless we're dealing with a weapon animation, in which case it's value is always 1). 0x00 // This field is rather unreliable so better use the number of bones provided by the skeleton file.
DWORD dwFrames; // Frames in the animation. 0x04
DWORD dwChunkSize; // Size of the animation set. 0x08
<code><pre>
typedef struct FF7FrameMiniHeader {
//SHORT sBones; // Bones in the animation. 0x00SHORT sFrames;// Apparently, frames in the animation (but sometimes sFrames > dwFrames)
SHORT sSize; // Size of the animation data. 0x02
BYTE bKey; // A key flag used for decoding. 0x04
} * PFF7FrameMiniHeader; // Size = 5 bytes.
</pre></code>
NOTE: sBones should provably be called sFrames since it seems to hold a secondary frames counter. Thus, it should be equal to dwFrames. Unfortunately, it usually isn't. In fact, It's hard to say which one should actually be trusted. Apparently dwFrames is a more conservative value, meaning there will always be at least that many frames in the animation. But there can be more of them. I can't help but wonder if this means the rest of the frames are dummied out information or they serve some sort of purpose. On the other hand, sFrames is sometimes higher than the actual number of frames on the animation chunck.
Anyway, the actual number of frames can be computed by parsing the whole animation chunck.
It's also worth mentioning that there is at least one animation (15th from RSAA, the playable frog) which physically lacks the sFrames field. Instead, sSize is at 0x00 and bKey at 0x02. This animation is more than likely damaged, because FF7 doesn't seems to be able to handle it.
==== FF7FrameMiniHeader ====
This is a basic bit-reading function. It reads “dwTotalBits†from “pbBuffer†starting at the “dwStartBitâ€â€™th bit.
==== GetBitsFixed ====
1.
<code><pre>
Now that we can read the bits in the buffer we have made, it’s time to know what we’re doing!
===== A.=====
The animation data begins with one full frame that is uncompressed, but stored in one of 3 ways. Every frame after that is compressed, but compressed in one of three ways; one way can be decoded using the same method as on the first frame, which is why sometimes the second, third, and even fourth frames can be decoded using the same method as was used on the first frame.
First Frame:
==== GetDynamicFrameOffsetBits ====
The first frame is easy.
Remember that all frames after are stored as relative offsets from the frame before it.
</pre></code>
==== GetEncryptedRotationBits ====
Now all that is left is to decode the rotations.
Rotations change size in multiple ways.
After the function returns, we must translate the rotational INT values to their FLOAT forms (although the function can be modified to do this part itself).
This function will be called in a loop for every frame in the rotation.
==== LoadFrames ====
1.
PFF7FrameMiniHeader pfmhMiniHeader =
(PFF7FrameMiniHeader)pbAnimBuffer; SHORT sSize = pfmhMiniHeader->sSize; BYTE bKeyBits = pfmhMiniHeader->bKey;
// Skip the first 5 bytes because they are part of the frame header.
if ( iBitStart == 0 ) { // First frame?
// The first frame is uncompressed and each value is the
// actual rotation. pfbFrameBuffer->svPosOffset.sX = GetBitsFixed( pbThisBuffer, dwThisBitStart, 16 ); // Always 16 bits here.
pfbFrameBuffer->svPosOffset.sY = GetBitsFixed( pbThisBuffer, dwThisBitStart, 16 );
pfbFrameBuffer->svPosOffset.sZ = GetBitsFixed( pbThisBuffer, dwThisBitStart, 16 );
// This function will set the FLOAT values for the
// positions.
// Any scaling that needs to be done would be done here.
pfbFrameBuffer->svPosOffset.fX = (FLOAT)pfbFrameBuffer->svPosOffset.sX;
pfbFrameBuffer->svPosOffset.fY = (FLOAT)pfbFrameBuffer->svPosOffset.sY;
// If we did not read as many bits as there are in the frame,
// return the location where the bits should start for the
// next frame.
if ( (SHORT)(dwThisBitStart / 8) < sSize ) {
return dwThisBitStart;
return 0;
}
</pre></code>
2.
This is an example loop that could be used to load a full animation.
<code><pre>
FF7FrameHeader fhHeader;
ReadFile( hFile, &fhHeader, sizeof( fhHeader ), &ulBytesRead,
// will load diretly into it.
// Every frame after that will actually use it with the
// offsets loaded to determine the final result of that // frame. iBits = LoadFrames( &fbFrameBuffer, fhHeader.dwBones,iBits, baData );
// Reverse the Y offset (required).
fbFrameBuffer.svPosOffset.fY = 0.0f –fbFrameBuffer.svPosOffset.fY;
// The first rotation set is skipped. It is not part of
// to dynamically make the model point at its target
// or face different directions during battle.
// UPDATE: Although the value of this field is 0,0,0 for most animations, some actually store a base rotation here
// so it shouldn't be ignored.
for ( DWORD I = 0; I < fhHeader.dwBones - 1; I++ ) {
fbFrameBuffer.psvRots[I+1].fX = (FLOAT)fbFrameBuffer.psvRots[I+1].iX / 4096.0f * 360.0f;
</pre></code>
== Part IV: Qhimm’s Input==
Qhimm has taken the time to rewrite two of these functions used in decoding, so it is easier to understand for people who know C++ better than they know assembly (despite my comments being in the assembly code).
He has also written a more in-depth look at the logistics behind the rotation compression format and explains its limitations
// Collect one more byte from the stream.
dwNextStreamBytes = dwNextStreamBytes << 8 |
pStreamBytes[dwStreamByteOffset + 2];
// Shift the delta value into place.
sValue = (dwNextStreamBytes << (dwCurrentBitsEaten + 1)) >> 8;
{
unsigned int uType = GetBitsFromStream( pStreamBytes,
pdwStreamBitOffset, 3 ) & 7;
switch (uType)
{
case 0:
// Return the smallest possible decrement delta (at given
// precision).
return (-1 << nLoweredPrecisionBits);
// Read a corresponding number of bits from the stream.
int iTemp = GetBitsFromStream( pStreamBytes,
pdwStreamBitOffset, nBits );
// Transform the value into the full seven-bit value, using the bit
// length
// as part of the encoding scheme (see notes).
if (iTemp < 0) iTemp -= 1 << (nBits - 1);
case 7:
// Read an uncompressed value from the stream (at requested
// precision), and return.
iTemp = GetBitsFromStream( pStreamBytes,
pdwStreamBitOffset, 12 - nLoweredPrecisionBits );
return (iTemp << nLoweredPrecisionBits);
default:
encodings available for small deltas. The smallest 128 [-64,63] sizes of deltas
can be stored in compressed form instead of as raw values. This method is
efficient
since a majority of the rotational deltas involved in skeletal character animation
will be small, and thus doubly effective if used with reduced precision. Precision
First, a single bit tells us if the delta is non-zero. If this bit is zero, there
is no delta value (0) and the decoding is done. Otherwise, a 3 bit integer
follows, detailing how the delta value is encoded. This has 8 different meanings, as follows:
Type Meaning
------ -------------------------------------------------------
0 The delta is the smallest possible decrement (under the current precision)
1-6 The delta is encoded using this many bytes
7 The delta is stored in raw form (in the current precision)
The encoding of small deltas works as follows: The encoded delta can be stored
using 1-6 bits, giving us a total of 2+4+8+16+32+64 = 126 possible different
values, which during this explanation will be explained as simple integers (the lowest bits of the delta, in current precision). The values 0 (no change) and -1 (minimal decrement) are already covered, leaving the other 126 values to neatly fill out the entire 7 bit range. We do this by encoding each value like follows:
- The magnitude of the delta is defined as the value of its most significant
have a magnitude of 32. For simplicity, we also define the 'signed magnitude' as
the magnitude multiplied by the sign of the value (so '-2' has a signed
- When encoding a value, we subtract its signed magnitude; essentially pushing
everything down one notch towards zero, setting the most significant value bit
- The transformed value is then stored starting from its magnitude bit (normally,
you would have to start one bit higher to include the sign bit and prevent
When decoding, you only need to know the number of bits of the encoded value, use
