Common sense: Entity backgrounds always go into slot X, missile sprites
into slot Y, and wave sprites into slot Z
ZUN: "Nah, let's set aside two slots, and bosses can just freely use
them as they want 🎺"
Part of P0165, funded by Ember2528.
There's a reason why the game reserves memory for exactly this many,
after all. This way, we also stop pretending that the game's use of
.PTN is neatly decoupled from the format's interface…
Part of P0165, funded by Ember2528.
Properly decompiling the calls to this function from the previous one
allows us to get rid of seemingly unrelated `goto`s there.
Part of P0164, funded by Yanga.
> direction merged into special attack enum
> direction outside special attack using a different enum
> both are stored in a single overloaded variable
> separate variable for direction only used during dashes, but only
pointlessly, in addition to the other one
That function's gonna be terrible.
Part of P0163, funded by Ember2528.
Hooray, separate sprites for facing left and right. That huge function
would have probably been less than half as long if ZUN just implemented
sprite mirroring, but doing that on PC-98 might have been just a
little bit *too* nontrivial for a first game. (At least he did it in
TH03, where he couldn't get away with pre-mirrored sprites.)
Part of P0162, funded by Ember2528.
Everything about these is bad, including my previous attempt at naming
them. The "forward" instance also contains the flip kick animations
(facing sideways), and MIKO.PTN also contains animations. Those sprite
sizes really are the only reason why those needed to exist at all, so
why pretend that they fulfill some higher semantic reason?
Part of P0162, funded by Ember2528.
I've long moved to a convention of putting every .OBJ compiled from ZUN
code into the subdirectory of the game that introduced it. These four
are the last remaining inconsistencies from earlier in development.
Part of P0162, funded by Ember2528.
Yup, it's a compiler bug, and it removes a small bit of freedom as far
as decompilation order is concerned. In particular, this means that we
can't do TH01's continue and pause menus before having decompiled the
bomb animation.
Would have been nice to pad out the previous push with those, but
instead, I had to spend way too much time figuring *this* out…
Completes P0161, funded by [Anonymous].
Only seen in Mima's fight, but initialized for all non-final boss
fights. Also with explicit support for all 8 origin edges, not just the
top-right one used in Mima's fight… and an off-by-one error?!
Completes P0160, funded by Yanga.
Oh hey, another HUD element that is needlessly (and slowly) drawn to
VRAM. The custom boldfaced font would have been a perfect fit for
gaiji… well, OK, halfwidth gaiji weren't exactly well documented back
then.
Part of P0160, funded by Yanga.
After all, these are called again during all of Sariel's background
changes, not really just when starting a scene or boss battle.
Part of P0160, funded by Yanga.
There might only be three functions between the second and new third
split, but these seem to depend on the entire rest of the code for
card-flipping stages…
Part of P0160, funded by Yanga.
So generic that every individual structure member is separately passed
by reference. 🤪 That's one way to practice this aspect of C++, I
guess?
Part of P0158, funded by Yanga.
This actually made me research whether Turbo C++ 4.0J had some obscure
loop unrolling optimization option. But no, ZUN must have done that by
hand…
Part of P0158, funded by Yanga.
nmlgc