"Oh wait, actually, I *do* want to blit 8 pixels at a time in some
cases" :zunpet:
First time in a long while that the VRAM access macros couldn't do the
job, because code generation wants *both* pointer arithmetic *and*
subscripts within the same expression.
But *come on*, just blit the 16 pixels for the byte-aligned case!
Part of P0107, funded by Yanga.
So if the boss entity class stores all non-pixel metadata for its
associated .BOS file, how can YuugenMagan have 5 independent eye
sprites, or Kikuri have more than one soul and tear sprite?
By duplicating that data, of course!
Those structure copies to local variables seen in the load functions
of these bosses still remain pointless, though.
Completes P0106, funded by Yanga.
"Hm, I have this format that specifies sprite width in multiples of 8,
but *actually*, I'd like to blit 16 pixels at a time… well, time to
pepper the code with divisions and casts, I guess :zunpet:"
Which becomes even more hilarious once you realize that the `operator
new` function does require bytes after all. Which leads
new dots16_t[image_size / 2];
to compile to
operator new((image_size / 2) * 2);
:tannedcirno:
Part of P0106, funded by Yanga.
What else to call something a boss can have multiple of, that may or
may not be part of a larger boss sprite, may or may not be animated,
and that may or may not have a orb hitbox?
Needed to be RE'd before the .BOS loading functions, because those are
actually methods of this class. And because renaming all these
variables in ASM land is tedious anyway, we might as well name each
individual entity of every boss.
Still, what's with the pointless local variable copies in the
YuugenMagan and Kikuri functions?
Part of P0106, funded by Yanga.
And that's all? No unblitting or non-aligned functions? Oh well, at
least this one correctly clips the sprite at all 4 edges of VRAM, for
once.
Part of P0105, funded by Yanga.
One fewer magic number. And one more deliberate dependency on a
PC-98-specific hardware constant, to further drive home just how
unportable these games are, even once decompilation will be complete.
Part of P0105, funded by Yanga.
Leading to slight complications in TH02's Music Room and shot type
selection menus. Thought about leaving those in C for a while, but I
still think it's worth it for the consistency we get with the VRAM
offset functions. Also, we'll have similar code for the main menus of
later games, and I'll surely won't be using C++ when starting out with
these.
Part of P0105, funded by Yanga.
We not only actually still need the (pointer, size) function to fill
heap-allocated memory, but we also need to differentiate between near
and far pointers, to move those pesky `PUSH DS` instructions to their
original places?!
Part of P0105, funded by Yanga.
"Hey, let's have separate functions for uint16_t and int16_t… and then
just *not* support negative numbers in the latter" :zunpet:
Part of P0104, funded by Ember2528.
If you've ever cheated more than 6 lives in TH01, you might have
noticed that those additional lives appear in additional rows in the
HUD. And well, that had to be coded somewhere…
Part of P0104, funded by Ember2528.
Both inlined and non-inlined page switching within the same function,
together with an approach that doesn't correspond to our other planar
access macros? That code must have been written during a very
experimental phase very early in the development of this game.
Part of P0104, funded by Ember2528.
Hey look, this one *does* only render to a single page, and then blits
the area to the other one! Using an unnecessary new function that isn't
even EGC-accelerated…
Completes P0103, funded by Ember2528.
The scores are rendered to *both* VRAM pages…? Which means that we
need a separate set of sprites to store the background behind the
numbers. This does not bode well for animated backgrounds…
Part of P0103, funded by Ember2528.
How optimized is TH01? Well, since the player Y is constant, checking
for Y ≥ 368 first would rule out a collision for the majority of
entities during gameplay after just 1 check.
TH01 still checks X first.
Part of P0102, funded by Yanga.
Or, in more relevant news: That's the function that forced TH01's
pellet sprites to be defined in C land. First sprite to make that jump.
Part of P0102, funded by Yanga.
… pellet unblitting uses a *doubly* sloppy 16×8 rectangle. 🤦
The resulting terrible flickering is probably why the Stage 15 and 20
battles enable this weird "interlace" mode that only renders and
hit-tests half of the pellets each frame… except that player shots
are still hit-tested every frame?
So yeah, your eyes aren't deceiving you, the game does effectively drop
its perceived frame rate in the Elis, Kikuri, Sariel, and Konngara
fights, and it does so deliberately.
And *then* you realize that those weird hit tests are actually a
futile attempt to mitigate the disastrous effects of a way too large
unblitting rectangle. Congratulations, you've found the most stupid
piece of code in this game.
Part of P0102, funded by Yanga.
ZUN might have gotten the impression that the EGC can *only* work with
multiples of 16 pixels per load or store? Which might explain why…
Part of P0102, funded by Yanga.
Note how Turbo C++ auto-generates that call to `operator new`, which
you don't see in the decompilation anymore. So yeah, as soon as you add
a constructor, Turbo C++ enforces heap allocation for any instance of
that class, even function-local ones that would otherwise be
stack-allocated.
That's where the bad reputation of C++ comes from, I guess?
Part of P0102, funded by Yanga.
First off: 👏 Just 👏 pass 👏 a 👏 reference 👏 to 👏 the 👏
currently 👏 iterated 👏 pellet 👏 if 👏 you 👏 need 👏 to 👏
modify 👏 it 👏
Second: Don't we hit-test pellets vs. shots already, in the CShots
class? So what is this garbage…?!
Completes P0101, funded by Yanga and Ember2528.
Actually quite cute with their hardcoded limitations, since the created
patterns do follow a clear logic.
But yeah, no 6-way spreads for you, we only support 2-, 3-, 4-, and
5-way ones here :zunpet:
Part of P0101, funded by Yanga and Ember2528.
Look, an unused pellet motion type! Which doesn't work as intended
thanks to no fewer than 3 ZUN bugs in one single if() expression.
Part of P0100, funded by Yanga.
A 4227-byte structure, with 100 pellet_t instances followed by a few
other data members. A textbook example of why you can't just quickly
get full position independence by parsing individual lines of ASM.
Part of P0100, funded by Yanga.
Also great news for those people who want to remove any and all C++ in
their mods, because this forces us to spell out subpixel literals as
actual floats, every time. And with that, you're back to being able to
simply search-replace for all the instances you'll have to change.
Part of P0099, funded by Ember2528.
And immediately, we discover another two hardcoded sprites, with, of
course, another set of functions for blitting and unblitting them…
Part of P0099, funded by Ember2528.
1 wrong byte of ASM that slipped through due to a off-by-one error in
an experimental mzdiff branch. Having MOV rather than LES here was
ultimately a harmless mistake though. In context, it's even covered by
the "identical instruction encoding" exception 🙂
nmlgc