The translation units were probably a better place back when most of
the codebase was still compiled in C mode, we only had a few C++ TUs,
almost everything needed to be declared as `extern "C"`, and moving
these declarations into the headers would have been really noisy with
all the `#ifdef __cplusplus` / `#endif` required. Nowadays though,
we've greatly reduced that surface area. And given that headers will
include even more headers as part of the upcoming `#include` cleanup,
it makes sense to make the jump now.
Part of P0284, funded by [Anonymous] and Blue Bolt.
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.
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.
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.
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.
The one where Shinki fires bullets in a ring, with each new ring fired
at an increasing or decreasing angle, for a curved effect. The first
pattern you see in the fight.
At least the pattern functions are short and sweet for the most part.
Part of P0190, funded by nrook.
nmlgc