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.
Segment alignment forces us to do all of those at once… but now, we've
not only caught up with the segment split point in TH04's OP.EXE and
MAINE.EXE, but also decompiled all instances of DEFCONV functions!
Part of P0138, funded by [Anonymous] and Blue Bolt.
Boom! Clever segment renaming allows us to link the same .OBJ into 12
binaries.
(Well, 10 for now, due to alignment issues in TH04's OP.EXE and
MAINE.EXE.)
Part of P0138, funded by [Anonymous] and Blue Bolt.
So, we have a problem. The ridiculously optimized graph_putsa_fx() used
in TH04 and TH05 swaps out the target of two CALL instructions at
run-time… because there *really* wasn't any free register left for an
indirect CALL, eh? Therefore, the necessary relative addresses have to
be calculated at assembly time, by subtracting the target function
label from the call site label.
Unfortunately, the resulting values are stored in the .DATA segment,
which we can't move out right now. Declaring the labels as EXTERN
wouldn't work either, since the linker can't do fancy arithmetic and is
limited to simply replacing address placeholders with one single
address. This is explained pretty well at:
http://computer-programming-forum.com/46-asm/48f3d4a463bb38d1.htm
Which means we're stuck, and can't separate out this function for the
foreseeable future.
So, time to approach the SHARED segment from the top instead, to at
least get everything around graph_putsa_fx() done now. 🤷
vram_planes_set() is the first common function there. But since it was
introduced in TH01, we've got some maintenance to do for that game
first…
Part of P0138, funded by [Anonymous] and Blue Bolt.
Might look uglier, but has the advantage of not generating an empty
segment with the default name… *and* the default padding, which will
really come in handy with the following breakthrough.
Part of P0137, funded by [Anonymous].
eeb4e7e changed the final C translation unit that used this header to
C++, and we got some more helpful inline functions upcoming.
Part of P0136, funded by [Anonymous].
Allowing us to consistently mirror the declaration in pc98.inc
without adding a planar.inc file. 😛 And points us to two more
dots8_t* arrays that should have used the Planar<> template.
Part of P0135, funded by [Anonymous].
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].
It's not necessary for assigning `__seg` pointers to `far` ones, which
might even remove the <dos.h> dependency in some translation units.
Part of P0134, funded by [Anonymous].
This might have almost been the case that justified making master.hpp
compatible with C translation units… but even this one would like to
use the template functions from th01/math/vector.hpp.
Part of P0133, funded by [Anonymous].
Since I'd still prefer to not use include guards *and* to have that
standalone .GRZ viewer, these would have actually caused somewhat of
an issue with the upcoming final stretch of the master.hpp transition.
Part of P0133, funded by [Anonymous].
Might seem inconsistent, given that the function initializes pointers
that are declared in planar.h… but it's always called from other game
initialization functions that don't require pc98.h or planar.h.
Part of P0133, 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.
nmlgc