Almost three years after the big SHARED segment separation got
unfortunately stuck thanks to this function, it's finally done!
Part of P0265, funded by [Anonymous] and iruleatgames.
So anticlimactic, again…
Also, note how renaming the `end_sequence_t` constants to better match
their usage also simplifies the explanatory comment for TH04's
not-quirk.
Part of P0265, funded by [Anonymous] and iruleatgames.
With the implementation moved to the header, it makes sense to
duplicate the function in the unfortunate place where the filename is
supposed to be.
Part of P0265, funded by [Anonymous] and iruleatgames.
This commit covers
• TH02/TH03/TH04/TH05's frame_delay() and frame_delay_2() (finally!)
• TH02/TH03/TH04/TH05's game_init_main()
• TH02's graph_copy_rect_1_to_0_16()
• TH03/TH04/TH05's cfg_load_resident_ptr()
• TH05's piano_setup_and_put_initial() and piano_render()
Part of P0264, funded by [Anonymous] and Blue Bolt.
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.
One of which also has the convenient responsibility of adding or
subtracting a number from the skill metric…
Part of P0244, funded by Blue Bolt and [Anonymous].
Even that part's the same in these three games… except for the 27 small
places where it isn't, 7 of which are purely coding style cosmetics.
Completes P0224, funded by Splashman and -Tom-.
With the script parsing and picture/box rendering functions being as
interleaved as they are, it makes little sense to keep the cutscene
code in more than one translation unit. How would those translation
units even be called? This time, having everything in one file should
beat the few hundred preprocessor-removed lines of code that we end up
adding to each one of the three affected games – and ultimately, you'd
want to merge those systems into one translation unit anyway.
Part of P0224, funded by Splashman and -Tom-.
That only leaves the TH02 versions of this function that really should
have been defined at one central location.
Part of P0223, funded by Blue Bolt and rosenrose.
You can fast-forward through cutscenes by holding Escape in these
games?! And the script interpreter adds automatic line breaks?!
Part of P0223, funded by Blue Bolt and rosenrose.
Thanks to TH03 having text-below-picture cutscenes before stages 8 and
9, the `/end/` directory is the wrong place to keep this code. And as
we're soon going to see, this feature did evolve during these three
games.
Part of P0223, funded by Blue Bolt and rosenrose.
Including the pointless DOS I/O variation in TH05's MAIN.EXE.
I'm slowly running out of characters to remove from the first segment
name in that file, though…
Part of P0148, funded by [Anonymous].
It shouldn't need a comment to communicate that this function does in
fact not load all values from the .CFG file that are part of the
resident structure, but only loads and sets the global pointer to that
structure.
Part of P0148, funded by [Anonymous].
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].
nmlgc