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].
Reason: Self-modifying. -.- And saving SI and DI on the stack way too
late.
Luckily, it's mostly identical to TH04's version I decompiled earlier,
only (thankfully) combining regular and special bullets into one
function, and integrating TH05-specific improvements.
Part of P0152, funded by -Tom- and [Anonymous].
Only used for the revenge bullets fired from Stage 3 Alice's barrier.
Not worth creating a separate translation unit, especially since the
function above is undecompilable as well…
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].
… (24 + (difficulty * 8) + rank) in TH04, and (42 + (difficulty * 8))
in TH05. Also, TH05 only doesn't have TH04's bullet zap animation
because ZUN didn't consistently use constants…
Completes P0151, funded by Blue Bolt and -Tom-.
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-.
Boom! Decompilable after all. And look what that made us finally point
out: In all 4 games that use this function, its return value is
undefined if BGM is inactive. (That is, if the user disabled it, or if
no FM sound board is installed.)
Part of P0148, funded by [Anonymous].
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].
… Wait, we *can* decompile functions with both parameters, no stack
frame, and a Pascal calling convention?! Good that I already forgot how
impossible it was to decompile the first function I looked at that fell
into this category!
Part of P0148, funded by [Anonymous].
Including the pointless DOS I/O variation in TH05's MAIN.EXE.
I'm slowly running out of characters to remove from the first segment
name in that file, though…
Part of P0148, funded by [Anonymous].
It shouldn't need a comment to communicate that this function does in
fact not load all values from the .CFG file that are part of the
resident structure, but only loads and sets the global pointer to that
structure.
Part of P0148, funded by [Anonymous].
The bullet update function really needs this one declared in C land to
link without a fixup overflow? Guess we'll have another technical debt
push before then…
Part of P0148, funded by [Anonymous].
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.
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.
The one in the first four phases, with the two parallel zooming lines
that give the impression of flying into a corridor, and random blue
particles shooting out from the center.
Part of P0146, funded by -Tom- and Ember2528.
We really wouldn't have wanted to start writing inline ASM in the
middle of a conditional expression just to get that janky `CMP AX, 0`
instead of TCC's sensible `OR AX, AX` optimization.
Part of P0146, funded by -Tom- and Ember2528.
Oh hey, a uth05win naming convention I have no qualms about adopting,
for once!
(Note from the future: It's actually really smart! The animation you
see is dependent on the state from previous background types, so it
makes sense to reduce the names to the original sequence.)
Part of P0146, funded by -Tom- and Ember2528.
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.
Last one! Done with the SHARED segment for the forseeable future! 🎉
Sure, not the best C++ code either, but still by far the sanest
implementation of this function in any of the 4 games.
Completes P0139, funded by [Anonymous].
It's not a kaja_func_t if it's shifted left by 8 bits. Why is it
shifted left by 8 bits to begin with, though? Why not just pass a
kaja_func_t, and assign it to AH? Arrrrgh.
Part of P0139, funded by [Anonymous].
Hardcoding these *might* have been acceptable if the numbers actually
matched the sizes defined in GAME.BAT, but they don't. With PMD's
AH=22h function, there's really no excuse though.
About time I looked into this, and expressed that constant as an inline
function that can easily be replaced with a proper implementation.
Part of P0139, funded by [Anonymous].
This gets rid of a couple of per-entity sprite bitplane types, makes
sprite declarations easier to read by putting width and height next to
each other… and points out a number of array dimension mistakes -.-
Even in places where we can't use it.
Part of P0138, funded by [Anonymous] and Blue Bolt.
Sure, we can't use them everywhere, but it's really nice to get rid of
that casting madness – and any explicit references to x86 memory
segmentation – wherever we can.
Part of P0138, funded by [Anonymous] and Blue Bolt.
Second previously undecompilable translation unit, second creative
workaround for the workaround. We can't compile snd_se_play() with -WX,
as that function needs a stack frame, and it's also illegal to disable
-WX in the middle of a translation unit. But since we only need word
alignment in front of snd_se_reset() *and* that function is identical
in all 4 games, it makes sense to move it to its own translation unit.
And then you notice that the TH02/TH03 and TH04/TH05 versions of the
other two functions are basically identical. The small differences can
easily be moved out to inline functions, leaving us with a single
implementation file for all 4 games. Nice!
Part of P0137, funded by [Anonymous].
Might look uglier, but has the advantage of not generating an empty
segment with the default name… *and* the default padding, which will
really come in handy with the following breakthrough.
Part of P0137, funded by [Anonymous].
Whoops, turns out that the build has been broken on TASM32 version 5.3
(the one in the DevKit) ever since 7897bf1. In contrast to version 5.0
(which I use for my development), 5.3 actually defines 32-bit segments
if you specify a .386 CPU before using .MODEL.
That might have been the reason for the .286 workaround all along?
Turns out there's the USE16 modifier, which makes this much more
explicit than switching CPUs.
nmlgc