This commit covers
• TH02's ZUNINIT errors,
• TH02's main menu,
• the init/exit functions in all 4 remaining games,
• TH03/TH04/TH05's configuration file functions, and
• TH04/TH05's tile rendering functions.
Part of P0258, funded by [Anonymous] and Blue Bolt.
"1D polar vectors" are a weird concept to wrap your head around,
especially if their constructor function takes a sine or cosine ratio
instead of an angle. This function is way closer to the polar_*()
family, which has these convenient `_x` and _y` suffixes that we could
just remove for this generic function to fit into there.
Part of P0244, funded by Blue Bolt and [Anonymous].
"I don't need the return value in MAINL.EXE? Let's copy-paste the
function and remove all of its `return` statements then!" :zunpet:
Completes P0172, funded by [Anonymous] and Blue Bolt.
Featuring inline assembly for a single ROR instruction. Turbo C++ 4.0J
unfortunately only offers intrinsics for 16-bit rotations.
Part of P0172, funded by [Anonymous] and Blue Bolt.
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.
Segment alignment issues once again… but that completes the SHARED
segments of all TH03 and TH05 binaries, for now!
Part of P0139, funded by [Anonymous].
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.
Exhibit B for the theory that ZUN did *not* set the default calling
convention to `pascal` for TH03.
Part of P0138, funded by [Anonymous] and Blue Bolt.
Exhibit A for the theory that ZUN did *not* set the default calling
convention to `pascal` for TH03.
… Then again, at this point, it's way more likely that ZUN simply
didn't have a unified build setup for any of the games, and rather
pieced them together with manually compiled .OBJ files.
Part of P0137, funded by [Anonymous].
Lovely. Turns out that all it needed to motivate the previous research
was one function that is simply too precious to be kept in ASM…
Part of P0137, funded by [Anonymous].
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.
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.
Nice to see that Borland C++ optimizes bit-tests to cover just the high
or low byte of a word if possible, and that these don't have to be
two-byte structures after all.
Completes P0114, funded by Lmocinemod.
Wow, this is the first time we're about to call any of these from C
land in ≥TH03? Found no built-in way to just uppercase an identifier
in TASM, so apparently we have to spell out the names in both lower-
and uppercase.
So, let's go back to regular, non-macro PUBLIC / PROC / ENDP code
wherever we can – for all functions introduced in ≥TH03, and for
everything that takes no parameters. It's simply not worth the
trouble.
Part of P0114, funded by Lmocinemod.
In which we exchange variable names for the ability to decompile more
than just 3 instructions here.
… yeah, "decompilation" is still a stretch.
Part of P0114, funded by Lmocinemod.
About time I finally developed this piece of tech. Towards TH05, this
segment got more and more undecompilable ASM functions mixed inbetween
C ones. Which means that pretty much all of the current ASM land
`#include`s in that segment will have to become translation units. And
we *really* don't want an additional layer of numbered, per-binary
translation units that just `#include` maybe one or two functions.
Also yeah, no _TEXT suffix, to drive home the point that this is a
"library" segment, and not really "owned" by any one file.
Part of P0113, funded by Lmocinemod.
No need to make the function names more complicated if we already
expressed the one subtle format difference between TH03 and TH04/TH05
in the plane layout enum.
Part of P0113, funded by Lmocinemod.
Also something that any future ReC project should be doing right at the
start. Finally, it made sense to do it here as well, because…
Part of P0084, funded by Yanga.
And with all possible .COM executables decompiled, this set of changes
reaches an acceptable scope, allowing us to *finally*…
Part of P0077, funded by Splashman and -Tom-.
The supposedly low-hanging fruit that almost every outside contributor
wanted to grab a lot earlier, but (of course) always just for a single
game… Comprehensively covering all of them has only started to make
sense recently 😛
Also, yes, the variable with the uppercase .CFG filename has itself a
lowercase name and vice versa…
Part of P0077, funded by Splashman and -Tom-.