Help with animation frame data

The Battle Animation Frame Data table (D10141) holds information about which 16x16 tiles any battle animation is going to use, in the form of frames.

Let's take a look at the frame data for the Flail animation (D104B3):

02 0C 12 0D 02 04 12 05 22 06 02 02 12 03 12 0E 22 4C

Each 16x16 tile is made out of two bytes. First byte is the tile's position in the frame and the second one is it's index in the current tile formation (Flail uses a tile formation located at D20940).

Here's a diagram of what these bytes look like, in their order:



As we can see, there are 4 frames being used. Two for the Flail in different positions and two for the swipe effect. Also, the second frame uses 3 tiles (6 bytes), and all the other frames uses 2 tiles (4 bytes). That means that the amount of tiles used in any frame varies. The problem though, is... where is this data at? Where do I find how many tiles is each frame going to use in each animation? I've been messing around with these battle animations for many hours right now, and I still couldn't find this piece of information.  

The animation frames are stored sequentially, so one frame ends when it reaches the beginning of the next frame. Following your example, the frame pointers for the flail animation are at D4/E072:

Code:

B3 04 B7 04 BD 04 C1 04 C5 04

So the first frame is D1/04B3 through D1/04B6, the second frame is D1/04B7 through D1/04BC, etc.

Another way to terminate a frame is by including the 2-byte value FF FF.

If you want to see this in a disassembly, the subroutine for loading a frame is at C1/9F61 for BG1 threads and C1/A0C6 for sprite threads (the data is stored the same way for both BG1 and sprites, they just get loaded differently).

This is going to sound incredibly stupid, but how does the Tile Formation get converted into a 16x16 tile for use in the frame? I can't seem to find any information on this anywhere, and the hex values aren't any help either.

For instance, at the aforementioned D20940 we have 64 bytes...
19 03 1A 03 1B 03 1C 03 15 00 1D 03 1E 03 1F 03
20 03 21 03 22 03 23 03 24 03 25 03 26 03 15 00
27 03 28 03 29 03 2A 03 2B 03 2C 03 15 00 15 00
2D 03 2E 03 15 00 15 00 15 00 2F 03 30 03 15 00

This is the tile formation $25, the one associated with the Flail as expressed in the first post. How does Block ID 0x0C translate into that first 16x16 tile in the picture, the one that makes up the handle of the flail in the very first frame?
As far as I can tell, that handle is formed using the 8x8 tiles 33 03, 34 03, 3B 03, and 33 C3. But... I don't see those four lining up in this tile formation. The numbers are somewhat close to each other BEYOND the tile formation, but not within the 64 bytes allotted to it. Moreover, even with their actual presence at D20990, D20992, D209B0, and D209B2, there's a 32 byte gap and there doesn't seem to be any correlation to that 0x0C that the frame data declares is its Block ID. How the heck does this work?

This is going to sound incredibly stupid, but how does the Tile Formation get converted into a 16x16 tile for use in the frame?  I can't seem to find any information on this anywhere, and the hex values aren't any help either.

For instance, at the aforementioned D20940 we have 64 bytes...
19 03 1A 03 1B 03 1C 03 15 00 1D 03 1E 03 1F 03
20 03 21 03 22 03 23 03 24 03 25 03 26 03 15 00
27 03 28 03 29 03 2A 03 2B 03 2C 03 15 00 15 00
2D 03 2E 03 15 00 15 00 15 00 2F 03 30 03 15 00

This is the tile formation $25, the one associated with the Flail as expressed in the first post.  How does Block ID 0x0C translate into that first 16x16 tile in the picture, the one that makes up the handle of the flail in the very first frame?
As far as I can tell, that handle is formed using the 8x8 tiles 33 03, 34 03, 3B 03, and 33 C3.  But... I don't see those four lining up in this tile formation.  The numbers are somewhat close to each other BEYOND the tile formation, but not within the 64 bytes allotted to it.  Moreover, even with their actual presence at D20990, D20992, D209B0, and D209B2, there's a 32 byte gap and there doesn't seem to be any correlation to that 0x0C that the frame data declares is its Block ID.  How the heck does this work?

If I understant your question correctly:

Tile formation entries works like this:

00 00 00 00 01 01 01 01 02 02 02 02 03 03 03 03
04 04 04 04 05 05 05 05 06 06 06 06 07 07 07 07
00 00 00 00 01 01 01 01 02 02 02 02 03 03 03 03
04 04 04 04 05 05 05 05 06 06 06 06 07 07 07 07


