Windows 9x requires CRLF for batch files to work at all. While Windows
XP and later appear to work with LF line endings, they introduce
devious glitches with certain commands:
https://www.dostips.com/forum/viewtopic.php?t=8988
However, we still want to use LF endings in the repo to prevent the
annoying ^M whitespace errors.
Part of P0002, funded by GhostPhanom.
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.
Wow, that was unexpectedly painless – even for TH03 where we have to
deal with a significant number of un-RE'd pieces of data. And for TH04
and TH05, it turns out that we not only *want* to move the entire _TEXT
segment into the new unit to keep the amount of `extern` declarations
to a minimum, but in fact *have* to because of graph_putsa_fx()'s fancy
labels in the data segment.
Part of P0263, funded by [Anonymous].
Running this on various PC-98 models confirms that unchecked blitting
(i.e., what you would intuitively consider to be the best method) is in
fact faster than checking either byte of a 16-pixel-wide sprite
beforehand, and has been throughout the PC-98's lifespan. For optimal
performance on the 286 and 386, we might want to use MOVS instead of
MOV, but even that difference is way too small to truly matter.
Also, nice to see turns out that our blitter outperforms a naive pure C
implementation by 2-4×, depending on the model. And master.lib is not
*that* much faster…
The gaiji in `Research/blitperf.bmp` were taken from the Unifont
version 15.0.01 glyphs for:
• U+2022 BULLET •
• U+23F1 STOPWATCH ⏱
• U+1F40C SNAIL 🐌
Part of P0233, funded by [Anonymous].
Yeah, no, I'm not going to declare all of those as `extern` and then
"Move all data to C land" after decompiling the entire segment. Once
again (94372d2), it's not too bad – heck, in REIIDEN.EXE, it's less
than a screen worth of identifiers that are still being referenced.
Part of P0214, funded by Ember2528.
That's all hardcoded sprites transferred to C land! Yeah, I know,
what a significant milestone… except…
Part of P0213, funded by Ember2528 and GhostRiderCog.
This one will use the DotRect template from `planar.h` and generate a
single 16- or 32-dot value per row. Since this converter has a goal of
maximum portability, it makes sense to keep raw the multidimensional
C-style arrays around as a possible output format.
Part of P0205, funded by [Anonymous] and Yanga.
Turns out that the "new idea" for handling these data slices won't work
out in reality. At least the amount of necessary manual `extern`
declarations isn't soul-crushingly large, so this way isn't bad either,
after all!
Part of P0197, funded by Yanga and Ember2528.
Reason: Too much micro-optimization using 32-bit registers, which
aren't supported by Turbo C++'s inline assembler. It's also just
another variation on a common function we've decompiled time and time
again.
Part of P0192, funded by [Anonymous], nrook, and -Tom-.
Reason: Saving SI and DI on the stack way too late. Just because ZUN
absolutely *had* to move the clipping condition before these two PUSH
instructions… Was it really necessary to save a total of 4 instructions
for an unlikely worst case in a function that's maybe called like 10-20
times per frame *at worst*?
Part of P0192, funded by [Anonymous], nrook, and -Tom-.
Second PC-98 Touhou boss completely decompiled, 29 to go! But meh,
ZUN's original code did in fact force the three leaf pattern sprites
into separate 1-sprite sheets…
Completes P0181, funded by Ember2528.
The one where Sariel's second form shoots sparks towards the top of the
playfield, which then turn into leaf-like sprites that sway towards the
bottom, killing Reimu on contact.
And wow, what a finish! A weird "decimal subpixel" type, hardcoded
sprites, and effectively unused non-hardcoded sprites. Too bad that it
also ruins the nice `dot_rect_t(w, h)` parameter abstraction for
grcg_put_8x8_mono()…
Completes P0180, funded by Yanga.
I've long moved to a convention of putting every .OBJ compiled from ZUN
code into the subdirectory of the game that introduced it. These four
are the last remaining inconsistencies from earlier in development.
Part of P0162, funded by Ember2528.
Reason: That switch statement. How should we even?
Well, the code *is* fairly good. After looking very deep into it, and
spending 35% of that function on blank lines (for logical grouping) and
explanatory comments, that is…
Part of P0152, funded by -Tom- and [Anonymous].
Boom! Decompilable after all. And look what that made us finally point
out: In all 4 games that use this function, its return value is
undefined if BGM is inactive. (That is, if the user disabled it, or if
no FM sound board is installed.)
Part of P0148, funded by [Anonymous].
Second previously undecompilable translation unit, second creative
workaround for the workaround. We can't compile snd_se_play() with -WX,
as that function needs a stack frame, and it's also illegal to disable
-WX in the middle of a translation unit. But since we only need word
alignment in front of snd_se_reset() *and* that function is identical
in all 4 games, it makes sense to move it to its own translation unit.
And then you notice that the TH02/TH03 and TH04/TH05 versions of the
other two functions are basically identical. The small differences can
easily be moved out to inline functions, leaving us with a single
implementation file for all 4 games. Nice!
Part of P0137, funded by [Anonymous].
Now actually decompilable with the discovery of -WX… even though it
now requires additional workarounds for the drawbacks of the -WX
workaround.
Part of P0137, funded by [Anonymous].
Reason: Self-modifying. -.-
Also, why no GRCG? Would have allowed blitting via REP MOVSD… Might as
well optimize all the way if you're going the ASM route to begin with.
Part of P0136, funded by [Anonymous].
Reason: Self-modifying. -.-
The TH05 version *might* be decompilable into a mess. Don't have time
for that right now, though.
Part of P0136, 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].
nmlgc