Turns out that we can define the magic numbers used in the pentagram
shrink effect in terms of the distances between the eyes and the
pentagram's target position in the center of the playfield. Therefore,
specifying the eye positions in raw pixel coordinates won't give the
full picture (who would have thought).
Part of P0208, funded by GhostPhanom and Yanga.
They really are no different from regular pellet motion until they
reach the top of the playfield. Also, part 2 of 5a8bbd2.
Part of P0207, funded by GhostPhanom.
Nooooo, the static initialization code proves that `boss_entities`
couldn't have been an array in ZUN's code! 😢 Which in turn explains
why YuugenMagan's and Elis' code looks the way it does. We could go
into undefined behavior territory and just cast `boss_entity_0` to a
pointer, but let's better not annoy future port authors just for my
personal convenience. In turn, we need to get a bit clever with some of
Elis' code to replace the now wholly redundant `elis_entity_t` type,
but it's not all too bad.
Part of P0207, funded by GhostPhanom.
You don't get the full picture of YuugenMagan's rendering calls
otherwise.
It's also really stupid in how it trades performance for flickering.
Part of P0207, funded by GhostPhanom.
• 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.
nmlgc