The X and Y flip flags can be applied through the stack consisting of:
- Object attributes
- Animation frame attributes
- OAM Data
Each of these negate eachother.
Confused yet? The same stack is traversed to obtain the final tile ID,
with an added layer on top for the base GFX offset and the offset for
the dynamically loaded GFX requested by the object!
wBattleAnimDelay is populated with the values passed to `anim_wait`.
Also fixed inmediate in PlaceMapNameFrame.FillTopBottom to calculate the
amount of loops required. (It fills two tiles in the first iteration,
and four in the remaining, hence the `-2` and `+1` part).
Glass ting SFX were added in crystal.
PicAnimations and UnownAnimations are expected to be in the same bank as
their pointers, because the pointers are not BANK()-referenced
separately.
These are used where the head or the feet of the player/enemy have to be
moved in an animation, and shouldn't overlap. These aren't actual GFX
and should be loaded with the proper commands, and they're always loaded
at the end of the VRAM area.
Furthermore, I've defined BATTLEANIM_BASE_TILE, which is the tile from
which battle animation graphics may start to load. This value was picked
to make sure at least an entire pokemon pic fits in the area before it,
even though it doesn't seem very used...
Tried simplifying things a bit, although not nearly as much as I wanted.
Ideally, we'd either have one of two situations:
- A single set of calculations based on values depending on the
direction of the connection
- A bunch of "generic" calculations done before applying simple
modifiers to them in the final `if` block
Right now it's an icky mix of both and I'm not really sure what to make
of it.
The previous name for this was rather misleading. It isn't an actual
jump like you'd expect the `jp` instruction to behave as. Instead, it
behaves more like a `farcall`.
This also makes it consistent with its current command ID name of
`TX_FAR`.
