Spell Graphics Document

So, for my romhack, I had to dive deep into the world of custom animations. Like, all the way. And that meant a lot of time staring at this thread in confusion. I'm gonna try to explain in my own words what I did to pull off my lone custom attack graphic. Hopefully this can help other people make more sense of this and custom graphics can be a more viable option for modders.

Code:

0x107F8F: Magic graphic data
14 bytes per spell

This is simply the spell animation data you'd change in FF3usME, so if you want to modify that stuff in the hex editor without opening usME, there you are.

What we need for custom animations is the number for the spell animation, which you can get from either usME or the D0 animation script doc. Get that number, multiply it by six, and that's the offset in D4/D bank. For example, I was modifying Rippler:

Code:

Rippler = $0192

$192 x 6 = $96C

Rippler offset is D4/D96C

In this bank are all the attack animations, and at that offset for Rippler there are six bytes.

Code:

05 F4 B3 07 01 01

Byte 1 - Number of animation frames (range from 00-3F)
Byte 2 - Graphic set to use
Byte 3&4 - Graphic mold to use
Byte 5 - Width
Byte 6 - Height

So here's where my struggles began - contrary to what OP said, I found that changing Byte 1, or Byte 5 or 6, had little or no effect on my new attack. That being said, my animation is a single frame. 

To see if the problem was OP's documentation or my methodology, I tried modifying Fire by changing these Bytes - changing Byte 1, Fire had the same animation script in terms of how the graphic moved, but only the first frame of Fire as shown in the OP displayed. Changing the width and height did not affect the graphic itself, but it did affect Fire's alignment when it displayed. 

So, I think that Width and Height do NOT refer to the animation itself, but the animation's position relative to the rest of the screen. I say I think because changing those values on my graphic had no effect whatsoever. It may be that they're only applicable for graphics with more than one frame, or depending on the animation script, I don't know.

Anyway, if you just want to change a spell's graphics to another spell, like saying, if you want to turn Rippler into a new attack that uses the Missile graphic, find the D4/D offset for Missile and copy those six bytes over Rippler. Voila, Rippler's graphics are changed to Missile. You'll still have to actually edit the animation script in D0 bank, as-is now you just have Rippler's animation but instead of the orbs that spin around Strago, it's the Missile graphic.

For fully custom graphics...ugh. That's where it gets "fun".

Now, the OP says that the method for effect 3 is different in terms of the offsets used and how you get to them. I did not do anything with effect 3 graphics, so I can't help there, but it seems similar to the effect 1 and 2 methods, just with different numbers. Anyway, the second byte in the six-byte string we got is what determines the actual graphic being loaded, so you can change that get your graphic loaded. How that byte loads the spell graphics, I don't know. Rippler's graphics are located at approximately D4/7D60 if you open a rom in yy-chr, but I can't see any obvious way the game loads data from that address. But, if you're editing a pre-existing graphic into something new, you can of course use the same offset and it'll load, though you may have to increase or decrease the digit a little depending on the exact location.

Take the second byte from your six-character string and multiply it by $40 to get an offset in D2 bank. There you'll find a string equal to the length of your byte 1 times 2, because each byte is 2 digits. Again using Rippler as an example:

Code:

$F4 x $40 = 3D00

Rippler graphic offset is D2/3D00.

As OP says, there will be two-byte pairs here that are essentially pointers to load your graphic. The game draws graphics in 2x2 squares each 8x8 pixels large (if you're using yy-chr, this can make visualization easier for you since it edits in the same). And this is where you'll have to play around a bit and use trial and error to figure out how to load the graphic you want, because it is not obvious and again, there's not a direct correlation as I can tell between the address of the graphics in the rom and the bytes used here to load them. But if you play around, you'll get what you want.

What I CAN tell you to help you is that the second byte in each pair, the first digit can be used to flip/rotate the 2x2 square. It seems to be even numbers that do this, odd numbers glitch up, but it's like every other even number - 2F and 4F seem to have the same effect, for example, while 6F and 8F have a different effect that they share. There may indeed be a difference, more testing would need to be done. Anyway, here you can build out your graphic in those 2x2 chunks.
Next comes the graphic mold - just like enemy sprites in battle formations, graphic data needs the proper mold or it won't display right. For that we look to bytes 3&4, which for Rippler is B3 07. That's the hex value offset so flip them as you do, and we get $7B3. Multiply that by 2.

NOW, here's where OP may be wrong - they say to add 14DF36 to the result to get the offsets of the pointers. This seems to be wrong - I believe you want to add 14DF3C to the result. But I may be wrong here too, if you've made it this far I'm sure you understand this is confusing. Play around with the data here and see how it affects the spell you're editing. Anyway, wherever you end up, if you're in the spot you should be, there will be more two-byte pairs, which are pointers to molds for the graphic. For Rippler, this is either D4/EE9C or D4/EEA2, depending on if OP or I are right.

However long the first byte was in the six-byte string we originally got, that's how many pairs you're looking for here. ie, 14 in byte 1, you want 14 pair. Each pair is a pointer to a spot in the D1 bank for the animation mold, so reverse them and away we go.

Code:

D4/EE9C: E7 A2 EB A2 ED A2 F1 A2 BF 0D

D1/A2E7 is our first destination, followed by D1/A2EB, etc. AGAIN, OP or I may be wrong about the addresses for the pointers and thus where exactly in D1 you want to begin, but again, play with stuff and you'll find something that breaks your spell, which is how I found my way around. This is why you keep backups!

In the D1 bank are yet-more two byte pairs that position each chunk of your graphic on the screen. This is complicated to explain (lolrly) but if you go to existing spell effects, you'll quickly see a pattern emerge: "WW ZZ", "XX YY", where XX is one higher than WW and YY is probably one off from ZZ, possibly with a C to flip it. The XXnumber is the position of the chunk of graphic, the YY number is an off-set of some kind. Draw out the pattern for your graphic, end the script with FF FF, and test it out.

If you want a spell to be larger than it is in the vanilla, it seems to be as simple as adding more byte pairs; I was creating a duplicate of Scar Beam that was the length of the screen, and Scar Beam's pattern went down on an angle: "82, 92, A2 / 93, A3, B3 / A4, B4, C4", etc (not exactly but you get the idea). To make the beam longer, I just kept going; B5, C5, D5, etc. Further, while they're mostly in order it doesn't seem like they need to be, which makes sense: if graphic data is being assigned to A4, the code probably doesn't care if the command is before 82 or after 94 or whatever. But again, I may be wrong.
----------------------
I'm sorry I can't be as thorough and insightful as preferred, at times I barely understood what I was doing myself, but in the end, I was able to copy Scar Beam's graphics into Rippler's place and duplicate Scar Beam animation but with a longer, thinner beam, by more or less following the OP and figuring out the methods I've described. The only other advice I can give is that when in doubt, play with shit until something breaks - as I've said before, OP seems to be wrong in some places and I may be as well, so if you can't find your string of bytes that are your graphic mold pointers, just copy/back-up the area, start blanking out lines, and try out your graphic until it glitches up, then you can narrow it down some.

So, there you are - how to make entirely new graphics for spells. It ain't clean, it ain't easy, but it can be done. I eventually stumbled my way to success, and if I can manage, anyone can.