The one where Sariel fires vertical 3-stacks with two spawners moving
from between the two bottom edges of the playfield, followed by
randomly raining bullets from two spawners moving between the two top
edges of the playfield. Final pattern of Sariel's first form, and
surprisingly fair by never spawning pellets on top of Reimu.
Also, about time I found a way of bypassing the -Z -3 function
parameter optimization in order to keep using nice structures like
these.
Part of P0179, funded by Ember2528.
> use 64-bit floating-point for particles that move on strictly
one-dimensional lines
> use integer pixels for particles with a sine wave motion
Part of P0177, funded by Yanga.
One of the hardest decompilations in a long while:
• Required new research into code generation for pointer arithmetic
• ZUN needlessly calculating intermediate results over and over again,
making the function tedious to read
• GRCG reads in TCR mode, which I haven't seen so far either
Part of P0176, funded by Ember2528.
Yup, it's a compiler bug, and it removes a small bit of freedom as far
as decompilation order is concerned. In particular, this means that we
can't do TH01's continue and pause menus before having decompiled the
bomb animation.
Would have been nice to pad out the previous push with those, but
instead, I had to spend way too much time figuring *this* out…
Completes P0161, funded by [Anonymous].
The one with lasers fired from the sword across the whole playfield,
either from left to right or from right to left, together with aimed
3-way spreads, every 10 frames.
Part of P0155, funded by Ember2528.
… (24 + (difficulty * 8) + rank) in TH04, and (42 + (difficulty * 8))
in TH05. Also, TH05 only doesn't have TH04's bullet zap animation
because ZUN didn't consistently use constants…
Completes P0151, funded by Blue Bolt and -Tom-.
`switch` statements compiling to binary searches if the range of values
is nasty enough? That's so cool. Apart from a few places in TH02,
this is the only place in PC-98 Touhou to show off that Turbo C++
optimization.
That code's still unexpectedly janky for what you'd expect from the 4th
game in the series, though.
Part of P0150, funded by Blue Bolt.
motion_t is also used for certain animations in MAINE.EXE, so not all
instances refer to entities in playfield space. Explicitly specifying
the latter now allows us to gain…
Part of P0149, funded by Blue Bolt, Ember2528, and -Tom-.
Yup, P0148 didn't actually solve the issue it was meant to solve, and
I still had to research this workaround.
Part of P0149, funded by Blue Bolt, Ember2528, and -Tom-.
Turns out that this is one of the effects of the -WX option ("Create
DPMI application")… along with generally messing up code generation.
Nothing we can't work around though, luckily! Finally getting to cross
that off the list of reasons that prevent decompilation.
Part of P0137, funded by [Anonymous].
Reasons:
• piano_fm_part_put_raw(): SI register referenced and not saved on
the stack
• piano_current_note_from(): Would be decompilable… into a mess.
Not worth adding a separate translation unit just for it.
• piano_part_keys_put_raw(): DI register saved before the SI register
• piano_pressed_key_put(): DI register referenced and not immediately
saved on the stack
• piano_label_put_raw(): SI and DI registered referenced and not saved
on the stack
• grcg_setcolor_direct_seg1_raw(): Let's procrastinate this one until
we have to reference all of these instances in C land.
And we could have even emitted that PIANO_KEY_PRESSED_TOP pixel data
into the code segment, by using `#pragma option -z` to give identical
names to both the code and the data segment. At least we can decompile
the first two functions here.
Part of P0135, funded by [Anonymous].
Reason: Wants to be word-aligned, and the previous version in OP.EXE,
game_exit(), is not, despite having an even length :(
Oh well, at least I'm confident enough about it by now to document it.
And out of all decompilations to be thrown away, this is a pretty
dispensable one.
Part of P0133, funded by [Anonymous].
Turns out the inlining behavior of `const` variables at global scope
that we've been relying on lately is actually exclusive to C++ mode…
once again!
Part of P0133, funded by [Anonymous].
Containing not one, but two decompilation innovations, one of which
works around a compiler bug using C++ template functions…
Completes P0126, 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.
A function which does so many individual things that I can't even
summarize it in a comment without spelling out each line of code. And
then, this entire clamped movement system is only used for Kikuri's
soul sprites. The usage code for every other entity just parties on
the [cur_left] and [cur_top] members, and passes a delta of (0, 0) to
this function. 🤷
Part of P0108, funded by Yanga.
Yes, functions! Those would have been nice earlier!
Also documented another overly specific Borland C++ code generation
quirk with regard to assigning expression results to elements of 16-bit
arrays…
Part of P0107, funded by Yanga.
Note how Turbo C++ auto-generates that call to `operator new`, which
you don't see in the decompilation anymore. So yeah, as soon as you add
a constructor, Turbo C++ enforces heap allocation for any instance of
that class, even function-local ones that would otherwise be
stack-allocated.
That's where the bad reputation of C++ comes from, I guess?
Part of P0102, funded by Yanga.
"Physics". Not only did ZUN restrict the X velocity to the 5 discrete
states of -8, -4, 0, 4, and 8 (because hey, unaligned blitting is slow
anyway?), but gravity is also only applied every 5 frames.
We're still missing quite a bit of usage code, but these are the core
functions. One of which turned out to be undecompilable, due to… a
rigorously defined instruction order when performing arithmetic between
`double`s and `float`s?! Still, spelling out all this stuff in ASM
seems much better than somehow splitting the data segment, just so that
we can immediately use literals there.
Part of P0097, funded by Ember2528.
With ternary operator expressions straight out of Jigoku.
(TL note: Jigoku means hell.)
Nice to see that Turbo C++ apparently has no nesting limit on function
call inlining in general, though!
Part of P0092, funded by Yanga.
Of which we can express precisely *nothing* as an inline function,
because Turbo C++ always emits a useless `JMP SHORT $+2` at the end of
such an inlined function if it contains nested `if` statements. This is
also what forced some of the functions in 90252cc to be expressed as
macros. By now, this is clear enough to be documented separately.
And to warrant this separate commit.
Completes P0090, funded by Yanga.
And of course, TH05 ruins the consistency once again. Sure, the added
file error handling is nice, but we also have changes in the playful
messages (lol), and now need a third distinct optimization barrier
(🤦)… But as it turns out, inlined calls to empty functions work as
well. They also seem closer to what ZUN might have actually written
there, given that their function body could have been removed by the
preprocessor, similar to the logging functions in the Windows Touhou
games. (With the difference that the latter infamously *aren't*
inlined…)
Part of P0077, funded by Splashman and -Tom-.
4½ years after aa56a7c, it turns out that the correct decompilation
involves… no-ops generated by assigning variables that just happen to
be in registers to themselves?! Which does get optimized out, but only
after TCC folded identical tail code in all branches of a function,
thus effectively functioning as an optimization barrier.
The initial attempt used register pseudovariables, but this definitely
is the best possible way this could work – portable, and doesn't
unnecessarily shred the code into tiny inlined functions pieces. The
mindblowing thing here is that ZUN could have actually written this to
have additional, albeit unnecessary, lines to place breakpoints on. But
that means he must have chosen those two local variables in SI and DI
completely by chance… 🤯
The best thing though? ~#pragma inline is gone~
Part of P0076, funded by [Anonymous] and -Tom-.
Something small that came out of the resident structure review.
Including more research to suggest that we probably can't ever use C++
constructors for anything in ReC98.
Part of P0076, funded by [Anonymous] and -Tom-.
Much better than the previous incorrect comment, since the char_id()
method now easily generates the correct sequence of conversion
instructions, seen all throughout the ASM. Even within array
subscripts!
Part of P0076, funded by [Anonymous] and -Tom-.
TH01's (original) version also replicates the PC-98 text RAM's reverse
and underline attributes. Which was removed in later games,
interestingly and inconsistently enough.
Part of P0068, funded by Yanga.
Semi-unused, that is, the one use of this function doesn't actually
move the rectangle to a different position. Ironically, the non-moving
back-to-front function immediately above *is* unused…
Also, too bad that stack order is the only reason we can't use structs
to combine all plane variables into a single object.
Part of P0067, funded by Splashman.
Which store colors as GRB, as suggested by the structure's ID string.
Even master.lib's own functions add an additional XCHG AH, AL
instruction to get colors into and out of this format. MASTER.MAN
suggests that it's some sort of standard on PC-98. It does match the
order of ths hardware's palette register ports, after all.
(0AAh = green, 0ACh = red, 0AEh = blue)
Now we also know why __seg* wasn't used more commonly, as lamented in
c8e8e98. Turbo C++ simply doesn't support a lot of arithmetic on
segment pointers.
And then that undecompilable far call to a function within the same
segment, but inside a different translation unit…
Also, thanks again to Egor for the SCOPY@ hack that debuted in 0460072.
Would have probably struggled with this a lot more without that.
And *then* you realize that TH01 effectively doesn't even use the
resident palette. 😐
And yes, we're procrastinating the whole issue of potentially using
a single translation unit for all three binaries by using a common
segment name, because it *really* isn't that easy.
Completes P0066, funded by Keyblade Wiedling Neko and Splashman.
Meh, can't overload arithmetic operators that take a Subpixel without
generating a needless load and store, even with -Z. But heck, slightly
uglifying subpixel/subpixel arithmetic is exactly the right trade-off.
Completes P0061, funded by Touhou Patch Center.
Ooh, shot position being determined by RNG at lower shot levels? That's
some RNG manipulation TAS potential right there! Maybe.
Part of P0037, funded by zorg.
That should make this convoluted copypasta a bit easier to read. And
sure, I could have done something about the loop as well, but
SHOT_FUNC_INIT already hides enough control flow behind a macro…
Part of P0037, funded by zorg.
A TH05 innovation that actually makes the game code easier to read?!
Although it was quite hard to actually reverse-engineer it, with the
confusing flag ordering pointing to some deeper meaning behind the
flags, which really doesn't exist.
Completes P0036, funded by zorg.
And once again, the TH05 version is un-decompilable. :/ It was pretty
close this time, though, as the entire block between PUSH DI and POP DI
kind of resembles a separate inlined function, in accordance with Turbo
C++'s automatic backup of the DI register, as researched in 7f971a0.
Except that it contains a loop, and Turbo C++ refuses to inline any
function with `do`, `while`, `for`, or `goto`. If it didn't, it would
have totally worked.
Also, yes, C++ class methods are treated identically in this regard.
Oh well. Shot type control functions next, finally!
Completes P0035, funded by zorg.
nmlgc