Help with animation frame data

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.