• Comments that describe all lines of code until a blank one are placed
into the lines immediately above
• Comments that describe an entire demarcated block are placed
immediately below the dash row at the top
• In any case, there should be a blank line after the top comment of
a demarcated block, to keep IntelliSense-style systems from applying
the block comment to the first actual line of code…
• …but there shouldn't be one before the dash row at the bottom, where
it'd be redundant.
Part of P0207, funded by GhostPhanom.
Yup, if it weren't for that one boss function periodically resetting
the palette to the other global one, this discoloration would be
permanent.
Completes P0206, funded by Yanga and [Anonymous].
The source: The boss invincibility flash effect, which ends up
unconditionally resetting the palette periodically. But wait, could
that maybe…?
Part of P0206, funded by Yanga and [Anonymous].
The one where ZUN finally uses the corner points for the current frame
as the spawn point for Mima's aimed lasers. 60 functions remaining in
TH01!
Part of P0206, funded by Yanga and [Anonymous].
The one where Mima sprays slow pellets from the corner points of the
rotating square around her from 8 frames ago, aimed in a half-circle
motion from her left to her right side and back.
Part of P0206, funded by Yanga and [Anonymous].
The one where Mima fires missiles from the corner points of the
rotating square around her from 8 frames ago, aimed along a static
downwards half-circle from her right to her left side, with 16 frames
between the individual missile groups.
Part of P0206, funded by Yanga and [Anonymous].
The one where Mima spawns 8 flame pillars, 20 frames apart, at very
specifically calculated random positions, followed by an aimed 3-spread
after each pillar has reached its maximum height.
Part of P0206, funded by Yanga and [Anonymous].
The one where Mima hops over ⅕ of the playfield 4 times in a row,
starting at either the left or right edge, while darkening the screen…
or not?
Completes P0205, funded by [Anonymous] and Yanga.
The one where Mima takes the final static part from the first pattern,
and replicates it with two squares that rotate in opposite directions.
Also demonstrates the 34th unblitting bug in this game.
Part of P0205, funded by [Anonymous] and Yanga.
The one where Mima spawns missiles from the corner points of the
rotating square around her from 8 frames ago, aimed to Reimu's position
before any missiles were spawned.
Part of P0205, funded by [Anonymous] and Yanga.
The one where Mima spawns aimed and later static pellets from the
corner points of the rotating square around her from 8 frames ago.
Part of P0205, funded by [Anonymous] and Yanga.
This one will use the DotRect template from `planar.h` and generate a
single 16- or 32-dot value per row. Since this converter has a goal of
maximum portability, it makes sense to keep raw the multidimensional
C-style arrays around as a possible output format.
Part of P0205, funded by [Anonymous] and Yanga.
You know that things are complicated when you have to resort to Unicode
box drawing character art to explain how two hitboxes relate to each
other. I *hope* this makes enough sense, and that I won't be rewriting
this in terms of ORB_W and ORB_H after all in the future. For now
though, it's immediately obvious when the hitbox reaches outside the
entity. In the case of YuugenMagan, it even simplifies the coordinates
so much that we don't need separate constants.
Part of P0205, funded by [Anonymous] and Yanga.
The flag that blocks collision handling for vertical bars might prevent
some of the potential glitches here, but definitely not all of them.
Thanks to touhou-memories for bringing this to my attention, this was
indeed a glaring omission.
The fact that the game insists on this translation unit is already bad
enough – thanks to the static constructor for the CCards and CObstacles
instances, we can't merge it with segment 31. Just `#include`ing
str_val.cpp here is much less bad than having more than one extra
source file.
Part of P0204, funded by [Anonymous] and Yanga.
The nondescript nature of `core/` has been annoying me for a while, and
these function kind of are number-related after all.
Part of P0204, funded by [Anonymous] and Yanga.
In which ZUN needs a hack to make columns of vertical bumper bars work
at all with the way the Orb's X velocity is implemented… and may have
just deliberately ensured that the Orb can definitely loop infinitely
between two bumpers.
(Those two wrong NOPCALLs aren't worth working around. It would
basically require taking apart the entire function, and they'll be gone
by the next two commits anyway.)
Part of P0203, funded by [Anonymous] and GhostRiderCog.
All throughout this codebase, `X_put_8()` implies that just the single
sprite of X is blitted on top of whatever is in VRAM at the given
position. This function blits more than one sprite though. (Also,
portal rendering is going to introduce a helper function that does only
blit a single thing.)
Part of P0203, funded by [Anonymous] and GhostRiderCog.
nmlgc