The main effect behind the discoloration seen in the bomb animation,
as well as the exploding squares at the end of Kikuri's and Sariel's
entrance animation.
Single-function segments are lovely, by the way!
Part of P0121, funded by Yanga.
And that's the intended way to play back the hidden DEMO5.REC. Unlock
the Extra Stage with all 4 characters, then hold the left and right
arrow keys in the main menu while waiting the usual demo replay.
For a recording of that replay, see
https://www.youtube.com/watch?v=iP2ywlW2u4U
Completes P0119, funded by [Anonymous] and -Tom-.
The TH04 one might have the same function structure, but the only thing
that's actually identical in both games is the picture darkening loop.
Part of P0119, funded by [Anonymous] and -Tom-.
Shoutout to Egor, who already implemented the necessary wrappers in
2018, which means that I don't have to spend a push on that. 🙂
Part of P0117, funded by [Anonymous].
And with that, we finally dumped every single PC-98 Touhou binary!
Since it'd be overkill to merge bmp2arr into the re-baseline branch
though, we also have to start out with the raw image bytes here.
Part of P0117, funded by [Anonymous].
Needlessly linked with TCC rather than TLINK, adding almost 4 KB of
completely unnecessary libc startup code.
Or maybe not, since ZUN doesn't free the allocated memory himself, but
relies on libc to do that?
Part of P0117, funded by [Anonymous].
On the surface, Version1.02 of the `INTvector set program` seems to
be largely the same as Version1.01, just with fancier instructions,
some redundancy removed, and some slightly different wording in the
playful messages… or is there more to it? Stay tuned!
Part of P0117, funded by [Anonymous].
Yup, it's finally the right time to properly rebuild ZUN.COM. While
all of these small binaries would still need some RE attention, putting
in the few minutes to make them position-independent right now is
definitely worth it. Adding them to the PI calculation on the website
would take much longer 😅
Part of P0117, funded by [Anonymous].
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.
Oh, wait. Due to ridiculously unlucky alignment, we can't actually
approach TH03's OP.EXE from the top of code segment 2… without
covering way too many functions at once, that is.
At least TH02 works out with "just" three functions at once. *If* we
add seg2 back to OP.EXE, where we previously needed to delete it… 😵
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.
Yeah, why *were* we assembling them in the 16-bit part before?!
Possible reasons:
• In a time before Tup, it made no actual difference whether these
little files were assembled in the 32-bit or 16-bit part. Now it sort
of does, since we've temporarily given up on minimal rebuilds in the
16-bit part.
• Emphasizing the temporary nature of the 32-bit part by deliberately
moving everything to the 16-bit part as early as possible?
• It all started with the ZUN.COM ASM code, which doesn't include any
other files, and can therefore be perfectly tracked by a Makefile.
Which *was* superior than the exclusive dumb batch file we had in the
past. And then I've simply cargo-culted all new .ASM translation
units into the 16-bit part well.
Oh, and another positive side effect of temporarily not using 16-bit
TASM: The build process now also runs on Windows 95.
Part of P0113, funded by Lmocinemod.
If the output file already exists, TASM interprets a filename with
extension as a directory, and then concatenates the implicitly
generated output file name to that path… yup.
Part of P0001, funded by GhostPhanom.
Lol, this led the bmp2arr compilation to fail on a clean checkout.
Lesson learned: Always test on a clean clone, not in your separate test
repo that you just `git pull` up to the final commit in a push, but
with all the build artifacts still in there…
Also, yes, `mkdir` only supports backslashes.
Part of P0001, funded by GhostPhanom.
Final unknown entity in TH05 that can collide with the player!
Get position independence hype!
(Also, no structure member comments necessary, thanks to the new
types!)
Part of P0111, funded by [Anonymous] and Blue Bolt.
With all the memmove()-style shifting of individual lines, there's
probably a point to reserving 20 lines per set, but only ever rendering
4 of them. We'll see once I get to decompile all of these functions.
Part of P0110, funded by [Anonymous] and Blue Bolt.
Wow, so the boss_stuff_t structure did exist in the original code after
all. This is the only function in all of TH04 and TH05 that confirms
it – in dea40ad, it just seemed like something I made up, out of
convenience.
Completes P0109, funded by [Anonymous] and Blue Bolt.
If C allowed labels of other functions as `goto` targets, this *might*
have been decompilable into something useful to modders. But like this,
there's no point in even trying.
Yeah, you *really* don't want to base your fangame mod on TH05.
Part of P0109, funded by [Anonymous] and Blue Bolt.
Found a uth05win inaccuracy! Once the Y coordinate gets close enough to
the target point, it actually speeds up twice as much as the X
coordinate would. This might make uth05win a couple of frames slower in
all boss fights from Stage 3 on.
And yeah, got too used to decompilation to go back to splitting off
RE'd functions in ASM land 😛
Part of P0109, funded by [Anonymous] and Blue Bolt.
Leading to slight complications in TH02's Music Room and shot type
selection menus. Thought about leaving those in C for a while, but I
still think it's worth it for the consistency we get with the VRAM
offset functions. Also, we'll have similar code for the main menus of
later games, and I'll surely won't be using C++ when starting out with
these.
Part of P0105, funded by Yanga.
"Hey, let's have separate functions for uint16_t and int16_t… and then
just *not* support negative numbers in the latter" :zunpet:
Part of P0104, funded by Ember2528.
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.
And immediately, we discover another two hardcoded sprites, with, of
course, another set of functions for blitting and unblitting them…
Part of P0099, funded by Ember2528.
"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.
So even TH01 wasn't 100% C++ after all. Turns out that this function
was the only instance in all of REIIDEN.EXE where ReC98 previously had
different encodings for identical x86 instructions.
Part of P0096, funded by Ember2528.
Surprise, it's the (terribly suboptimal) setgsta() example function
from the PC-9801 Programmers' Bible! 100% identical, so ZUN must have
read that book as well.
Used for screen shaking effects, as well as the scrolling backgrounds
at the start of the Final Boss stages.
Completes P0095, funded by Yanga.
Yes, TH01's memory info screen will recurse into itself for every 3
frames the PgUp key is held, requiring one additional PgDown press per
recursion to actually get out of it.
You can, of course, also crash the system via a stack overflow this
way, if that's your thing.
Part of P0091, funded by Ember2528.
That's… pretty specific. The only thing on the main menu with this
color is the "1996 ZUN" text at the bottom… probably part of an
effect that we never got to see. Every other idea would be baseless
speculation, given that the snapped buffer isn't used anywhere else.
Part of P0090, funded by Yanga.
Otherwise, TASM would simply convert all EXTRN declarations in those
files to uppercase. Then, the linker would expect them in uppercase,
forcing both the case-sensitive big 32-bit .ASM files *and* the entire
C land to declare them as uppercase as well.
For functions with __pascal convention which are always uppercased
anyway, this makes no difference. It does matter for regular __cdecl
variables, though, and the C declaration of [score_delta] in e6294c2
already showed that we'd then be forced to use macros if we wanted to
pretend that these names still had lowercase characters.
Doing this for every variable referenced in both C land and 16-bit ASM
land gets annoying quickly. So, no need to force this inconsistency if
we can get rid of it by slightly uglifying ASM land.
Part of P0089, funded by [Anonymous] and Blue Bolt.
Again, 11 necessary workarounds, vs. forcing byte aligment in at least
18 places, and that number would have significantly grown in the
future.
Part of P0085, funded by -Tom-.
5 enums where code generation wants an `int`, vs. 11 cases where using
the minimum size is exactly the right default. So it's way more
idiomatic to force those 5 to 16 bits via a dummy element… except that
we can't give it a single, consistent name, because you can't redeclare
the same element in a different enum later.
Oh well, let's have this ugly naming convention instead, which makes it
totally clear that the force element not, in fact, a valid value of
that enum.
Part of P0085, funded by -Tom-.
nmlgc