Much more than usual, now that we've got a snappy build system! This
commit covers
• All .PI functions across all games
• TH02's High Score entry functions
• TH03's shots_update() and shots_render()
• All functions declared in `th04/op/op.hpp`
• TH04/TH05's bb_txt_put_8_raw(), bullet_template_clip(),
player_pos_update_and_clamp(), score_update_and_render(), and
slowdown_frame_delay()
• TH05's reimu_stars_update_and_render(), score_delta_commit(),
stage2_invalidate(), stage2_update(), and space_window_set()
Part of P0284, funded by [Anonymous] and Blue Bolt.
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.
The asymmetry of having to do this for TH05's resident structure but
not for TH04's has finally become annoying enough.
Part of P0263, funded by [Anonymous].
By now, it has become clear that this the norm rather than the
exception among these units. Thankfully!
Part of P0245, funded by [Anonymous], Blue Bolt, Ember2528, and Yanga.
I could have equally argued the opposite way, and in favor of `sgm` and
`ofs`, but I've also been using `seg` and `off` more prevalently
throughout the years.
Part of P0245, funded by [Anonymous], Blue Bolt, Ember2528, and Yanga.
Yet another master.lib-inspired function that accesses `super_patdata`,
found in 2023. Only used for the star shapes during bomb animations,
and the various shapes in Stage 6 Yuuka's background.
Part of P0241, funded by [Anonymous] and Blue Bolt.
If we double down on this concept by defining all needed prefix and R/M
opcodes, the code turns out much simpler if we __emit__() even the
basic, non-broken case. And if the inlined functions directly take
the opcode bytes as parameters, we don't even need templates.
Completes P0227, funded by nrook.
Short, sweet, fits more nicely into 8.3 filenames than "curve bullets"
does, and 76.7% of fans agree:
https://twitter.com/ReC98Project/status/1500256959785746434
OMAKE.TXT calls them "homing lasers", but… eh, nah.
Part of P0190, funded by nrook.
One of the rare cases where explicitly spelling out the FP_SEG() cast
is better than just calling the C++ wrapper: To drive home the point
that this code relies on `far` pointer semantics. Running the dialog
script performs arithmetic on only the offset part of this pointer, and
the segment part must remain unchanged for this hmem_free() call to
work as intended.
Completes P0186, funded by [Anonymous] and Blue Bolt.
Mostly centered around the HUD, popup, overlay, boss, and player shot
functions we're about to reference in the upcoming decompilations.
Part of P0186, funded by [Anonymous] and Blue Bolt.
If the macro itself is local to a function, these can work in certain
scenarios, but never for global ones.
Part of P0186, funded by [Anonymous] and Blue Bolt.
The single underscore version is actually slightly more supported among
the compilers I've seen so far. Also added the exact list now.
Part of P0183, funded by Yanga and [Anonymous].
Aha! TH05 actually loads every single rendered dialog image
individually before rendering it, either from the EMS area or disk.
That's one way to save memory, I guess?
Part of P0169, funded by Blue Bolt.
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].
Not exclusively used for the boss entrance animations, even though its
data is declared in that general vicinity. It's also used for all bombs
in TH04, and Reimu's and Yuuka's bomb in TH05.
Part of P0147, funded by -Tom- and Ember2528.
We really wouldn't have wanted to start writing inline ASM in the
middle of a conditional expression just to get that janky `CMP AX, 0`
instead of TCC's sensible `OR AX, AX` optimization.
Part of P0146, funded by -Tom- and Ember2528.
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.
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].
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.
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].
Reason: Pascal calling convention with function parameters but no stack
frame. Theoretically we can __emit__() everything inside this function,
but there's no way we can get a `RETN 8` this way. Oh, and it also
accesses SI and DI without backing them up to the stack.
And thanks to TLINK apparently not reporting fixup overflows when
segments are small enough (?), it took quite a while to get that CALL
correct and not weirdly offset by 32 bytes. 😕
Part of P0134, 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].
Turns out that ARG RETURNS is only really necessary in DEFCONV
functions, which are explicitly declared to use either the C or PASCAL
calling convention. In functions without such a declaration, ARG by
itself works just fine, and won't emit any instructions on its own.
The parameter lists for PASCAL functions still have to be reversed in
that case, though… oh well, let's just comment these cases to hopefully
reduce the confusion.
Part of P0134, funded by [Anonymous].
`cPtrSize` is simply the wrong constant for calculating parameter
offsets on the stack, because it corresponds to the memory model's
default distance, not the function's distance. Luckily, ARG has a
RETURNS clause, and if you declare all parameters in there, ARG won't
emit that pesky and unnecessary `ENTER 0, 0` instruction. Big discovery
right there!
Sadly, ARG is unusable for ZUN's silly functions that keep the base
pointer in BX. TASM declares the resulting equates as `[BP+offset]`,
and it's apparently impossible to only get `offset` out of such an
equate later.
So, rather than staying with numbers, let's reimplement ARG for these
functions instead. This way, we can even abstract away the stack clear
size for the `RET` instructions.
It's a bit rough around the edges though, forcing you to explicitly
specify the function distance, and to pass the parameters in reverse
order compared to the C declaration (thankfully, all of these use the
PASCAL calling convention). It also doesn't work with more complex
types yet. But certainly better than numbers.
Part of P0134, funded by [Anonymous].
nmlgc