Second PC-98 Touhou boss completely decompiled, 29 to go! But meh,
ZUN's original code did in fact force the three leaf pattern sprites
into separate 1-sprite sheets…
Completes P0181, funded by Ember2528.
The one where Sariel's second form shoots sparks towards the top of the
playfield, which then turn into leaf-like sprites that sway towards the
bottom, killing Reimu on contact.
And wow, what a finish! A weird "decimal subpixel" type, hardcoded
sprites, and effectively unused non-hardcoded sprites. Too bad that it
also ruins the nice `dot_rect_t(w, h)` parameter abstraction for
grcg_put_8x8_mono()…
Completes P0180, funded by Yanga.
Stupid one-off functions deserve stupid names, Part 2. If it only
loaded sprites, I might have given it a somewhat better name.
Part of P0167, funded by Ember2528.
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.
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.
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.
The one where Konngara fires 4 diamonds in a cross-shaped motion
towards the edges of the screen, with random pellets raining down for
200 frames afterwards.
Completes P0142, funded by Yanga.
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.
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.
First ZUN bug in sprite preshifting! One wrongly shifted pixel means
that we can't use the auto-preshift feature of our sprite converter -.-
Also, why did these even have to be hardcoded sprites to begin with.
These dot patterns could have been easily generated procedurally… but
even *that* wouldn't have been necessary, given that there's this nice
function called, uh, graph_r_line_patterned()? Which could have
rendered all of the lasers in the upcoming class and more?
Part of P0122, funded by Yanga.
Some of the unused interleave masks are not that straightforward, so it
makes sense to have all of them as a bitmap. I'm positive that this
sort of thing could have been EGC-accelerated… although, simply
writing better C would probably already go a long way.
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.
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.
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.
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.
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.
A future sprite converter (documented in #8) could then convert these
to C or ASM arrays.
(Except for the piano sprites for TH05's Music Room, which are stored
and used in such a compressed way that it defeats the purpose of
storing them as bitmaps.
So even TH01 wasn't 100% C++ after all. Turns out that this function
was the only instance in all of REIIDEN.EXE where ReC98 previously had
different encodings for identical x86 instructions.
Part of P0096, funded by Ember2528.
nmlgc