*.SEQ file format and the ongoing problem

[qullicube]

For the last few days, after I read melonhead's FFTPatchers source code, especially ShishiSpriteEditor. I was able to get a picture of file structure that final fantasy tactics used. Now the problem is there are excessive information inside .SEQ file. For example, the format of this file is as follow:

Explanation (Skip this part if you know how it works):

.SEQ
Hexdecimal
0x00 - 0x02 : Unknown (probably some file identity, doesnt matter really)
0x02 - 0x04 : Unknown (I don't know this part, doesnt matter)
0x04 - 0x406 : Offset of each animation sequence, 4 byte each (for e.g. Jumping with facing South is an animation sequence no.48 ---- Refer to http://ffhacktics.com/wiki/Animations (the index in wiki is not totally correct, We have to divide by 2 because one action comes in a pair of facing-West and facing-South)
0x406 - end : We use the above Offset to find each animation sequence. (0x406 + offset to find position in file where the animation starts)


The format at which animation is store is in 2 byte pair. For example, I found first offset to be 0 and the second offset to be 2, so (0x406 + 0 = 0x406) and (0x406 + 2 = 0x0408). To find my first animation sequence, I'll have to look from 0x406 to 0x408.

Now at 0x406 - 0x408 I might found, let's say, 08 00, or 0x0800. If you have learn some hexdecimal, you'll know that two digit of hex represent 1 byte. Therefore, here is my 2 bytes ---- 08 00

What the first byte means is the index of your frame. When you load your spritesheet, from .SPR, it will load the whole spreadsheet of bmp image (look on custom sprite in front page and try .BMP, it appears to be a full sheet of sprites). Now, what FFT did is it has a .SHP (or Shape) file that crop out various locations on spritesheets and combine them into a character frame (for e.g. Walking may use 6 character frames, when played, will display an animated walking sequence).

When you have done your cropping in specific order according to .SHP file, the order of character frame produced will match perfectly with the index used in first byte of the animation sequence data in *.SEQ file. For example, 08 00 would look at index 8, which is a Standing-facing West frame.

The second byte represent the delay of that frame. When raising hand, for example, the frames that represent raising-action would be faster than the frame that represent raised hand. This is used to produce non-linear animation (each frame have different delay). Now, in our example, 00 is our second byte, this means that there is no delay. This is implicitly used for an animation sequence that consists of only 1 frame, such as Standing.


Problem:

Now, the problem starts when not all part of animation sequence data follow the 2 byte frame format. In Shishisprite Editor, the author make the program ignores part of the data: the one that begins with 0xFF.

For example, I may have a data read such as 08 04 09 04 FF D5. Now if I load everything according to 2 byte frame format, then I would get 3 frames with last one having FF (or 255) index. However, character frame at index 255 is a character with only its head--- which makes the animation appears flaw. Therefore, 0xFF must not be an animation frame.

On the other hand, there are some 0xFFs that takes more than 2 bytes! For example, when you see FF EF, it will always be accompanied by an extra byte before the real 2 byte data. Like FF EF 02 09 04.... 02 may or may not be appropiate index, but I tested it visually and it isn't. This also ruins the 2 by 2 format of the bytes. Therefore, what the author did is skip it by 1 byte after seeing 0xFF accompany with 0xEF.

Now, the author must specify all the skip, which he does by looking at the byte after 0xFF and pre-programmatically determine which 0xFF byte should be skip by X, where X is discovered through observation (same as how I found it). Now, the meaning behind this 0xFF can be quite predictable.

Well, why should the creator put it there if it is going to be ignore? Certainly, it must means something. After some observation, I found out that 0xFFD5 appears after almost every sequences (except for one that is single frame and few others--- 08 00 for e.g.). Now, the first conclusion that I come to is 0xFFD5 must means end of animation. However, I found some sequence like jump doesn't have this one. Therefore, further observation led me to conclude that it must be some command for Looping.

I kind of guess that some of the 0xFF sets are apply to the sequence after it, for example FF EF 02 08 04 would means FF EF 02 apply to frame 08 04.

Then, I went further in, by viewing the real animation (directly from game via youtube) and compare with the byte sets:

0xFFD5

Looping (i guess)

0xFFCB
Specify start/end of vertical motion (upward only)? used in jumping sequence & levelup sequence, after the character suppose to launch itself into the air.

Comment: I saw the code sometime use it singularly or other time use it as a pair. It might means start------some vertical motion ------ end.

0xFFCF
Specify start/end of downward vertical? similar to 0xFFCB? it is used similarly like 0xFFCB

Comment: This might not be a vertically downward, but in level-up sequence. The jumping-up motion is sandwich in by 0xFFCB while the falling-down motion is sandwich by 0xFFCF.

0xFFEFXX where XX is optional byte
Specify offset of character vertically, and use XX as signed byte (concern negative). For example 0xFFEF02 would be offset of (0,2).

If drawing normally is at (0,0), then I would have to add (0,2) to it

Comment: These are always sandwich in between 0xFFCB pairs and 0xFFCF pairs ----

0xFFF0XX where XX is optional byte
Specify offset of character horizontally (in similar way as 0xFFEFXX)


There are about 20 more such as 0xFFCC and 0xFFD0 which seems to be randomly used on sequence such as getting-hit (which is seemed to be one frame, but actually consist of 2 frames) or Standing sequence

(try open latest ShishiSprite editor -> Animation and you'll see index 12-17 sequences being play with more than 1 animating frame, while all the frames have the same image)


Therefore, I believe these are some kind of scripting command that is done by the maker. If there is a resource out there, or anyone who already discovered all the commands, please point me to them, because I really desire to figure all these out, or else I will have to painfully discover them one by one...

[Pickle Girl Fanboy]

I've nothing to contribute to this except that you should contact Archemaic and check the wiki.  And this is way over my head, but thanks for sharing instead of keeping it to yourself.