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].
Spent 4 pushes on the basic types and constants in 2020, still ended up
up getting this wrong and documenting the opposite of what TH05 actually
does…
Part of P0152, funded by -Tom- and [Anonymous].
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-.
And actually document them correctly.
Clear: Custom duration, awards constant points per bullet during the
entire duration, plays a decay animation
Zap: Fixed duration, awards a semi-exponential bonus for all bullets
alive on the first frame, plays a, um, "zapping" animation… in
TH04, because it's bugged in TH05 :zunpet:
Part of P0149, funded by Blue Bolt, Ember2528, and -Tom-.
Well, we *could* pointlessly decompile this function into an unreadable
mess, but only if we throw away the semantics of the return value, and
replace its type with `void` or `uint32_t`.
(Turbo C++ can't cast registers to a struct value, and adding a
constructor to SPPoint would break everything else, if it even works.)
ZUN's original usage code doesn't care either way, because it only ever
accesses the returned value directly through DX:AX.
Part of P0148, funded by [Anonymous].
We're going to need some name for the longer, boss-specific danmaku
animations. Turns out that these are exactly called "patterns" in
Sparen's glossary:
https://sparen.github.io/ph3tutorials/ddsg0.html#sub4
So what we called a "pattern" is actually called a "group". Whoops!
Part of P0142, funded by Yanga.
`cPtrSize` is simply the wrong constant for calculating parameter
offsets on the stack, because it corresponds to the memory model's
default distance, not the function's distance. Luckily, ARG has a
RETURNS clause, and if you declare all parameters in there, ARG won't
emit that pesky and unnecessary `ENTER 0, 0` instruction. Big discovery
right there!
Sadly, ARG is unusable for ZUN's silly functions that keep the base
pointer in BX. TASM declares the resulting equates as `[BP+offset]`,
and it's apparently impossible to only get `offset` out of such an
equate later.
So, rather than staying with numbers, let's reimplement ARG for these
functions instead. This way, we can even abstract away the stack clear
size for the `RET` instructions.
It's a bit rough around the edges though, forcing you to explicitly
specify the function distance, and to pass the parameters in reverse
order compared to the C declaration (thankfully, all of these use the
PASCAL calling convention). It also doesn't work with more complex
types yet. But certainly better than numbers.
Part of P0134, funded by [Anonymous].
*Technically* also a uth05win inaccuracy. That codebase went with
"KnifeBullet", which seemed right, so I just ran with it without
researching it further… My bad.
(Maintenance mode commit)
Making sure that we don't ever have to iterate over the 8×8 pellet part
of the bullet array during rendering… sure, but why not give the same
optimization treatment to the 16×16 bullets?
Part of P0112, funded by [Anonymous] and Blue Bolt.
nmlgc