Topic: Spell Visual Effects

[avalanche]

Here is some information about how spell visuals are coded and animations stored in the ROM.  This would be pretty long for one post, so I will make a few, and link to them from this first as a little table of contents.

Table of Contents
1. Spell Visual Table
2. Sprites
3. Keyframe Animations
4. Frames for Animations
5. Master Routines

[avalanche]

SPELL VISUAL TABLE
--------------------------------
Starting with the spell visual table at 0F:A050 (ROM 7A250)
This is indexed by the spell visual number, but it starts with entry 1, not 0.
For most spells, this the same as the spell index.
For player summon spells though, these have already been mapped to the enemy
summon equivalent (values 4D..5D), which leaves an empty range which can be used
by items.  For example, FireBomb uses the entry where the player Chocb is,
and you'll also find LitBolt and the Crystal in this section.

  byte 0: Initial Palette index
  byte 1: Sprite "Page"
  byte 2: Keyframe Animation index (usually)
  byte 3: Master Routine index

Some extra details on those bytes.

byte 0: Initial Palette Index.
  Initial palette index for the keyframed sprite animation, if any.
  Some animations change their palette during the animation (e.g. Cure1),
  more on this later.  Note this is not used for background color effects
  nor for palette effects on the target monster or character.

byte 1: Sprite Page
  The game copies a span of sprites from the graphics in the ROM to somewhere
  the hardware can use them.  This byte represents a sliding and overlapping
  window of sprites to use, and animations later use sprite indices relative
  to this page.  Each value shifts by 8 16x16 sprites, and many visuals share
  the same page values even if they do not use the same sprites in the end.
  I think the animations can only reference around 31 sprites from the start
  of this page, so this can add +8, +16, etc to the indices.

byte 2: Keyframe Animation Index
  This is what you think of when you picture the "Fire1" animation.
  I think 00 means none, and FF would cause the entire visual to be skipped.
  It is important to note that this value is not always used,
  it is up to the next byte.

byte 3: Master Routine Index
  Ultimately points to an actual assembly routine that runs the animation.
  I call it the master because it runs mostly the entire thing, and
  may or may not even use the byte 2 keyframe animation at its discretion.
  For example, value 06 (used by Psych and Drain), 04/05 (used by Meteo, Comet),
  do not use the byte 2 animation.
  Or it could even run two keyframe animations, or precursor animations like
  White/Nuke, setup global effects such as shaking monsters for Quake.
  Summon routines often move their summon image around too.
  The simple ones like what Fire1 uses mostly just call a routine to run the
  byte 2 animation.
  I think an FF causes the entire visual to be skipped.


Note about Summon spells
  Summon spells 4D..5D (including player ones, as mentioned above) will have
  the party flicker out and the summon image fade in PRIOR to the master routine
  being called.  These are detected strictly by the visual index, and the summon
  to use is thus the visual index minus 4D, so Imp is the 0th summon.

[avalanche]

SPRITES
----------------------------------

The sprites for an animation are always 16x16 sprites.  These are composed
as usual of 8x8 graphic subtiles.  And as often is the case, there is
a sprite formation table used to share tiles and flip them horizontally or
vertically.

This table is located at 0C:F3C0 (ROM 675C0).

Each entry in the formation data is 2 bytes:

Code: [Select]

  byte 0: xxxxxxxx - low 8 bits of subtile index
  byte 1: VHxxxxxx - V = vertical flip, H = horizontal flip,
                     The other bits are the top 6 bits of subtile index

The subtile index is relative to the well-known spell graphics location at 638C0.

The data is layed out in virtual rows of 8 16x16 sprites horizontally.
So each "row" of 16x16 virtual sprites is like two rows of 8x8 sprites.

Code: [Select]

  (page 0):    Spr 0 TL, Spr 0 TR, Spr 1 TL, Spr 1 TR, ... Spr 7 TL, Spr 7 TR
               Spr 0 BL, Spr 0 BR, Spr 1 BL, Spr 1 BR, ... Spr 7 BL, Spr 7 BR
  (page 1):    Spr 8 TL, Spr 8 TR            ...           Spr F TL, Spr F TR
               Spr 8 BL, Spr 8 BR            ...           Spr F BL, Spr F BR
               ...

