Age | Commit message (Collapse) | Author |
|
The lot of these were rather misnamed, since they're used to replace
part of the player or enemy with objects for several background effects.
https://github.com/pret/pokecrystal/pull/578#issuecomment-440996244
|
|
Confusingly ambiguous name
|
|
QueueBattleAnimation loads an object using these wram addresses. Usually
populated by the anim_obj command, but in a couple of cases also
manually.
|
|
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...
|
|
|
|
|
|
text_jump → text_far
|
|
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`.
|
|
|
|
|
|
Renamed to be more in line with our current coding standards. Hopefully
this is slightly more readable.
|
|
|
|
|
|
|
|
|
|
My bad.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
allowing four-byte multiplicands could overflow hProduct.
|
|
|
|
|
|
|
|
|
|
|
|
Remove some unused WRAM labels
|
|
Note that the result quotient is four bytes, but hQuotient is a three-byte buffer. This is because no Divide caller ever needed a four-byte quotient, so the buffer didn't include the high byte.
|
|
In the 2BPP format, two bytes %ABCDEFGH %abcdefgh define eight pixels %Aa %Bb %Cc %Dd %Ee %Ff %Gg %Hh.
Four valid colors: %00 = 0 = white, %01 = 1 = dark, %10 = 2 = light, %11 = 3 = black.
Thus `22222222 = pixels %10 %10 %10 %10 %10 %10 %10 %10 = bytes %11111111 %00000000 = $ff00.
|
|
|
|
|
|
|
|
|
|
Use explicit ldh instruction to access HRAM locations, don't rely on optimizing ld
|
|
Its main function is fainting the opponent and ending the move effect.
Updated the comment accordingly.
|
|
|
|
Clarified its usage, as the comments surrounding it were factually
wrong.
|
|
|
|
|
|
These are by far not always checked each week, and as such shouldn't be
called that.
Since they're almost always used through the `bit` instruction, it's
very inconvenient to just make wDailyFlags a `dw` instead.
|
|
|
|
|
|
|
|
|
|
Pokedex_PrintListing has a comment noting how it depends on wCurSpecies == wNamedObjectIndexBuffer; an assert would be more convenient, but is not possible since WRAM label addresses are not defined yet here.
|
|
|