I didn't know that extra staff roll cutscene order is different for
each character --WindowsTiger
Final actual data references in TH05's MAINE.EXE! 🎉 --Nmlgc
Reviewed and merged as part of P0118, funded by -Tom- and Ember2528.
Mainly elaborating a bit on choosing different compilers instead of
Borland C++ 5.5, and fixing a common issue with it. Also removing the
16-bit TASM section for the time being, if it's not required.
Part of P0118, funded by -Tom- and Ember2528.
… with either the port or the argument in registers. This is one of the
few actually dumb concessions to the PI counter on the website.
Then again, binary *is* a better representation for the contents of the
GRCG tile register than hex…
Part of P0117, funded by [Anonymous].
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].
Not really PC-98-hardware-related, not really master.lib-related, so
yeah, that's really the best place for it.
Part of P0116, funded by [Anonymous] and Lmocinemod.
28,160 bytes of global data just for a overly large 320×704 bitmap
that allows you to scroll between the general verdict and the
individual end-of-stage scores with the Up and Down keys. That's one
benefit of splitting your game into multiple executables, I guess?
Completes P0115, funded by Lmocinemod and Blue Bolt.
Subpixels with 32-bit X and Y components?! That's new.
And yeah, they still just use 4 bits for the fractional part.
Also, let's try something revolutionary for these declarations that are
only used in a single .ASM dump file, and put them all straight before
the first function they are used in. Then we certainly don't forget to
delete them once we're done decompiling that stuff 🙃
Part of P0115, funded by Lmocinemod 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.
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.
Wow, this is the first time we're about to call any of these from C
land in ≥TH03? Found no built-in way to just uppercase an identifier
in TASM, so apparently we have to spell out the names in both lower-
and uppercase.
So, let's go back to regular, non-macro PUBLIC / PROC / ENDP code
wherever we can – for all functions introduced in ≥TH03, and for
everything that takes no parameters. It's simply not worth the
trouble.
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.