In most cases, this discovery will mean that we have to bite the bullet
and remove `const` from pointer parameters if the generated ASM
wouldn't match otherwise. That by itself doesn't really simplify the
code, but at least we get to remove a single bloated `reinterpret_cast`
from one function call already.
Part of P0278, funded by Yanga.
A year ago, I would have considered this undecompilable. Turns out that
this function really benefitted from a decompilation against all odds,
especially with these 4 different views on the same 8 local variables.
Part of P0228, funded by [Anonymous] and nrook.
Biggest decompilation breakthrough of the year already? Completely
removes the need for the "set near pointer to far function" hack, and
solves quite a few upcoming issues.
The TASM manuals did have a few pages on the topic of segments and
groups, but there's absolutely nothing about it in the TCC ones beyond
the three-sentence description of `#pragma codeseg` and that completely
unhelpful "🤷" of an explanation for the `Fixup overflow` error…
Part of P0227, funded by nrook.
Nooooo, the static initialization code proves that `boss_entities`
couldn't have been an array in ZUN's code! 😢 Which in turn explains
why YuugenMagan's and Elis' code looks the way it does. We could go
into undefined behavior territory and just cast `boss_entity_0` to a
pointer, but let's better not annoy future port authors just for my
personal convenience. In turn, we need to get a bit clever with some of
Elis' code to replace the now wholly redundant `elis_entity_t` type,
but it's not all too bad.
Part of P0207, funded by GhostPhanom.
In which ZUN needs a hack to make columns of vertical bumper bars work
at all with the way the Orb's X velocity is implemented… and may have
just deliberately ensured that the Orb can definitely loop infinitely
between two bumpers.
(Those two wrong NOPCALLs aren't worth working around. It would
basically require taking apart the entire function, and they'll be gone
by the next two commits anyway.)
Part of P0203, funded by [Anonymous] and GhostRiderCog.
Noooo, SinGyoku will in fact prove the existence of this getter method
via the given code generation detail. Might as well go fully consistent
then and exclusively use the methods, ending the previous party time.
Part of P0201, funded by Ember2528 and Yanga.
And move it under the C++ chapter, as both top-level `inline` and
(obviously) class methods are only supported in C++ mode.
Part of P0201, funded by Ember2528 and Yanga.
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.
nmlgc