And once again, SinGyoku is the only boss to get its own variable.
Maybe this means that it was the first boss to be implemented after
all?
Part of P0131, funded by Yanga.
And we're right back to things not being nice. Because yeah, why
shouldn't these three distinct rendering functions be part of a single
function, selected by magic numbers?
Or why shouldn't the 16×16 wrapper around a 32×32 set of graphics
functions be used to handle backgrounds for 16×8 sprites, resulting in
needlessly complex parameter calculations that lead to sloppy code?
Part of P0131, funded by Yanga.
Nice GRCG use! The 8 dots of its tile register, which are commonly just
set to the same color value, can of course hold an arbitrary bit
pattern for every bitplane. This allows you to get different colors for
every pixel, with still just a single VRAM write of the alpha mask to
one bitplane.
And I thought TH01 only suffered the drawbacks of PC-98 hardware, and
made so little use of its actual features that it's perhaps not even
fair to call it "a PC-98 game"…
Completes P0130, funded by Yanga.
Made truly generic by its use in both the upcoming boss collision
handling, as well as some SinGyoku pellet spawning function.
Part of P0130, funded by Yanga.
And with that, TH01 is pushed over the 50% completion mark! 🎉
This time, it's only YuugenMagan who gets no own copy. Giant RE% gains
from all these calls, but let's hope I don't regret already decompiling
this one for all bosses. It's not quite at the beginning of SinGyoku's,
Mima's, and Elis' code segment, after all…
Part of P0130, funded by Yanga.
The placement at the beginning of Kikuri's code segment makes you think
this is only used for the barely noticeable white-in effect during
Kikuri's entrance animation. It's also used to periodically reset boss
sprite colors during the flashing effect after getting hit by the Orb,
though.
Part of P0130, funded by Yanga.
Lol @ Konngara decompilation being blocked by this giant card-flipping
function that took 2 pushes to understand, only for it to start with
if((stage % 5) == 4) {
return;
}
…
Completes P0129, funded by Yanga.
This is where the code generation actually confirms the SoA layout of
the global obstacle structure, rather than it being distinct pointers.
Part of P0129, funded by Yanga.
Continuing the good error handling from the .PTN functions they're
based on… if only its sole caller actually cared.
Also: A sort-of limit of 102 objects per stage, just because someone
didn't use huge pointers where they would have been necessary…
:tannedcirno:
Part of P0128, funded by Yanga.
Case in point: This structure member, which is located after all the
obstacle members. Sure, it'll look weird to see this one initialized by
a class method, but it'll be much weirder to somehow group both cards
and obstacles into one class.
Part of P0128, funded by Yanga.
And another one for all the obstacle types we saw earlier. The original
game probably combined all SoA pointers for both cards and obstacles
into a single "stage object". But that'll get way too unwieldy in the
functions later, given that those aren't even methods, and simply
reference one global variable. `stageobjs.obstacles.member`… yeah, no.
Part of P0128, funded by Yanga.
Sure, a SoA layout might actually be genius and what you should be
doing most of the time on modern systems, but you still wouldn't
allocate every member separately.
Part of P0128, funded by Yanga.
An enum to distinguish between bumpers, turrets, portals, bumper bars…
and cards that have to be flipped more than once?!
Part of P0128, funded by Yanga.
Rather than preferring either the Microsoft/Watcom `(in|out)pw?` style,
or the Borland `(in|out)portb?` style, master.lib had to introduce its
own `(OUT|IN)P[BW]` naming scheme… Insert obligatory xkcd standards
comic.
Part of P0126, funded by [Anonymous] and Blue Bolt.
And get rid of the constraining FX() macro, with its spacing parameter
that we haven't even seen used so far.
Part of P0124, funded by [Anonymous] and Blue Bolt.
*Still* no need for the classic `if(ptr) { delete[] ptr; ptr = NULL }`
macro, because who cares about dangling pointers anyway, right?
:zunpet:
Part of P0123, funded by Yanga.
All this CPU time spent optimizing the unblitting mask, yet the code
still ends up glitching if the two sprites are more than 2 horizontal
bytes away. So, Reimu's slide speed can only be as high as 8 pixels per
frame, before this function fails to unblit the previous sprite and
leaves little Reimu parts in VRAM.
Part of P0123, funded by Yanga.
"Let's add a row to the offset, and then subtract it again" :zunpet:
This could only *possibly* have been intended as a DoS attack against a
future manual decompilation, right?
Part of P0123, funded by Yanga.
Two ZUN bugs in a single function call! These end up causing
effectively random sprite pixels to disappear during the transition to
the boss clear tally screen, if the boss was killed while any shootout
lasers were on screen. And once again, one of those bugs would have
been a non-issue with strong enough typing…
Oh well, that's all there is to this class.
Completes P0122, funded by Yanga.
Not to be confused with stationary lasers (as used by YuugenMagan, for
example), which are just regular lines with collision detection. 🥴
Also, 22 unused bytes out of 69, with another 11 that could have easily
been exchanged for better code…
Part of P0122, funded by Yanga.
So ZUN *did* want to clip those at the left and right edges of VRAM,
but accidentally tested the Y instead of the X coordinate 🎺
Part of P0121, funded by Yanga.
Wait, so if this is only used for the rotating white squares around
Mima, that must mean that the white star in the YuugenMagan fight got a
completely redundant reimplementation…
Part of P0121, funded by Yanga.
In which ZUN accidentally the GRCG rather than the EGC in what should
have been (?) the unblitting function. Which then ends up actually
blitting yet another randomly background-masked version of the same
sprite on top of the old one. And after just a few frames, you get
those fully filled red diamonds you don't see in the sprite sheet.
Then again, if the 16w×h rectangle unblitting function is all you
have, and you can't be bothered to actually learn the EGC, this *is*
the better option 🎺
Completes P0120, funded by Yanga.
Not only getting rid of the "useless" (and thankfully, consistent)
bitplane parameter, but also allowing those shortened macros to be
redefined for the upcoming little ZUN inconsistency.
Part of P0120, funded by Yanga.
The usual case where ZUN should have just written a custom EGC-powered
unblitter, instead of resorting to the word-aligned rectangle one…
Part of P0120, funded by Yanga.
I'm still impressed that something like this perfectly inlines in every
place that uses this functionality so far. Maybe something about each
parameter only being used once inside the single expression of the
function?
Part of P0120, funded by Yanga.
What was the thought process behind this inconsistency?! Oh well, that
was still an entire class decompiled for almost free.
Part of P0120, funded by Yanga.
I did consider calling them "boss ａｅｓｔｈｅｔｉｃｓ" instead, but
that didn't really seem to fit Sariel's dress and wand animations,
which are the only things this class is used for. Or does it?
Part of P0120, funded by Yanga.
Still no need for the classic `if(ptr) { delete[] ptr; ptr = NULL }`
macro, since the `ptr` is unconditionally set to NULL here…
Part of P0120, funded by Yanga.
… now that we have a better idea about the differences of both classes.
Also, no transitive dependency on bos.hpp for either class.
Part of P0120, funded by Yanga.
We've been establishing `screen` as meaning "a coordinate rooted at the
top-left corner of the display", whereas most of the Subpixels in >TH01
are rooted at the top-left of the playfield.
Part of P0112, funded by [Anonymous] and Blue Bolt.
… and this one, while I'm at it. I've been using pretty much every
possible type for VRAM offset variables, depending on my mood that day,
since signedness apparently never matters for those.
Except that it does. And so, just like with most of our high-level
types, we also have to account for ZUN's little signedness
inconsistencies here. Oh well, at least it's now only one of two types,
and there's no need to choose between `int` or `unsigned int` or
`short` or `unsigned short` or `int16_t` or `uint16_t` or `size_t` or…
Part of P0111, funded by [Anonymous] and Blue Bolt.
Whew, time to look at every `int` variable we ever declared! The best
moment to do this would have been a year ago, but well, better late
than never. No need to communicate that in comments anymore.
These shouldn't be used for widths, heights, or sprite-space
coordinates. Maybe we'll cover that another time, this commit is
already large enough.
Part of P0111, funded by [Anonymous] and Blue Bolt.
A function which does so many individual things that I can't even
summarize it in a comment without spelling out each line of code. And
then, this entire clamped movement system is only used for Kikuri's
soul sprites. The usage code for every other entity just parties on
the [cur_left] and [cur_top] members, and passes a delta of (0, 0) to
this function. 🤷
Part of P0108, funded by Yanga.
Yet another unused function. No idea what it could have been intended
for – no boss sprite has animated sections that small.
But come on, out of all places that could have required the macro form
of a VRAM offset function, it had to be a unused one…
Anyway, that completes the low-level blitting functions for boss
entities!
Part of P0108, funded by Yanga.
Another unused function! This might indicate that Elis could originally
split herself into two sprites, similar to TH04 Stage 6 Yuuka?
Or it might just have been some other kind of animation effect, who
knows.
Part of P0108, funded by Yanga.
Used for Elis' entrance animation. Including an unused unblitting +
blitting function – apparently, ZUN wrote that one before the sloppy
EGC-accelerated wavy unblitting function that I decompiled way back in
6d2fa9f.
Oh well, the latter one is fine in context, since there are no other
sprites on screen during the animation.
Part of P0108, funded by Yanga.
… except that those single-plane functions provide basically no
useful abstraction in the context of a 4-plane image format. Should
have just gone all the way and directly take something like our
Planar<dots16_t> type to operate on all 4 planes, so that I wouldn't
have had to add that layer of abstraction myself.
Apparently, early ZUN was allergic to passing structures by reference?
Part of P0107, funded by Yanga.
Yes, functions! Those would have been nice earlier!
Also documented another overly specific Borland C++ code generation
quirk with regard to assigning expression results to elements of 16-bit
arrays…
Part of P0107, funded by Yanga.
"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.
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.
nmlgc