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.
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 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.
The .PTN functions, vector functions, and egc_copy_rect_1_to_0_1()
(finally!) from TH01, as well as playfld.hpp from all games(finally!),
together with a bunch of other functions in their vicinity.
Part of P0201, funded by Ember2528 and Yanga.
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.
Oh *come on*. TH05 not only reuses this bad idea from TH04, it also
uses them 4× as often as TH04, even for midbosses. Unfortunately, even
the first two bytes that are only (properly) used for a single thing in
the Yumeko fight make more sense as part of this array – then, it's a
consistent 16 bytes for both games. The fact that I didn't look further
in b02147b probably also contributed to me missing them in 426a531 last
month.
But yeah, no sense in researching the TH05 ones deeper this time.
b4876b6 has already proven that to be a waste of time.
Part of P0190, funded by nrook.
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.
This is the function that causes Marisa's `Divide Error` crash when
called during a 4-frame window during the end of certain patterns.
Just like with Kurumi's division by zero, it's just as undefined here
what should happen instead, and any possible fix can only ever be a
fan-fiction interpretation of the code. And since the community will
have an easier time understanding and debating a C++-level hack instead
of an ASM-level one, it makes sense to first decompile this function…
…and document it, which is actually much harder!
Part of P0189, funded by Arandui and Lmocinemod.
Using the .BB entrance animation as a transition between stage tiles
and the backdrop image. Also implemented in a much better way.
Part of P0189, funded by Arandui and Lmocinemod.
It's basically the same function copy-pasted 4 times, differing only in
the backdrop image coordinates and some other inconsequential details.
Part of P0189, funded by Arandui and Lmocinemod.
Once we decompile whatever can be decompiled of those, we're going to
use the same coordinate constants for both these and the backdrop
image. Ideally, we can even macro (or inline-function) away the entire
implementation, so that the redundancy between TH04's and TH05's Stage
4 bosses won't matter as much.
Part of P0189, funded by Arandui and Lmocinemod.
The fanciness of expressing these as signed constants probably hurted
the understandability of the code more than it helped.
Part of P0189, funded by Arandui and Lmocinemod.
Awesome! The last of the shared TH04/TH05 boss functions, completed
just as the money for that sort of thing ran out. Time to decompile
some actual bosses!
Part of P0188, funded by [Anonymous] and nrook.
With TH04's version hardcoding not only Gengetsu's dialog and
initialization, but also the Bad Ending after having clearing Stage 5
with continues or on Easy difficulty.
Part of P0188, funded by [Anonymous] and nrook.
With a different meaning (and sometimes, even type) every time they are
used, forcing me to look at details of boss fights way before I wanted…
wonderful. Not sure yet whether they're involved in Kurumi's and
Marisa's division-by-0 crashes, but that kind of wildly shared state is
exactly what causes bugs like these to happen. I did manage to
reproduce the Marisa crash during this research!
Temporarily breaking the rule of immediately reflecting ASM land
declarations in C land, because it makes more sense to render these as
macros, local to their respective pattern functions, and it's way too
early for declaring these. Or late, given that I've now got to add a
third push to this stretch…
Completes P0187, funded by [Anonymous] and Blue Bolt.
Given how close the string literals of TH04's boss defeat sequence
function are to the end of its data segment, it makes sense to figure
out the three values after it right now.
Part of P0187, funded by [Anonymous] and Blue Bolt.
Mostly centered around the HUD, popup, overlay, boss, and player shot
functions we're about to reference in the upcoming decompilations.
Part of P0186, funded by [Anonymous] and Blue Bolt.
motion_t is also used for certain animations in MAINE.EXE, so not all
instances refer to entities in playfield space. Explicitly specifying
the latter now allows us to gain…
Part of P0149, funded by Blue Bolt, Ember2528, and -Tom-.
Palette hacks not included yet. Yup, that's how all phases can use
hardware color #0 as their background color.
Completes P0147, funded by -Tom- and Ember2528.
64 slots reserved, 16 slots actually used, another 768 bytes of
conventional RAM wasted…
(And yes, that naming convention is indeed meant as a shoutout to all
the RPG Maker veterans out there.)
Part of P0147, funded by -Tom- and Ember2528.
That could have easily been architected without forcing every boss to
manually set the "background to be drawn while bombing" function
pointer.
And without the laziness of just redrawing all tiles during the blocky
opening animation of certain bombs…
Part of P0147, funded by -Tom- and Ember2528.
Not exclusively used for the boss entrance animations, even though its
data is declared in that general vicinity. It's also used for all bombs
in TH04, and Reimu's and Yuuka's bomb in TH05.
Part of P0147, funded by -Tom- and Ember2528.
Whew, time to look at every `int` variable we ever declared! The best
moment to do this would have been a year ago, but well, better late
than never. No need to communicate that in comments anymore.
These shouldn't be used for widths, heights, or sprite-space
coordinates. Maybe we'll cover that another time, this commit is
already large enough.
Part of P0111, funded by [Anonymous] and Blue Bolt.
nmlgc