Way easier to read compared to the mental gymnastics of the original
"offset + range" form, especially since we can also abstract away
subpixels with another layer of wrapper functions. Also brings a bunch
of new speed/angle symmetries to light.
Part of P0190, funded by nrook.
If the macro itself is local to a function, these can work in certain
scenarios, but never for global ones.
Part of P0186, funded by [Anonymous] and Blue Bolt.
Not just the maximum bounce count. Unsurprisingly, I also did a rather
shallow job in this part of the bullet code back in 2020…
Part of P0184, funded by -Tom-.
Reason: That switch statement. How should we even?
Well, the code *is* fairly good. After looking very deep into it, and
spending 35% of that function on blank lines (for logical grouping) and
explanatory comments, that is…
Part of P0152, funded by -Tom- and [Anonymous].
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.
TH05's version, which we saw way back in ac7e6bc, is almost identical
and can be used for any speed, whereas this one is hardcoded to modify
only the speed in the bullet template.
Part of P0150, funded by Blue Bolt.
`switch` statements compiling to binary searches if the range of values
is nasty enough? That's so cool. Apart from a few places in TH02,
this is the only place in PC-98 Touhou to show off that Turbo C++
optimization.
That code's still unexpectedly janky for what you'd expect from the 4th
game in the series, though.
Part of P0150, funded by Blue Bolt.
Still way premature to say things like "the base speed of a bullet
aroup is not affected by difficulty, only by rank". (Which also would
be a way less meaningful statement than you might think it is.)
Part of P0150, funded by Blue Bolt.
nmlgc