Each of the "Spr # corner" entries is 2 bytes in the format described above.

Before the master routine is called, the game uses the sprite page as a starting
point and composes a bunch of 16x16 sprites, converting to 4 bpp for the hardware.

Attached is an image showing the graphics in the ROM and the virtual sprites after they have been assembled into proper 16x16 sprites which will be referenced by the frames.

[avalanche]

KEYFRAME ANIMATION
----------------------------------

If the keyframe animation is used, here is how it works.

The keyframe animation index is looked up in a pointer table at 0F:D5E0 (ROM 7D7E0).
Add 70200 to get the resulting address in the ROM.

This points to an FF-terminated byte list.
The first 2 bytes are a header, and remainder are byte code for the animation.

Code: [Select]

  byte 0:  xxxxyyyy

xxxx = size code, sometimes overrides position too. See "Size Codes" below.
        yyyy = additional loop count (0 = one time through, 1 = two times through)

  byte 1:  Mvvssiii

        M  = If set, tells it to never mirror the animation.
             Normally the animation is mirrored if on the right side of the screen
             like targetting the party in a normal battle, or monsters when back attacked.
        vv = vertical alignment code.
             00: centered on target (e.g. Ice-2, many others)
             01: bottom of anim aligned to bottom of target (e.g. Fire1, Ice-3)
             10: center of anim at top of target? (only used by Charm?)
             11: bottom of anim at top of target? (only used by Float?)
        ss = Speed code.
             Technically looked up in a table at 0D:FFD9, but corresponds to:
             00: Slowest. 8 screen frames per animation frame (7.5 fps)
             01: 4 screen frames per animation frame (15 fps)
             10: 2 screen frames per animation frame (30 fps)
             11: 1 screen frame per animation frame (60 fps)
        iii= High bits used later to index frame data (See below).

  byte 2 and beyond are byte code for the animation, terminating with an FF.
  Bit pattern meanings:

    0xxxxxxx    Frame number iiixxxxxxx, where iii is from the header byte above.
                A frame of sprites will be presented (details below), and
                then a pause will occur according to the speed code.
                All other bytes from here below are executed without pausing
                until a frame is encountered.

    10001000 (88 hex) Special command. The NEXT byte is a parameter. See below.

    1xxx0yyy    Shift entire animation xxx direction by (yyy + 1) pixels.
                Several are often used in a row to move amounts greater than 8 pixels.

                xxx = direction:
                   000 down, left
                   001 down
                   010 down, right
                   011 left
                   100 right
                   101 up, left
                   110 up
                   111 up, right
                This may be visually more understandable:
                   5 6 7
                   3   4
                   0 1 2
                Example: F7 moves up and right 8 pixels.  Eight F7's in a
                         row move up and right 64 pixels (see Ice-1)

    1xxx1?yy    Enable palette effects on target monster or character.

                xxx = Palette.  Add 28 (hex) to get final palette index to use.

                ?   = Game checks this, but I believe there is a bug which
                      means it would never occur...

                yy  = Speed/Type of palette effect.
                      00: change palette and hold constant (e.g. stone anims)
                      01: fast toggle between new palette and normal
                      10: slow toggle between new palette and normal
                      11: cycle/rotate the specified palette (e.g. Ice-1, many)

                Example: CB used by Ice-1 enables a rapid palette rotation
                         of a bluish palette.

  When the byte is 88 (hex), the following byte is read and executed according to:

