The pascal calling convention for TH03's input mode functions actually
sort of matters, since we have this nice function pointer type that
expects pascal.
Not applying this leak to TH03 since it would have more than one
`key_det` variable, resulting in names that are as much fanfiction as
the current ones…
Yes, decompilation, of something that was so obviously originally
written in ASM. We're still left with two un-decompilable instructions
here, but I'm amazed at how nicely I was able to abstract away all of
the gory register details, leading to pretty clear, readable, and dare
I say *portable* code?! Turbo C++ was once again pretty helpful here:
• `static_cast<char>(_BX) = _AL` actually compiles into `MOV BL, AL`,
as you would have intended,
• and no-op assignments like _DI = _DI are optimized away, allowing
us to leave them in for clarity, so that we can have all parameter
assignments for the SPRITE16 display call in a single place.
I love this compiler.
Part of P0060, funded by Touhou Patch Center.
And the explicit permission to also do something as seemingly trivial
as naming functions or data on separate branches, which apparently
still needed to be said somewhere.
Raw, uninteresting position independence work. Or maybe not, given that
this was one of the few things that also apply to TH01, and reveal just
how chaotically this game was coded. And so we've got three ways that
ZUN stored regular 2D points: Regularly (X first, Y second), Y first
and X second, and multiple points stored in a structure of arrays…
Completes P0059, funded by [Anonymous] and -Tom-.
In the end, the explosions remain the only constant in these phases,
everything else ("defeat"? "last phase"?) could have been
misunderstood. And yes, the algorithm really treated these 111
constants as potential memory references…
Completes P0058, funded by -Tom-.
Yup, function parameters that can clearly be identified as coordinates
are by far the fastest way to raise the calculated position
independence percentage. Kinda makes it sound like useless work, which
I'm only doing because it's dictated by some counting algorithm on a
website, but decompilation will want to un-hex all of these values
anyway. We're merely doing that right now, across all games.
Part of P0058, funded by -Tom-.
> not using the Point structure, which is not only perfectly suitable
here, but would have also generated much better code
Part of P0058, funded by -Tom-.
Welcome to this new [brand] of reverse-engineering, where we only fix
things that might be mistaken for addresses, without looking deeper
into what the actual functions do… unless that directly leaps into
the eye.
Part of P0057, funded by [Anonymous] and -Tom-.
"Splashes"? That's what uth05win calls them. Oh well, "circle" is
already taken, and merely keeping the slices in the item/ directory
won't avoid the name collision when looking at game code.
These are hardly visible on top of regular enemy explosion animations;
you can most clearly see them at the end of the TH04 Extra Stage
midboss. Easy enough to *almost* completely cover right now, even
during a position independence push. Struct strITEM_SPLASH in uth05win.
Part of P0057, funded by [Anonymous] and -Tom-.
Well, that might have been my entire sales pitch for the decompilation,
and now I've ruined everything… Still, I've been getting way too many
confused questions about this by now. Let's focus on reconstructing,
and once that's done, ReC98 is done, and another project can take over.
Maybe done by me and mostly following the original plans, but probably
not.
Thanks to -Tom- for finally pushing me to do this 😛
Apparently, people might have misunderstood this to mean "we've found
SPRITE16, so TH03 is now 74% (OP) / 54% (MAIN) done"? Thanks to
Splashman for the tip.
Aha! TH03's in-game graphics run in line-doubled 640×200 simply because
that's what this SPRITE16.COM version was written for, making use of
the PC-98 EGC for optimized blitting.
Doesn't seem all *too* optimized though, given that it chooses to
effectively draw every sprite twice, just in case it might overlap with
something that's already in VRAM. It first clears the previous VRAM
content at the drawing position according to the sprite's alpha mask,
then ORs in the actual sprite data. The EGC can do monochrome alpha-
tested blitting just as well as the GRCG, but once the sprite data
covers all bitplanes, ORing is apparently the best it can do by itself?
More technical details on the raster operations in the next push!
Completes P0056, funded by rosenrose and [Anonymous].
Which was actually found out by @m1yur1 last year, who thankfully
tweeted this in reference to ReC98:
https://twitter.com/m1yur1/status/1018855232371998720
Thanks a lot! But what makes this more than a piece of trivia is the
fact that the StormySpace release actually *was* bundled with
documentation. Shoutout to the Neo Kobe PC-98 collection for preserving
the original release! This should now greatly simplify any RE efforts
related to TH03's INT 42h calls. (Not *trivialize*, because there's
still all this EGC hardware to be understood…)
And sure, you *were* allowed to use this driver in your own game, but
replacing the copyright with your own isn't exactly the nicest thing to
do… That now makes three library programmers that ZUN didn't credit.
Makes me wonder what makes M. Kajihara so special. Probably the fact
that Touhou has always been about the music for ZUN, first and
foremost.
Part of P0056, funded by rosenrose and [Anonymous].
I thought this would be a good target for my first attempt at
decompilation. Should have known something was up, because it's the only
undecompiled proc in the translation unit.
Oh well, SCOPY stands for "structure copy" anyway. /s
nmlgc