A slickproductions.org /forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=printpage;topic=1991.0 e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index385c.html slickproductions.org /forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&topic=1991.0 e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index385c.html.z x 5g^ Ћ h OK text/html ISO-8859-1 gzip @ h Tue, 10 Mar 2020 06:54:03 GMT 0 0 P 5g^ . h
Print Page - Spell Visual Effects
Board of Slick
Library of the Ancients => Final Fantasy IV Research & Development => Topic started by: avalanche on December 27, 2014, 03:41:16 PM
Title: Spell Visual Effects
Post by: avalanche on December 27, 2014, 03:41:16 PM
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.
Title: Re: Spell Visual Effects
Post by: avalanche on December 27, 2014, 03:42:59 PM
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.
Title: Re: Spell Visual Effects
Post by: avalanche on December 27, 2014, 03:45:29 PM
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.
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.
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.
Title: Re: Spell Visual Effects
Post by: avalanche on December 27, 2014, 03:48:16 PM
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:
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 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.
Title: Re: Spell Visual Effects
Post by: avalanche on December 27, 2014, 03:49:14 PM
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.
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.
Title: Re: Spell Visual Effects
Post by: avalanche on December 27, 2014, 03:51:07 PM
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.
$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.
Title: Re: Spell Visual Effects
Post by: Grimoire LD on December 27, 2014, 06:15:11 PM
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.
Title: Re: Spell Visual Effects
Post by: avalanche on December 27, 2014, 08:04:55 PM
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:
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:
--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?
Title: Re: Spell Visual Effects
Post by: Grimoire LD on December 27, 2014, 09:28:35 PM
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.
Title: Re: Spell Visual Effects
Post by: chillyfeez on December 27, 2014, 10:08:38 PM
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?
Title: Re: Spell Visual Effects
Post by: avalanche on December 27, 2014, 10:28:35 PM
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?
Title: Re: Spell Visual Effects
Post by: chillyfeez on December 27, 2014, 11:21:10 PM
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!
Title: Re: Spell Visual Effects
Post by: avalanche on December 28, 2014, 09:32:07 AM
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.
Title: Re: Spell Visual Effects
Post by: chillyfeez on December 28, 2014, 02:02:11 PM
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.