The vertical shmup counterpart to 841d8be. Cleans up the subsystem
hierarchy by ensuring that at least all tile /formats/ code does not
depend on /main/ code.
Part of P0258, funded by [Anonymous] and Blue Bolt.
PAT_BULLET16_N_BLUE and PAT_BULLET16_N_RED are just meant to be generic
color range indicators with no semantic meaning.
Part of P0245, funded by [Anonymous], Blue Bolt, Ember2528, and Yanga.
In which the shrink types """conveniently""" use a signed comparison
that effectively limits their width to 127 pixels, which forces a
shrink/nonshrink distinction upon the entire rest of the code. 🙄
Part of P0228, funded by [Anonymous] and nrook.
9th PC-98 Touhou boss almost completely decompiled, 22 to go!
I definitely did not miss the convoluted control flow of the TH05 ones.
Part of P0227, funded by nrook.
The one where Sara spawns a symmetric laser pair to wall the player
into a 0x14° corridor while firing dense spread pellets and random blue
balls every 16 seconds.
Part of P0227, funded by nrook.
The one where Sara alternates between firing a slow and a fast spiral
of blue ball ring groups that turns clockwise (7) or counter-clockwise
(8), with each new bullet accelerating by 0.25 pixels per frame.
Part of P0227, funded by nrook.
The one where Sara fires small arcs of pellets at random angles that
are first limited downwards and then gradually expand at both sides,
with slightly faster blue balls on top.
Part of P0227, funded by nrook.
The ones where Sara fires a counter-clockwise (1) or clockwise (2)
curve of blue ball bullets, with one new group every two frames.
Part of P0227, funded by nrook.
Easier to get the bit shifts right if you focus on them in a separate
helper function that is decoupled from any semantics – and Sara is
about to add two more variants of these setters. By interleaving the
per-difficulty count/delta values instead of listing them separately,
it also turns out that I originally mixed them up in Shinki's 4th
pattern. Reads much better now.
Part of P0227, funded by nrook.
Biggest decompilation breakthrough of the year already? Completely
removes the need for the "set near pointer to far function" hack, and
solves quite a few upcoming issues.
The TASM manuals did have a few pages on the topic of segments and
groups, but there's absolutely nothing about it in the TCC ones beyond
the three-sentence description of `#pragma codeseg` and that completely
unhelpful "🤷" of an explanation for the `Fixup overflow` error…
Part of P0227, funded by nrook.
As soon as we get to Sara, these will do more than just show the gather
animation. If we could change the code, we'd include the pattern
selection in the same function, but the second-best refactor would pass
the pattern function as a parameter, and therefore arrive at this
naming scheme as well.
The function pointer names are fine the way they are – since a boss can
have multiple of these externally selected patterns in more than one
phase and select them based on different rules, it makes little sense
to streamline their names.
Part of P0227, funded by nrook.
As implied in adffa1c, a single segment-switching translation unit for
both rendering functions and game logic is the most straightforward
solution for those two games. Especially once you look at TH04, and
realize that the wildly chaotic order of the *_fg_render() functions in
the first code segment exactly matches the order of the *_update()
functions in the third.
Part of P0225, funded by Enderwolf, Blue Bolt, 32th System, 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.
What a beautiful micro-optimization! What's less beautiful though is
the fact that the segment-3 version is only used by a single function,
where it could have easily been inlined.
Part of P0192, funded by [Anonymous], nrook, and -Tom-.
3rd PC-98 Touhou boss completely decompiled, 28 to go… and the code
quality is taking a nosedive again, especially with that unnecessary
"relative phase" variable that collides with the laser activation flag
in the Devil pattern.
(The nearfunc_t_near workarounds are our fault, though!)
Completes P0191, funded by nrook.
There's the meaning I was looking for in 6ff427a! Far from everything
that's done with this "mode change" variable though – and as we've seen
in 426a531, it's mostly a waste of time to immediately RE all meanings
of this variable across all bosses. So, let's keep using the raw
"phase_state" variable in ASM land.
Part of P0191, funded by nrook.
The one where Shinki first fires two point-symmetric 32×32 bullets, and
later adds two alternating spirals of red vector bullets and pellets,
respectively. Final pattern of the boss fight.
Part of P0191, funded by nrook.
The one where Shinki fires aimed purple 32×32 ball bullets, together
with symmetric rotating spreads from the left and right edges of her
wings whose angles rotate along ¾ of a circle.
Part of P0190, funded by nrook.
The one where Shinki's white wings turn purple, and fire 16 purple
32×32 bullets after the color change.
For some reason, OMAKE.TXT says that these wings are black?!?
Part of P0190, funded by nrook.
The one where Shinki walls off both the left and right edges of the
playfield with triangular walls out of spread bullets, and fires
cheetos inside the corridor.
Part of P0190, funded by nrook.
The one where random blue 32×32 bullets rain from near the top of the
playfield, together with aimed spreads from random positions on
Shinki's wings. First white-wing pattern.
Part of P0190, funded by nrook.
The one where Shinki spawns her wings, which fire 50 quick random
bullets as soon as they appear. Featuring the first reliance on a piece
of state set by an earlier boss, which technically affects gameplay!
Part of P0190, funded by nrook.
The one where Shinki fires dense, aimed stacks of blue bullets in quick
succession, while flying to a random point.
I really, *really* don't want to believe that ZUN manually wrote these
micro-optimized setter functions that abuse the bullet template
structure layout, but I don't really have any other idea how to get
those out of the compiler…
Part of P0190, funded by nrook.
The one where Shinki fires random blue directional and kunai bullets
from her left and right side, while flying to a random point.
Part of P0190, funded by nrook.
Featuring something that looks like part of an unused pattern, but was
actually just copy-pasted from Yumeko. Some evidence for Shinki having
been coded after Yumeko, at least.
Part of P0190, funded by nrook.
nmlgc