This is pretty fantastic information, yet can you give an example or two of how these correspond to the Sprite/Sequence/Effects portion of a Spells data? Maybe it's plainly there, but when it comes to graphics I'm not that bright.
Sure thing. Let's try Ice-1, which is what I used for my first dive into all this. I will try to stick with hex numbers.
Ice-1 is spell 20, and since it is not a summon spell, it uses the same spell visual index. Since the visual table starts with 1 instead of 0, it is really index 1F into the visual table.
The visual table entry for 20 (aka 1F if 1-based):
08 01 0B 00
Broken out:
08 - initial palette index for animation
01 - sprite "page"
0B - keyframe animation index
00 - master routine index
The palette is easy. It is simply palette 08, in the palette table at 74D00 in ROM. This spell doesn't alternate palettes either, so this is the only palette for the animation itself.
The "sprite page" is 01. Take a look at the graphics attachment I posted a few back. On the left side are the 8x8 graphics as they are in the ROM. The game (before it calls the master routine) copies out a range of these 8x8 graphics and converts them into 16x16 sprites to actually display. The sprite assembly data is in ROM at 675C0. Just take my word that each "page" is worth 64 (decimal) bytes in this table, so for Ice-1's page 01, we start at 67600. Which looks like:
67600: 20 00 21 00 22 00 23 00 24 00 25 00 26 00 27 00
67610: 28 00 29 00 2A 00 2B 00 2C 00 2D 00 2E 00 2F 00
....
For all the details in the bit meanings, look at the original posts. I'll just show the ultra basics here. The first entry (20 00) has neither H nor V flip bits, and has subtile index 20. If you look at that same attachment, and count each 8x8 subtile left-to-right, you will see that 20 (hex) is the top-left corner of the smaller heart in the second row. Somewhere in that second row, the left and right sides of that image start to diverge, and it's actually where Ice-1's frosty sprite in the middle of that second row start to use previous graphics and H and/or V flip them.
Short Cut, if you are not as interested in how this part works, or don't want to try to add MORE sprites. The "sprite page" as I called it corresponds to the row number in the RIGHT side of that attachment. I scripted all this craziness to make the visual aid. Page 01 starts with the second row. You only have 5 bits to reference sprites later, so you basically can access about 4 rows starting from the row specified in the sprite page. Look at the right side: you can find all the sprites used by Ice-1's animation within 4 rows of row 01 - in the middle of row 01, as well as the first sprite in row 04.
Just to nail the point home, the sprite page doesn't specify THE sprites to use in an animation, but a group from which you can later choose. That is why so many spells share the same values for this byte.
The Master Routine index (00) is looked up in the pointer table at 16D76, resulting in an assembly routine at 02:F30A (or 1750A in ROM). Again I won't go into too many details, but know that this is one of the simpler routines, in that it basically just runs the keyframe animation specified.
The Keyframe Animation (0B) is used for this spell via the master routine. It is looked up in a pointer table at 7D7E0 in ROM, resulting in bytes (31 D7) or final address of 7D931 in ROM. Here is the entire FF-terminated sequence at that address, for Ice-1:
62 30 CB F7 F7 F7 F7 F7 F7 F7 F7 4F 87 87 87 87 50 87 87 87 87 51 4F 50 FF
The first two are headers as described above, broken down as:
62 - header byte 0
broken down by nibbles:
6: size code 6. Look that up in the table specified before, this is a 4x4 animation with no special position.
2: total loops are 2+1, or 3.
30 - header byte 1
broken down in more complex bit groups:
M vv ss iii
0 01 10 000 (30)
M (0): normal mirroring, so it is mirrored when cast against players
vv(01): bottom alignment. hard to see for this example spell, but it is bottom-aligned on the target.
ss(10): animation speed (looked up in table) this runs at half the 60hz screen frame rate
iii(000): high 3 bits for frame, used below.
Now all the bytes after those 2 describe what to do for the animation:
CB = 11001011, matches the pattern:
1xxx1?yy which enables palette effects on the target monster/player.
The palette is x + 28, so 2C which is shades of blue.
The type of effect (y) is 11 (binary) which is a rapid rotation.
Watch Ice-1 being cast on a monster, and their palette goes nuts
with blues and whites. This is why.
F7
F7
F7
F7
F7
F7
F7
F7
Each F7 is:
11110111, which matches the pattern:
1xxx0yyy which moves the animation.
The direction is specified by x, which is up-right in this case.
The amount to move is y + 1 pixels, so 8 pixels.
Because there are 8 of these, it results in 8 x 8 or 64 pixels up and right.
Because we haven't even displayed any sprites yet, the FIRST frame
will be up and to the right of the target... which Ice-1 does if you watch it.
4F
Hey this is a frame, because the top bit isn't on.
It will look up frame 4F and put sprites on the screen.
87
87
87
87
Like F7, 87 moves the animation
10000111, pattern:
1xxx0yyy
Each 87 moves it down and to the left 7+1=8 pixels,
so the four of them move it a total of 32 pixels down and left.
50
Another frame, becaue the top bit is not on.
Then we display frame 50.
87
87
87
87
Move down and left 32 pixels again.
51 Frame 51
4F Frame 4F
50 Frame 50
Now let's look at just the first frame, 4F. We need the top 3 bits from the header byte, which are 0, so the final frame index is still 4F. Look up in pointer table from original post, results in address of 7F649 in ROM. Here are those bytes:
9F 02 10 03 1F 10 23 24 1F 03 30 1F 03 1F 10 1F
(row 1)
9F 02 - 2 blank slots
10 - sprite 10
03 - sprite 3
(row 2)
1F - blank slot
10 - sprite 10
23 - sprite 3, horizontally flipped
24 - sprite 4, horizontally flipped
and so on..
Refer to the original post that describes the RLE compression and bit meanings.
For brevity, let me show you just the blanks and non-blanks:
--XX
-XXX
-XX-
X-X-
See the attached image where I hastily scribbled a grid over the first frame of Ice-1's animation, and you can see the pattern of X's above in it, not to mention the palette effect that is setup by that CB byte in the animation byte code sequence, AND the fact that it is 64 pixels up and to the right of the target.
One sprite exampleFinally, because this is SUPER LONG (Sorry) let's just look at one of the sprites used. The bottom-left sprite comes from the byte value 03 in the RLE data above. That is just sprite 03 with no flip flags. (After looking up in the annoying ROM table...) that is sprite index 3 from "sprite page" 1. So look at the right side of that attachment from my original post. Look 3 sprites after where row 01 starts, and you'll see the snowy sprite that appears in the bottom-left of the Ice-1 image attached to this post!
Whew! I didn't make that any clearer, did I!? Maybe?