Code: [Select]

    bgr?0mmm    Enable background and monster color effects.
                Enables a complex effect that can also be controlled by
                the master routine.  The background and all monsters are
                affected by this.  I believe the specified color is
                effectively "added" to the BG and monsters with an alpha
                which is modulated over time depending on the mode parameter.

                bgr = Sets which color channels to use at full intensity.
                      Example: 100 is blue, 011 is yellow, 000 I think is valid for black.

                ?   = unused

                mmm = Mode.  The amount of the effect changes over time according to this.

                      000: Off. Disables a previous effect.
                      001: Toggle every other screen frame. (e.g. rapid red flashes)
                      010: Triangle wave. Starts at 100% and reduces to 0%, then
                           back up to 100%, down to 0%, and so on.
                      011: Flash for exactly 1 frame, then disables itself.
                      100: Increase from 0% to 100% and hold.
                      101: Decrease from 100% to 0% and hold (may actually disable, same thing)
                      110: Same as 010 I think, but there may be a
                           difference I haven't discovered.
                      111: (unknown)

    pppp1sss    Enable / Disable palette toggling for the sprite animation itself.
                Used by, for example, Cure1 to toggle between a bluish and greenish palette.

                pppp = Index of palette pairs.
                       Looked up at ROM B81C6. 2 bytes per entry: the two palette indices to toggle.
                       Interestingly, the second one is applied first.

                sss  = Speed code.
                       Technically looked up in a table at 03:F678 (ROM 1F878), but corresponds to:
                       000: slowest. toggle every 128 frames
                       001: toggle every 64 frames
                       010: toggle every 32 frames
                       011: toggle every 16 frames
                       100: toggle every 8 frames
                       101: toggle every 4 frames
                       110: toggle every 2 frames
                       111: toggle every frame
                       The table values are actually: {7F, 3F, 1F, 0F, 07, 03, 01, 00}


Size Codes

  The size code nibble in the animation header is both a size and sometimes a position override.
  The size code indexes into a table located in ROM at 7013E.  Each is two bytes:
    byte 0: width in 16x16 sprites
    byte 1: height in 16x16 sprites

Position Override by Size Code

  Normally, the position of the animation is near a target monster or character (see
  the vertical alignment above).  But certain size code values are also used by the
  code in a few places to set a global position for the animation (e.g. FireBomb, Quake).
  These are handled in assembly, not a table, but here are the ones I know of:

Code: [Select]

  code  position (left side)  position (right side)  Example
  ----  ---------             ---------              -------------
   3:   (60, 44)              (D8, 44)               Quake
   4:   (60, 44)              same as left, or N/A   Blitz, Wave, FireBomb
   5:   (80, 44)              same as left, or N/A   Indra
   D:   (60, 44)              (D8, 44)               Blaze, Fire
   E:   (60, 44)              (D8, 44)               ?
  * all numbers above in hex

  When these occur, the vertical alignment is ignored and the animation centers
  on the coordinates listed above.

  Note that at least one master routine sets a global position in assembly.  This
  is done by Bomb, to force a global position for the first time the animation
  is run on the summon image, then reverted so the second animation runs on the
  target monster normally.

[avalanche]

Frames for Keyframe Animation

  The 10-bit frame number indexes into a pointer table at 0F:DDE0 (ROM 7DFE0).
  Add 70200 to the pointer entries to find the final location in the ROM.

  The size/length of the frame is implied with the width and height from the
  header above.

  Each frame lists the sprites to use and how to flip them, in a type of RLE compression.

Code: [Select]

    RVHxxxxx

      R - If set, this is repeated.  The following byte indicates how many times to repeat.
      V - vertical flip
      H - horizontal flip
      x - the sprite index, relative to the sprite page as described above.
          When this value is 1F (all 5 bits on), then it is an empty slot
          instead of a sprite.  Empty slots can repeat too.

  Technically, the sprite index is looked up in a table at 16:FCCB (ROM B7ECB) to compose
  the real low-level sprites as the hardware needs them.  BUT as it happens, the quirky
  way this is done will happen to appear to us humans as a straight index from the sprite page.
 
  The sprite priority is supplied by calling code.  Quake for example changes the sprite
  priority so it shows under the monsters instead of above like most animations.

[avalanche]

MASTER ROUTINES
----------------------------------

Looked up in a pointer table at 02:EB76 (ROM 16D76).
Each points in bank 02; add 10200 to get the routine's location in ROM.

I will leave detailed analysis about each master routine for a separate post/document,
as each is a custom assembly routine, instead of a static data format.

Here is just a tiny fraction of memory locations that some routines use.

