We're going to need some name for the longer, boss-specific danmaku
animations. Turns out that these are exactly called "patterns" in
Sparen's glossary:
https://sparen.github.io/ph3tutorials/ddsg0.html#sub4
So what we called a "pattern" is actually called a "group". Whoops!
Part of P0142, funded by Yanga.
Amazing how both an `int` and an `unsigned char` parameter generate the
exact same ASM if they're only passed on to a single function that
widens them to a 16-bit type.
Part of P0142, funded by Yanga.
It's script-like code, what can you say. Maybe minimally sloppy in some
places, but ultimately harmless.
Oh, the Siddhaṃ seed syllables are supposed to show up immediately, with
no delay between them? Good to know – clocking your emulator too low
tends to roll them down from the top of the screen, and does add a
noticeable delay between the individual images.
… Wait, but this means that ZUN could have *intended* this "effect".
Why else would he not only put those syllables into four individual
images, but also show them on the foreground VRAM page?
Completes P0141, funded by [Anonymous] and rosenrose.
ASM land had a macro for this, which suggested a corresponding inlined
class method in C++ land. We couldn't use that macro for Konngara's
third boss entity though. So I probably wanted to wait with that inline
function until the decompilation of that Konngara load call, which
could verify the existence of said inline function. And it did!
Part of P0141, funded by [Anonymous] and rosenrose.
We've got to move all of Konngara's escape sequences to C land right
now, to get them out of the way of the filenames, so we might as well
look at all of them, in the entire binary.
But, uh… "graph mode"? That one is severely underdocumented, seemingly
even in Japanese. Turns out that it's a way to disable Shift-JIS
decoding, which makes it possible to access the half-width glyphs in
the PC-98 font ROM at the 0x81-0x9F and 0xE0-0xFF codepoints.
(In regular "kanji mode", these are interpreted as Shift-JIS lead
bytes.)
So, I did a deep dive into NEC's IO.SYS to hunt down all places where
this distinction has an effect, and then implemented it into DOSBox-X,
which was still missing everything related to it:
https://github.com/joncampbell123/dosbox-x/pull/2547
If P0140 looks a bit empty as a result, that's why – most of the
feature work went into DOSBox-X, not ReC98. That's the beauty of
"anything" pushes. :tannedcirno:
So, after switching to graph mode, TH01 does… one of the slowest
possible memset()s over all of text RAM (one printf(" ") call for every
single one of its 80×25 half-width cells), before switching back to
kanji mode. What a waste of RE time…? Oh well, at least we've now got
plenty of documentation to prove to future port authors that these
weird escape sequences *actually* do nothing.
Completes P0140, funded by [Anonymous].
At least that's what we can infer from its position in the code.
Putting it into player shots for the sole reason that it's easier to
find it there.
Part of P0140, funded by [Anonymous].
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.
DOS is not the same thing as the underlying CPU, after all. A separate
file not only indicates to future port authors which parts of the code
are x86-specific, but it also speeds up build times…
… in theory, because removing 677 lines from 49 files each doesn't seem
to speed up the build as much as I had hoped? But apparently my whole
system mysteriously got faster in the meantime, and I was getting 22-23
seconds for the entire repo even before this commit. Good enough.
Part of P0134, funded by [Anonymous].
Functions with 12 parameters are hard to describe, y'know. Looking
forward to decompiling these giant expressions for the actual
boss↔orb collision parameter passed to this function…
Oh well, at least we're now totally ready for some boss code next
year. 😌
Completes P0131, funded by Yanga.
Yes, no "generator", just a single number. Used to add some very
minimal randomness to certain things, by taking it modulo a small
number.
Part of P0131, funded by Yanga.
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.
nmlgc