"Extracting" Battle Animations from Game

Your ROM version is 1.xx, where xx is the byte at 0xFFDB. I'm assuming you're using the English version.

For version 1.0, at 0x13175 change 0x48 to 0x60
For version 1.1, at 0x13172 change 0x48 to 0x60

The other two changes are the same for both versions. Make sure you have your character in the first party slot, and make sure the battle is a normal attack (not a back attack, etc.).

0x2cf17 -> change 0x70 to 0x00
0x2cf03 -> change 0x44 to wherever you want the vertical offset to be

Your ROM version is 1.xx, where xx is the byte at 0xFFDB. I'm assuming you're using the English version.

For version 1.0, at 0x13175 change 0x48 to 0x60
For version 1.1, at 0x13172 change 0x48 to 0x60

The other two changes are the same for both versions. Make sure you have your character in the first party slot, and make sure the battle is a normal attack (not a back attack, etc.).

0x2cf17 -> change 0x70 to 0x00
0x2cf03 -> change 0x44 to wherever you want the vertical offset to be

Ah, great! That did it! Thank you so much!

---

My next question: Is it known what the math is around out the output color for, well, specifically for Aqua Rake but for things generally?

I've been reading some of the math on alpha compositing and it's thankfully not rocket surgery. In these individual frame captures, the main bubble color against the off-white background is RGB(255,255,255), which assuming I understand the math correctly -- a big assumption! -- shouldn't be possible. That leads me to believe it's doing something other than alpha compositing. And when I do the math based on the Wikipedia article using the gray and the brown backgrounds (it's a "two unknown variables, two equations" situation), I get that the blue value is negative. I would have assumed that meant I did something wrong if not for the maxed out values in the off-white frame.

Straight addition doesn't work out either. The foreground/background differences of the three channels of the gray and brown are within 1/255 of each other, as are the pink's red and blue channels, but the pink's green channel difference is 5/255 off the gray's and brown's red channel.

https://en.wikipedia.org/wiki/Alpha_compositing
https://stackoverflow.com/a/11163848
https://keithp.com/~keithp/porterduff/p253-porter.pdf

---

Those screen captures are from before I fixed those byte values.

---

Interesting. So as I was looking at various abilities in online videos, I'm realizing that for some (such as Ice 2) the background is totally obscured by the effect while the effect is rendered with transparency over the target. It's fascinating.

A lot of graphical effects in these animations (including transparency) are done using the SNES hardware. This means it’s a little different from techniques that are used for modern image manipulation (like alpha compositing).

The SNES has two “screens”, the main screen and the sub screen, and 4 background layers (plus sprites) that can be enabled or disabled in each screen. For transparency, the SNES has hardware color addition and subtraction, but no alpha channel. The color math is either full addition/subtraction where colors values from the two screens simply add or subtract to generate the final color (clamped between min and max), or half addition/subtraction where the color values are halved after adding or subtracting. The most common color math for transparency is half addition (I think this is what aqua rake uses). This seems like a pretty good reference: https://wiki.superfamicom.org/transparen...alving)-17

If you want to “rip” the animation, id suggest using the Mesen emulator which allows you to view each layer and both screens separately before any math operations are applied. Also keep in mind that the SNES uses 15-bit color, and the emulator converts the rendered output to whatever your computer screen uses (likely 32-bit color). There is some rounding that occurs during this conversion, which can lead to discrepancies like what you are seeing.

A lot of graphical effects in these animations (including transparency) are done using the SNES hardware. This means it’s a little different from techniques that are used for modern image manipulation (like alpha compositing).

The SNES has two “screens”, the main screen and the sub screen, and 4 background layers (plus sprites) that can be enabled or disabled in each screen. For transparency, the SNES has hardware color addition and subtraction, but no alpha channel. The color math is either full addition/subtraction where colors values from the two screens simply add or subtract to generate the final color (clamped between min and max), or half addition/subtraction where the color values are halved after adding or subtracting. The most common color math for transparency is half addition (I think this is what aqua rake uses). This seems like a pretty good reference: https://wiki.superfamicom.org/transparen...alving)-17

If you want to “rip” the animation, id suggest using the Mesen emulator which allows you to view each layer and both screens separately before any math operations are applied. Also keep in mind that the SNES uses 15-bit color, and the emulator converts the rendered output to whatever your computer screen uses (likely 32-bit color). There is some rounding that occurs during this conversion, which can lead to discrepancies like what you are seeing.

Oooh, awesome, thank you! I don't know when I'll get to the reference, but I will hopefully soon! It looks like the Retro Arch Snes9x core supports turning on and off layers 1-4 and the sprite layer (https://docs.libretro.com/library/snes9x/).

Also, I'm just noticing that your avatar is the Ice 2 spell! Very neat!

---

Just to give a little update, I'm realizing what want to do cannot be done by rote, at least not with the limited knowledge of how the SNES functions that I have. I think that's okay given that my goal isn't to output every single effect (which seems possible but outside my goals) nor to perfectly replicate the SNES output effect perfectly (which seems impossible for based on the information you all have shared with me). My next steps are basically to take the Aqua Rake effect Retro Arch outputs and come up with a simple script that for each pixel in each frame will assign a color index and then map those pixels into a new animation with RGBA colors I'll manually pick based on what looks good to me in an image editor.

Just to share a curiosity I'm okay not solving, part of the reason that I (specifically me) cannot do this by rote is that the math isn't adding up. I re-exported from Retro Arch using the PNGA format, which produces perfectly clean bitmap images of the screen frame-by-frame. I don't see how addition with halving could be in use, since some of the output pixels are solid white over a non-solid-white background, and anything that isn't solid white averaged with solid white cannot be solid white. However, direct addition also seems unlikely, since the differences between the Aqua Rake pixels and the background pixels aren't the same from background to background. I'm wondering if the "important note" in https://wiki.superfamicom.org/transparen...effects-55 or something else is going on.

Whatever the result of my process is, I'll share it here for sure. Thank you all again!

I double checked and it turns out aqua rake is using full addition, not half addition. Sorry if that caused any confusion. For reference, the raw 15-bit (R,G,B) values for the lightest and darkest spots on the bubble are (30,31,31) and (5,5,5), respectively.

Here are a couple more references if you're interested:

SNES coding tutorial about color math: https://nesdoug.com/2020/06/16/color-math/

2006 forum thread where a few pioneers of SNES emulation (including blargg and byuu) discuss optimal color math algorithms: https://board.zsnes.com/phpBB3/viewtopic.php?t=6438

I double checked and it turns out aqua rake is using full addition, not half addition. Sorry if that caused any confusion. For reference, the raw 15-bit (R,G,B) values for the lightest and darkest spots on the bubble are (30,31,31) and (5,5,5), respectively.

Here are a couple more references if you're interested:

SNES coding tutorial about color math: https://nesdoug.com/2020/06/16/color-math/

2006 forum thread where a few pioneers of SNES emulation (including blargg and byuu) discuss optimal color math algorithms: https://board.zsnes.com/phpBB3/viewtopic.php?t=6438

Thank you for the info! It's been a few days since I've worked on this, but I'll take a look at these links the next time I'm working on it.