Code: [Select]

  $F2A0:  modifies how the animation sprites are positioned.
          00: None
              Used by most.
          01: Unknown
          02: Random
              At start of each loop, each sprite slot gets a random offset in the range -6..+9
              Used by Venom, Sleep, Digest, Nuke, White, Crystal...
              Specifically used by master routines: 02, 21, 25 (all hex)
          03: Totally custom tables of offsets and random additions,
              Used only by Fire3 (master routine 23 hex)
          04: The inward circles of Cure4 (master routine 29 hex)

  $F2D0:  some global effects?  I only know these:
          01: Used by Quake (and friends) to shake monsters
          02: ??
          03: ??
          04: used by Comet, Meteo to ??
          05: used by Stone, Beak, Petrify to ??
          06: Used by Bomb to override the global position.
          07: Used by Big Bang to ??

  Many setup background color effects by manipulating bytes that the animation can do above.

  Here are the routine numbers I found that do not use the keyframe animation,
  or do so in a special way.
    00    (Alert)
    04,05 (Meteo, Comet) - no keyframe animation, just custom code to move sprites
    06    (Psych, Drain) - no keyframe, just custom sprite code
    20    (Disrupt, Demolish) - no keyframe, just custom sprite code
    22    (Wave, Big Wave) - no keyframe, just custom sprite code
    26    (one of the Odins) - changes monster graphic and slides it
    27    (Big Bang) - does the animation, but has extra bg effects
    2A    (Glance) - only flashes screen
    2B    (Crush) - only flashes screen
    2D    (Gaze, Slap) - only flashes screen
    2F    (Blk. Hole)
   
    21,25 (Nuke, White, Crystal) - have a precursor animation run by code, then the keyframes

    And most of the Summon spells do a lot to manipulate the summon image, though some
    use a keyframe anim too.

[Grimoire LD]

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.

[avalanche]

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:

Code: [Select]

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:

Code: [Select]

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:

Code: [Select]

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:

Code: [Select]

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:

Code: [Select]

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:

Code: [Select]

--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 example
Finally, 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? 

[Grimoire LD]

You made it Much clearer, that was a legitimately enlightening post on spell effects, now I think I more-or-less fully grasp the way spell effects are drawn.

[chillyfeez]

Question for ya, avalanche... Is there any empty space in any of those data banks to create new spell animations without overwriting the existing ones?

[avalanche]

Question for ya, avalanche... Is there any empty space in any of those data banks to create new spell animations without overwriting the existing ones?

This is a great question, and I'm not sure how to answer.  It might be a challenge.  There looks to be around 320 bytes at the end of that bank (around 800C0 in the ROM).  That's not much for graphics, but is for the other kinds of data.  The graphics data needs to be contiguous anyway, but all those pointer tables let you go anywhere in the bank for each entry.

One thing I was thinking about is whether the ROM could be extended with an extra bank or two, because it might be a simple thing change where the code addresses both the tables and graphics.  Is that possible and/or frowned upon as cheating per se?

[chillyfeez]

Well, IMHO, there's no such thing as "cheating" when it comes to ROM hacking... but the problem with that idea is that FF4kster isn't compatible with expanded ROMs, so doing so makes many other Hacking endeavors a lot more tedious.

I wasn't really worried about new graphics anyway, just new animation routines. There are enough spell sprites in the game to work with, I think, that a few new animation routines would be enough for what I'd want to do. And I think this info, in that case, is exactly the kind of stuff I tried to figure out a year ago. So, thanks!

[avalanche]

I just skimmed through a little bit more of bank 0F (78200 in ROM), and there are several spans of FFs that I would assume to be unused (can't be entirely sure though).  I stopped counting after like 3 KB.  So there should be no problem adding everything but graphics.

Also there is an unused section just before the graphics that would fit a reasonable number of new sprites, if you were able to shift the entire set of graphics forward and change the assembly to match.  I'm not sure there is only one place where it is addressed.  It would not surprise me if there were some places hardcoded to find a sprite directly.   But it may be worth a shot for those interested in adding extra graphics.

It's also a little bit of a shame when there are sprites only used by one spell, by one monster, in one battle in the game.  Globe199 and Counter come to mind.

[chillyfeez]

Funny you should mention Globe199.
One thing I want to do specifically is make a gravity spell that uses Globe199's sprites, but something like Cure4's animation.
The hack I'm working on brings the Gravity and Air spells into the mix (as blue magics), and while I have assigned graphics to those spells, this info should help me improve on what I have now.