OK, this is the big one. We still keep using `#include` guards only
where we absolutely need to, but with each header now being valid in
isolation, this can now actually help *minimize* the length of each
translation unit's `#include` list. Turns out that after removing all
the duplicates, we only *actually* need to guard 29 headers across all
5 games.
Part of P0285, funded by [Anonymous] and iruleatgames.
With the upcoming `#include` cleanup, it finally makes sense to split
off all graphics-related code into its own header. In turn, it makes
more sense to store all of these future master.lib headers in, well,
the master.lib directory, which provides a new 8 characters for their
file names. Turns out that the rationale I gave for the root directory
placement in 8266bbd didn't hold up 3½ years later…
(Also, the `pc98.h` declarations will eventually be split into
`game/coords.hpp` and something in `platform/x86real/pc98/`.)
Part of P0284, funded by [Anonymous] and Blue Bolt.
The translation units were probably a better place back when most of
the codebase was still compiled in C mode, we only had a few C++ TUs,
almost everything needed to be declared as `extern "C"`, and moving
these declarations into the headers would have been really noisy with
all the `#ifdef __cplusplus` / `#endif` required. Nowadays though,
we've greatly reduced that surface area. And given that headers will
include even more headers as part of the upcoming `#include` cleanup,
it makes sense to make the jump now.
Part of P0284, funded by [Anonymous] and Blue Bolt.
I might change this convention again in the future, particularly once
someone wants to fund C89 conformance, but let's stay consistent for
now.
Part of P0264, funded by [Anonymous] and Blue Bolt.
This commit covers
• TH02's ZUNINIT errors,
• TH02's main menu,
• the init/exit functions in all 4 remaining games,
• TH03/TH04/TH05's configuration file functions, and
• TH04/TH05's tile rendering functions.
Part of P0258, funded by [Anonymous] and Blue Bolt.
• 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.
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].
And no longer force translation units that access the resident
structure into #including that mistake that was ReC98.h.
Part of P0124, funded by [Anonymous] and Blue Bolt.
The supposedly low-hanging fruit that almost every outside contributor
wanted to grab a lot earlier, but (of course) always just for a single
game… Comprehensively covering all of them has only started to make
sense recently 😛
Also, yes, the variable with the uppercase .CFG filename has itself a
lowercase name and vice versa…
Part of P0077, funded by Splashman 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-.
nmlgc