The main point of the previous strings/ subdirectory was to bundle all
hardcoded strings for translators. And sure, *technically*, gaiji
strings are *both* strings *and* something you might want to translate.
But mainly, they're sprites with an attached enum, and their own
directory. Changes to the enum quickly tend to involve changes to the
strings that use these values, so it makes sense to keep both in the
same directory.
Especially since 82% of the previous strings/ directories consisted of
such gaiji strings.
That leaves the strings/ directory rather empty and nondescript though.
Recently though, I've been wanting to generally move all Shift-JIS text
to this directory. While that wouldn't *solve* the typical "text editor
accidentally a file upon save, due to wrongly detected encoding" issue,
it's at least a mitigation: If all Shift-JIS strings are in files that
contain nothing *but* Shift-JIS strings, a wrongly detected encoding
becomes immediately noticeable.
For that job, strings/ can have a more descriptive name though. Hence,
shiftjis/.
Part of P0141, funded by [Anonymous] and rosenrose.
Whoops, turns out that the build has been broken on TASM32 version 5.3
(the one in the DevKit) ever since 7897bf1. In contrast to version 5.0
(which I use for my development), 5.3 actually defines 32-bit segments
if you specify a .386 CPU before using .MODEL.
That might have been the reason for the .286 workaround all along?
Turns out there's the USE16 modifier, which makes this much more
explicit than switching CPUs.
Eh, REP MOVSD is used too inconsistently across the games to justify
replacing these macros with an `inline` function. Still can use a
custom one here to make the register usage a bit more explicit, though.
Part of P0136, funded by [Anonymous].
Almost undecompilable, until you remember that you can inhibit the
optimization of keeping a function parameter in a register by having an
`inline` function take a reference. Yet another function that wouldn't
have decompiled that nicely if we had restricted us to C…
Part of P0136, funded by [Anonymous].
Not that it really fits there either, but I've been trying to keep the
th0?/ directories free from any actual code. They should only contain
the distinct translation units within the original three .EXE binaries,
`#include`ing files from subdirectories, along with maybe game-specific
`#pragma`s, but contain no code on their own. Port authors would simply
ignore those, and link everything from the subdirectories into one
binary. That approach has seemed to make the most sense for all of this
so far.
Part of P0135, funded by [Anonymous].
A decompilation of ZUN-written ASM that was almost worth it, for once!
Too bad that those aren't the <string.h> intrinsics that the
Wolfenstein 3D disassembly hinted at, though.
Part of P0135, funded by [Anonymous].
That assembly is *worse* than what you would have gotten out of your
1994 C++ compiler with the 386 code generation switch!
Part of P0134, funded by [Anonymous].
> assigning to the DI register immediately before a CALL
Yeah, no amount of comma operator trickery can get *that* out of this
compiler. Also, these TH05 .PI functions are the only place in PC-98
Touhou with a `IMUL DI, imm8` instruction, which is impossible to get
out of Turbo C++'s built-in assembler.
Well, at least the `if` branches decompile somewhat nicely.
Part of P0134, funded by [Anonymous].
… especially because this one *is* actually undecompilable. Reason:
Base pointer assignment to BX, before saving the SI register on the
stack.
Part of P0134, funded by [Anonymous].
Well, it *would* have been decompilable, but that ridiculous placement
of the nullptr assignment would have forced the entire function call to
be spelled out in inline ASM, verbatim. No amount of comma operator
trickery would have generated the same instructions either. And for a
function this small and obvious in what its decompilation *should* be,
it really defeated the purpose of adding a separate translation unit…
Part of P0134, funded by [Anonymous].
Reason: Manual "tail call optimization" of input_reset_sense(), with
execution falling through to input_sense() immediately below.
Part of P0133, funded by [Anonymous].
Umm… but this can't be in the same translation unit as frame_delay(),
because OP.EXE has cdg_put_nocolors() inbetween, which means we'd have
to compile it twice.
What probably happened there: ZUN originally wrote this in C when
frame_delay() was still next to it, then generated ASM from it,
tinkered with that, and ultimately only linked that ASM into the final
game, with the NOPCALL still in there. That might very well be the one
temporary NOPCALL workaround we can never get rid of…
Oh well, at least we got lucky with the padding, and can keep the
cdg_put_nocolors() decompilation from the last commit.
Part of P0133, funded by [Anonymous].
Finishing this push with another highly questionable one… Let's hope
that the port developers will certainly appreciate that they just have
to remove the weirdness here, and not mess with defining entirely new
functions in C land.
Completes P0127, funded by [Anonymous].
Undecompilable again. The loading functions have these *_noalpha()
variants that simply set a global variable and fall through to the
regular functions, while cdg_free() has its first `PUSH DI` instruction
after the first expression we'd be decompiling. cdg_free_all() *could*
be decompiled… but would also require _FLAGS trickery, and it's simply
not worth starting a translation unit for one such small function.
Part of P0127, funded by [Anonymous].
Actually fairly average, as far as unreasonable decompilations are
concerned. No `goto`, at least! Another place that would benefit from
EGC raster op documentation, though.
Also, got one more padding byte in TH05's MAINE.EXE correct. 🙂
Part of P0126, funded by [Anonymous] and Blue Bolt.
There's the better name, in ALLCAPS for improved grepping. TH01 is also
going to need a pseudo-binary to bundle translation units that appear
in more than one .EXE, and since "segment 2" would be wrong for that
game, it makes more sense to have one consistent name for these
pseudo-binaries in all games.
(Maintenance mode commit)
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.
By now, it's become obvious where it has to be. Apparently, the order
of translation units inside ZUN's modified master.lib did somehow
change with TH02?
(Maintenance mode commit)
I didn't know that extra staff roll cutscene order is different for
each character --WindowsTiger
Final actual data references in TH05's MAINE.EXE! 🎉 --Nmlgc
Reviewed and merged as part of P0118, funded by -Tom- and Ember2528.
… with either the port or the argument in registers. This is one of the
few actually dumb concessions to the PI counter on the website.
Then again, binary *is* a better representation for the contents of the
GRCG tile register than hex…
Part of P0117, funded by [Anonymous].
28,160 bytes of global data just for a overly large 320×704 bitmap
that allows you to scroll between the general verdict and the
individual end-of-stage scores with the Up and Down keys. That's one
benefit of splitting your game into multiple executables, I guess?
Completes P0115, funded by Lmocinemod and Blue Bolt.
nmlgc