• Comments that describe all lines of code until a blank one are placed
into the lines immediately above
• Comments that describe an entire demarcated block are placed
immediately below the dash row at the top
• In any case, there should be a blank line after the top comment of
a demarcated block, to keep IntelliSense-style systems from applying
the block comment to the first actual line of code…
• …but there shouldn't be one before the dash row at the bottom, where
it'd be redundant.
Part of P0207, funded by GhostPhanom.
Palette hacks not included yet. Yup, that's how all phases can use
hardware color #0 as their background color.
Completes P0147, funded by -Tom- and Ember2528.
Sure, we can't use them everywhere, but it's really nice to get rid of
that casting madness – and any explicit references to x86 memory
segmentation – wherever we can.
Part of P0138, funded by [Anonymous] and Blue Bolt.
A decompilation of ZUN-written ASM that was almost worth it, for once!
Too bad that those aren't the <string.h> intrinsics that the
Wolfenstein 3D disassembly hinted at, though.
Part of P0135, funded by [Anonymous].
> assigning to the DI register immediately before a CALL
Yeah, no amount of comma operator trickery can get *that* out of this
compiler. Also, these TH05 .PI functions are the only place in PC-98
Touhou with a `IMUL DI, imm8` instruction, which is impossible to get
out of Turbo C++'s built-in assembler.
Well, at least the `if` branches decompile somewhat nicely.
Part of P0134, funded by [Anonymous].
DOS is not the same thing as the underlying CPU, after all. A separate
file not only indicates to future port authors which parts of the code
are x86-specific, but it also speeds up build times…
… in theory, because removing 677 lines from 49 files each doesn't seem
to speed up the build as much as I had hoped? But apparently my whole
system mysteriously got faster in the meantime, and I was getting 22-23
seconds for the entire repo even before this commit. Good enough.
Part of P0134, funded by [Anonymous].
Getting us completely macro-free there… even though it did require a
separate version of those functions if the ID is a pointer.
Part of P0134, funded by [Anonymous].
My repo will never include all of master.lib anyway, as explained in
https://rec98.nmlgc.net/blog/2020-11-03.
That gets me a median build time of 27 seconds for the entirety of
ReC98 on my system, just as estimated in that same blog post. And we're
far from done with #include optimizations…
Part of P0133, funded by [Anonymous].
This might have almost been the case that justified making master.hpp
compatible with C translation units… but even this one would like to
use the template functions from th01/math/vector.hpp.
Part of P0133, funded by [Anonymous].
With a type-safe wrapper template that removes the need for ID length
and structure-size-in-paragraphs macros. *And* <dos.h>!
Part of P0126, funded by [Anonymous] and Blue Bolt.
6149 LoC with the original master.h, vs. 2524 LoC *and* additional
semantic sugar with master.hpp. Nice!
(Yes, *semantic* sugar.)
Part of P0124, funded by [Anonymous] and Blue Bolt.
Since we can't even change whitespace inside a preprocessor macro
without getting a `redefinition is not identical` warning, these have
to be wrapped in `#if !defined(__MASTER_H)` blocks for now.
Part of P0124, funded by [Anonymous] and Blue Bolt.
The regular master.h is big, uncomfortable in C++ mode, and bloated
with all those portability `#define`s that effectively only cover a
small portion of the PC-98-specific code anyway. So, let's gradually
transition to a new smaller header that is more integrated into the
ReC98 codebase, by simply no longer #including `master.h` in new code.
Which also explains its weird place in the root directory. Even though
`libs/master.lib/` contains plenty of game-specific modifications, it
didn't feel right to have anything in this directory refer to types
from `pc98.h`.
Part of P0124, funded by [Anonymous] and Blue Bolt.
nmlgc