Fun fact: The laser from the rightmost eye has a hitbox that's 24
pixels larger than the other ones…
But yeah, nothing that resembles the pattern functions from the other
fights in this one, and even the functions that sort of do leave their
cleanup to the big main function. No sense in numbering them this time.
Part of P0208, funded by GhostPhanom and Yanga.
• 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.
The one where Sariel's second form shoots sparks towards the top of the
playfield, which then turn into leaf-like sprites that sway towards the
bottom, killing Reimu on contact.
And wow, what a finish! A weird "decimal subpixel" type, hardcoded
sprites, and effectively unused non-hardcoded sprites. Too bad that it
also ruins the nice `dot_rect_t(w, h)` parameter abstraction for
grcg_put_8x8_mono()…
Completes P0180, funded by Yanga.
Only seen in Mima's fight, but initialized for all non-final boss
fights. Also with explicit support for all 8 origin edges, not just the
top-right one used in Mima's fight… and an off-by-one error?!
Completes P0160, funded by Yanga.
Third longest function in all of PC-98 Touhou, and it's even more of a
copy-pasta than the patterns we've seen earlier. Certainly didn't feel
that long.
Part of P0156, funded by Ember2528.
The one with two homing snakes, and pellets fired in a semicircle
spread. And yes, Reimu really has a 30×30-pixel hitbox against the
snakes.
Much simpler than its instruction count might suggest. Recalculating
array element addresses over and over is certainly a way to add bloat…
And yes, we're going to see all of this exact same code again in the
four-snake pattern.
Part of P0153, funded by Ember2528.
Deciding whether to decompile this one or not seemed to be a tough
choice. Should we *really* introduce two more translation units just
for the sake of decompiling another function that's identical to its
TH04 counterpart anyway?
Well, turns out it actually isn't: TH05 does in fact *not* immediately
clip bullets that are spawned on top of the player. Which might sound
like it has a notably different effect on gameplay… except that it
doesn't.
So yeah, good we've decompiled it, and got to show that more clearly.
Part of P0152, funded by -Tom- and [Anonymous].
… (24 + (difficulty * 8) + rank) in TH04, and (42 + (difficulty * 8))
in TH05. Also, TH05 only doesn't have TH04's bullet zap animation
because ZUN didn't consistently use constants…
Completes P0151, funded by Blue Bolt and -Tom-.
First place to confirm the hitbox of both the 8×8 pellets and the 16×16
sprite bullets!
Well, "hitbox". It's really more of a kill delta of 8×8 pixels between
the center points of a bullet and the player. You can distribute these
pixels to any combination of bullet and player "hitboxes" that make up
8×8. 4×4 around both the player and bullets? 1×1 for bullets, and 8×8
for the player? All equally valid… or perhaps none of them, once you
keep in mind that other entity types might have different kill deltas,
which turns the concept of a "hitbox" into just a confusing abstraction.
Part of P0150, funded by Blue Bolt.
At least I *hope* it's an improvement. `point` should be reserved for
actual structures with .x and .y members.
Part of P0149, funded by Blue Bolt, Ember2528, and -Tom-.
nmlgc