Yup, there's more! About time we started a general coordinate header
that will ultimately be independent of `pc98.h`.
Part of P0264, funded by [Anonymous] and Blue Bolt.
We'd like to use this optimization in the platform layer as well.
Turning it into an inline function via __emit__() also allows us to
turn a bunch of other macros into proper inline functions.
Part of P0232, funded by [Anonymous].
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.
Started out with the usual amount of decompilation workarounds for this
low-level laser code, but ended up requiring one on almost every line
just because ZUN reversed the function prolog… 🙄
Part of P0228, funded by [Anonymous] and nrook.
A year ago, I would have considered this undecompilable. Turns out that
this function really benefitted from a decompilation against all odds,
especially with these 4 different views on the same 8 local variables.
Part of P0228, funded by [Anonymous] and nrook.
VS Code doesn't seem to properly syntax-highlight C-style comments that
start on a #define line and end in the line below. But even apart from
that, this rearrangement ensures that IntelliSense correctly assigns
both lines to BGCC_SPREAD as I intended it.
Part of P0227, funded by nrook.
• 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 .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.
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.
Since the game uses global state to define its patterns, we'd really
like to see immediately which of the structure fields are relevant for
spawning bullets. This makes it easier to spot which of the patterns
rely on fields set in previous patterns – and there are several that
do.
Part of P0190, funded by nrook.
Short, sweet, fits more nicely into 8.3 filenames than "curve bullets"
does, and 76.7% of fans agree:
https://twitter.com/ReC98Project/status/1500256959785746434
OMAKE.TXT calls them "homing lasers", but… eh, nah.
Part of P0190, funded by nrook.
Wait, wouldn't it be cool if we could keep the render, spawn, and
update functions in the same translation unit, by switching code
segments in the middle of the file? Let's hope this works out, and give
the source file an all-encompassing generic name.
Part of P0188, funded by [Anonymous] and nrook.
The algorithm for gradually rotating these clockwise or counterclockwise
towards the player could have been 5 lines long. ZUN blows it up to 26
lines.
Also, a 16×16 killbox for the head node, and a 12×12 one for trail
nodes.
Part of P0185, funded by [Anonymous], -Tom-, and Blue Bolt.
Too bad that alignment constraints do in fact force us to compile
th04/bullet_u.cpp and th04/bullet_a.cpp separately. 😕
Part of P0184, funded by -Tom-.
Also not worth decompiling, because:
• It would break return value semantics
• The algorithm is identical to TH04 (except for that one divisor)
• Small function
• Next to a bunch of more critical, undecompiled functions
• Decompilation would be messy anyway
Part of P0152, funded by -Tom- and [Anonymous].
And that's it! Finally RE'd every bullet spawning function in TH04 and
TH05! 🎉
These really aren't worth adding a translation unit for either, in the
end. Not least because they decide to keep bullet_template.speed from
being mutated via PUSH and POP, which we can only express via inline
assembly in C land.
Part of P0152, funded by -Tom- and [Anonymous].
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].
nmlgc