Might as well cover this one while I've got this type of function in my
head. This one is used for the animated star backgrounds during Stage 2
and the Shinki battle.
Completes P0073, funded by [Anonymous] and -Tom-.
Which *looks* like a master.lib function, but only because ZUN adapted
his own micro-optimized super_roll_put_tiny() for 32×32. Good thing we
covered that one first!
Part of P0073, funded by [Anonymous] and -Tom-.
So, master.lib has:
• super_put_tiny() for tiny-format 16×n sprites
• super_roll_put_tiny() for vertically wrapped tiny-format 16×16
sprites
• super_put_tiny_small() for tiny-format 8×n sprites
• yet *no* super_roll_put_tiny_small() function
And now we have ZUN adding micro-optimized versions of:
1) vertically-wrapped tiny-format 16×16, clearly based on master.lib's
super_roll_put_tiny(), RE'd in 35f9bd7
2) vertically-wrapped tiny-format 32×32
3) vertically-wrapped non-tiny monochrome 16×16 (TH05 only)
Conclusion: Even though 1) does duplicate a master.lib function, trying
to continue following master.lib's inconsistent naming convention only
leads to more confusion here. master.lib also already designates the _8
suffix to mean "x will be byte-aligned, ⌊x/8⌋*8"…
So let's:
• spell out both coordinates of the sprite size directly in the
function
• keep the z_ prefix to encode ZUN's optimized calling convention
(left/top coordinates in registers, ES already set to the beginning
of a VRAM plane, GRCG already on) for all of these, not just 1).
• and prefix the actual functions with _raw, since C land will want
to handle the coordinate parameter registers in a macro.
Part of P0073, funded by [Anonymous] and -Tom-.
Which finally allows us to use the PLANE_SIZE macro in ASM land. Yeah,
(ROW_SIZE * RES_Y) has finally got old.
Part of P0073, funded by [Anonymous] and -Tom-.
And since everyone always cares about caps:
• TH04: 240 for the white 8×8 pellets, 220 for 16×16 sprites
• TH05: 180 for the white 8×8 pallets, 240 for 16×16 sprites
Completes P0072, funded by [Anonymous] and -Tom-.
夢時空.TXT calls this a "Gauge Power-Up", but that's both misleading
and too verbose, so let's go with how scoreplayers call it.
Part of P0071, funded by KirbyComment and -Tom-.
The _add function pointer is part of the 128-byte player structure,
that's why it's already named differently here 🙃
Part of P0071, funded by KirbyComment and -Tom-.
Yup, in the first 6 stages, the CPU always takes more damage per hit
than P1. 1½ hearts in stages 1 and 2, 1 heart in stages 3 and 4, and
½ heart in stages 5 and 6.
Part of P0071, funded by KirbyComment and -Tom-.
Probably going to refine those `pid_other` variables later; it almost
seems as if there's one to store the attacked player for every entity
type?
Part of P0070, funded by KirbyComment.
Little-endian BCD, again… Far less crazy than in TH04 and TH05,
though, thanks to updating and rendering being two different functions
here.
Part of P0070, funded by KirbyComment.
In which our typedefs mercilessly reveal ZUN's original sloppiness, and
the unncessary sign extension taking place here. Also, ❎ unused…
Completes P0069, funded by [Anonymous] and Yanga.
Yes, when clipping the start and end points to the screen area, ZUN
uses an integer division to calculate the line slopes, rather than a
floating-point one. Doesn't seem like it actually causes any incorrect
lines to be drawn, though; that case is only hit in the Mima boss
fight, which draws a few lines with a bottom coordinate of 400 rather
than 399. It *might* also restore the wrong pixels at parts of the
YuugenMagan fight, causing weird flickering, but seriously, that's an
issue everywhere you look in this game.
Part of P0069, funded by [Anonymous] and Yanga.
Templates would have been nicer, but as soon as you add just one
non-immediate parameter, Turbo C++ generates a useless store to a new
local variable, ruining the generated code.
Part of P0069, funded by [Anonymous] and Yanga.
TH01's (original) version also replicates the PC-98 text RAM's reverse
and underline attributes. Which was removed in later games,
interestingly and inconsistently enough.
Part of P0068, funded by Yanga.
I did consider not doing this, because "well, can't anyone who's
*actually* interested just diff the TH01 and TH02 implementations to
figure out the differences themselves", but that duplication ended up
feeling too filthy after all.
And hey, it's a nice excuse to update TH02's version to current naming
standards! 😛
Part of P0068, funded by Yanga.
Including the longest function present in more than one game among all
of PC-98 Touhou, and #23 on the list of longest functions overall,
which draws a 1-pixel line between two arbitrary pixels.
Completes P0067, funded by Splashman.
Semi-unused, that is, the one use of this function doesn't actually
move the rectangle to a different position. Ironically, the non-moving
back-to-front function immediately above *is* unused…
Also, too bad that stack order is the only reason we can't use structs
to combine all plane variables into a single object.
Part of P0067, funded by Splashman.
Previously sloppily mis-RE'd as "some page variable, idk", back in
2015…
Now also with a page number typedef. And yeah, restricting bool to C++
has now proven to be stupid after all.
Part of P0067, funded by Splashman.
Which store colors as GRB, as suggested by the structure's ID string.
Even master.lib's own functions add an additional XCHG AH, AL
instruction to get colors into and out of this format. MASTER.MAN
suggests that it's some sort of standard on PC-98. It does match the
order of ths hardware's palette register ports, after all.
(0AAh = green, 0ACh = red, 0AEh = blue)
Now we also know why __seg* wasn't used more commonly, as lamented in
c8e8e98. Turbo C++ simply doesn't support a lot of arithmetic on
segment pointers.
And then that undecompilable far call to a function within the same
segment, but inside a different translation unit…
Also, thanks again to Egor for the SCOPY@ hack that debuted in 0460072.
Would have probably struggled with this a lot more without that.
And *then* you realize that TH01 effectively doesn't even use the
resident palette. 😐
And yes, we're procrastinating the whole issue of potentially using
a single translation unit for all three binaries by using a common
segment name, because it *really* isn't that easy.
Completes P0066, funded by Keyblade Wiedling Neko and Splashman.
Right, PC-98 hardware only supports 4 bits per RGB component, for a
total of 4,096 possible colors. The 8-bit RGB color values we've been
seeing throughout the later games are a master.lib extension, to allow
for more toning precision. Which TH01, with all its NIH syndrome,
doesn't use.
And yup, that means templates in the most basic header files… Since
that would have meant renaming *everything* to compile as C++, I simply
made these types exclusive to C++ code, thcrap style.
Part of P0066, funded by Keyblade Wiedling Neko and Splashman.
The TH04/TH05 BGM/SE mode setup is a good example for code where
different structure field offsets will vanish completely upon reverse-
engineering. If we continued to use the per-game ID string as the
variable name, we'd only have another game-specific "difference" there.
Part of P0065, funded by Touhou Patch Center.
nmlgc