Idea to make C26/C27 battle animation script command usable in custom animations

Documentation
, , , ,
1

After a recent mishap with trying to import a fix for FE6’s female Hero axe animations with full functionality and running into some problem or other with the shield throw part each time, I decided to try and analyze why, exactly, the C26/C27 command script that handles that shield throw is so finicky with imported animations. I’m fairly certain the reason has to do with how the animation’s tile sheet is laid out.

I’ve compiled exports of all the GBAFE Hero animations, and, as I expected, the shield tiles are in the exact same position in each tile sheet across all Hero animations from a given game. For some examples of what I mean, here are comparisons between the first sections of the tile sheets for FE6’s male and female Hero animations, as well as between the first sections of the tile sheets for FE7/8’s generic male Hero animation and FE7’s Raven/Linus Hero animation.

FE6 F!Hero vs. FE6 M!Hero

braf_sw1 Sheet 1

bram_sw1 Sheet 1

FE7/8 M!Hero vs. FE7 Raven/Linus Hero

bram_sw1 Sheet 1

brlm_sw1 Sheet 1

My postulation is that C26 and C27 scripts get specific, hardcoded tile ranges from the loaded animation tile sheet to use for the thrown shield, which results in garbled graphics if the contents of those tiles are not synced with what the scripts are designed to use.

Altering the tiles does not prevent the animation itself from playing all the way through just fine, it simply causes the shield that is being drawn and moved around to appear as a mess of incorrect graphic tiles. As such, I believe it highly likely that the issue is purely a matter of the wrong tiles being loaded for the shield.

My suggestion for a solution is, if a C26 or C27 command is detected in the animation.txt file, reserve space in the tile sheet to correspond to the locations of the shield tiles in the vanilla Hero animations in the game into which the animation is being imported. Import graphics to those tiles from a “shield.png” file in same directory as the other weapon_frame.png files, while the other animation tiles are arranged around the reserved space.

shield.png and weapon_frame.png files should obviously all use the same palette.

I’ve also compiled a .zip file with all the GBAFE tile sheets and frame data sorted by game, as well as a .txt file with the same musings I’ve shared in this post, which you can download here if it would be helpful.

Unfortunately, I don’t really have the coding know-how to modify the current battle animation importation software to do this just yet, but I figure I can at least share what I’m pretty sure the issue is and how to make it work in a place frequented by people who do.

1 Like
2

The research
The research852×587 78 KB

Yeah, that’s exactly what is going on in the sprite sheets. When I originally discovered it months ago, I got the responce that it would be impossible to implement, so idk how to proceed about this. These rules are not followed in the FE6-axe animations so there is already a vanilla-case where we would need a way to make use of these commands, but if it’s impossible, then I guess it just is.

1 Like
3

I believe those who can make a battle animation creator already know that. It is possible to do but not worth it.

1 Like
4

C26 and C27 probably (although I haven’t checked) start new AISes which draw the shield (& sword?)

I’m guessing this was done so rotation could be applied instead of incorporating the shield at multiple angles into the sheets, which would’ve resulted in more sheets and more frequent decompression, not that either would’ve likely resulted in any noticeable downsides, probably.

There’s a lot of documentation on AIS and OAM Data here,

As for creating a tool that does this for someone, that sounds iffy. I’m not sure what assumptions need to be made when someone runs a hero-edit through the tool for the output to work well. In any case, if I’m not mistaken, this would be the source code of the part of FEBuilderGBA that creates battle animations out of scripts+images:

One can reference that to make their own tool. Best of luck to whomever would be willing to go that far.

2 Likes
5

Oh, FEBuilderGBA is written in C? I might be able to figure something out then, actually.

If which tiles it draws the shield from are known, it seems very feasible to add functionality to reserve that space for the contents of a shield.png if C26 or C27 commands are found in the animation script file.

I’m not sure about the rest of the Hero animation’s separated shield movements, though; this would just be for the shield that gets tossed into the air.

6

What seperated shield movements? As far as I remember, everything else already works like with any other animation iirc, it’s simply that these specific coordinate-ranges cannot be used on the sheets because they are already used by these commands.

7

Looking at how the tile sheets are laid out, it really looks like the Hero’s shield is being animated separately from the rest of the sprite. FEBuilderGBA doesn’t display it that way, but you’ll notice that the tile sheets don’t contain any of the rough-looking rotation frames of the shield; just a few “base” shield sprites for different viewpoints.

8

Yeah this is essentially it in terms of what’s being done under the hood. I share Misaka’s notion that lack of will is the issue, not lack of knowledge, as this has been known since pretty much the moment that the graphics were ever first exported.

9

As with cloak command C47, creating more complex mechanisms in the current combat script to support C26/C27 would only make the system even more difficult, and the benefits gained would be negligible.
There is no need to stick with such nonsense, and there is no need to support it, since it can be solved in other ways.

The alternative is to write commands without C26/C27, as in C47.

The downside is that it increases the animation capacity a bit.
However, the increase is only a few kilobytes per unit, so it is not a very serious problem.
On the contrary, it would be extra difficult and time-consuming to create and use a circuitous system to support this feature.
I don’t think this is a feature that would benefit anyone.

First, you need to set where the tiles to be reserved are.
Then you need to additionally set which part of the animation it is.
This alone would prove to be a hassle to set up.
Probably no one would use such a feature if it were created.