Tile $00 is formed by the first 4 bytes of the first line and the third line.
Tile $01 is formed by the next 4 bytes of the first line and the third line, and so on.

Tile $04 is formed by the first 4 bytes of the second and fourth lines.

I hope the colors help you, lol

---

Also, another important thing is that even if an animation uses tile formation $21, for example, it can still access tiles from the formation $22 an onwards. It can access those tiles using the indexes of $08 and above. I think it can access tiles up to $3F, but I haven't tested this specifically.

Also, another important thing is that even if an animation uses tile formation $21, for example, it can still access tiles from the formation $22 an onwards. It can access those tiles using the indexes of $08 and above. I think it can access tiles up to $3F, but I haven't tested this specifically.

To clarify the number of tiles that are accessible for different types of animation threads, here is my message copied from the Discord server:

Sprite and BG3 threads load 4 rows, BG1 threads load 5 rows (including weapon "hit" threads), Weapons load the parry/block graphics into the first row and the weapon into the next 3 rows, and espers load 5 rows for sprite threads and 6 rows for BG1 threads. Each "row" of the tilemap has eight 16x16 tiles which is 32 8x8 tiles.

So weapons can only use tiles $00 through $17. If you use a tile beyond that I think it will draw damage numerals instead, but I could be wrong so please double check.

If I understant your question correctly:

Tile formation entries works like this:

00 00 00 00 01 01 01 01 02 02 02 02 03 03 03 03
04 04 04 04 05 05 05 05 06 06 06 06 07 07 07 07
00 00 00 00 01 01 01 01 02 02 02 02 03 03 03 03
04 04 04 04 05 05 05 05 06 06 06 06 07 07 07 07


Tile $00 is formed by the first 4 bytes of the first line and the third line.
Tile $01 is formed by the next 4 bytes of the first line and the third line, and so on.

Tile $04 is formed by the first 4 bytes of the second and fourth lines.

I hope the colors help you, lol

---

Also, another important thing is that even if an animation uses tile formation $21, for example, it can still access tiles from the formation $22 an onwards. It can access those tiles using the indexes of $08 and above. I think it can access tiles up to $3F, but I haven't tested this specifically.

Yeah, I was seeing the 8x8 tile positions I was seeking split by an entire sixteen byte line, and I was puzzled why there was this other tile line interleaved in the middle.  The colors do help.  It did describe the limit as $3F on the one wiki page, which was muddling me, but being able to load beyond a start point makes sense in this context (the event script works the same way; anything beyond CA0000).

Yeah, it's a mess lol. I think they made it so complex in order to squeeze all of these graphics into a 3MB ROM chip. The "block ID" in frame data chooses one of the 16x16 metatiles from the 2bpp or 3bpp tilemap (a.k.a. tile formation). You can view the tilemaps in FF6Tools under Ability -> Attack Tilemap (2bpp or 3bpp). Now, there are way more than 64 tiles in each tilemap, and that's because only a small subset of these tiles actually gets loaded into VRAM for each animation. This is determined by byte 1 of the attack graphics data: https://www.ff6hacking.com/wiki/doku.php...phics_data. If you view the attack tilemap as rows of 16x16 tiles with 8 tiles in each row (as it's shown in FF6Tools), then byte 1 of the attack graphics data is the index of the first row of tiles that gets loaded into VRAM, and loading 8 rows would give you 64 tiles.
However, it never actully loads the full 8 rows into VRAM. Sprite and BG3 threads load 4 rows, BG1 threads load 5 rows (including weapon "hit" threads), Weapons load the parry/block graphics into the first row and the weapon into the next 3 rows, and espers load 5 rows for sprite threads and 6 rows for BG1 threads. Again, each "row" of the tilemap has eight 16x16 tiles which is 32 8x8 tiles.

Pasted for posterity from the Discord, since the conversation there moved on before I even got a chance to see this response.
I was aware that changing Layer 1 of the animation data could change which attack graphic tiles were used, as I've swapped the draw weapon of spells before (to make Swdtech use the left-hand graphics, actually).  I achieved the result through trial and error, though, so it's good to know that it's actually legitimately how the system is supposed to work.

Weapons loading parry graphics as the first row has me a little perplexed, though.  Does that mean that block graphics can be called by frame block data, and if so, what values would do so?  The flail example at the start of this thread is using 16x16 blocks within the first eight definitions; wouldn't those have been replaced with shields, cloaks, and blocking dogs?  Or is it loaded at the bottom end, calling those blocks for $18-$1F?  I'll have to twiddle around with that to see, might be nice to set up some shield bash weapons.