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.
These declarations (and the associated `planar.h` dependency) are
needed by a lot fewer translation units than the rest of `ptn.hpp`.
Part of P0284, funded by [Anonymous] and Blue Bolt.
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.
egc_setrop() delivers nothing of value, just obscures the single thing
it does, and disrupts the visual flow of the code.
egc_selectpat() isn't much better, is used a total of two times, says
almost nothing from its name alone, and MASTER.MAN's documentation adds
so little of value that you'd want to consult hardware documentation
anyway once you try to understand it.
Not to mention that both add a dependency on master.hpp for what are
actually PC-98 hardware constants.
Part of P0284, funded by [Anonymous] and Blue Bolt.
The upcoming `#include` cleanup is going to spell out all implicit
dependencies of every header file. This would
• `#include "master.hpp"` in every header that uses `PF_FN_LEN`, and
• `#include "pc98.h"` in `master.hpp`, adding lots of graphics
declarations to translation units that don't need them.
Moving `PF_FN_LEN` to its own file not only avoids needless inclusions
of `master.hpp` and all of its future dependencies later, but already
removes `master.hpp` from 6 translation units – not to mention that we
no longer need to preprocessor-guard some of the usages of `PF_FN_LEN`.
Part of P0284, funded by [Anonymous] and Blue Bolt.
`irand()` and `rand()` are only identical on Borland compilers. The
specific RNG implementation is an integral part of the original game
logic, so we actually never want to use the generic libc `rand()`. Any
future replays recorded on PC-98 builds should play back identically on
whatever system we port the games to, after all.
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.
Everything related to the definition concept should be in one place.
The resident structure is merely where it's all stored, and the
`debloated` branch will get rid of that structure eventually.
Part of P0284, funded by [Anonymous] and Blue Bolt.
Not only would the `(GAME != 2)` need to include TH03 in the future,
but this `#undef` trickery will blow up once we start reorganizing the
`#include`s in the next few commits.
Sadly, a few source files use master.lib's grcg_off() function in one
game and the macro in the other, which makes it infeasible to assign a
distinct name for every function.
Part of P0284, funded by [Anonymous] and Blue Bolt.
Turns out that all of the previous inconsistencies in the Makefile are
covered by just 8 additional `#pragma`s in the code. Most of those
applied to code that already needed way more flags than the Makefile
bothered to address, such as the extremely silly `-O-`.
Part of P0002, funded by GhostPhanom.
In most cases, this discovery will mean that we have to bite the bullet
and remove `const` from pointer parameters if the generated ASM
wouldn't match otherwise. That by itself doesn't really simplify the
code, but at least we get to remove a single bloated `reinterpret_cast`
from one function call already.
Part of P0278, funded by Yanga.
Needed for a constness overloading hack later. A certain single place
in TH02 will need the `str` parameter to not be `const` for code
generation reasons, but we don't want to force every call site into
passing non-`const` pointers for such a silly reason.
Part of P0278, funded by Yanga.
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.
`RANK_DEFAULT` raised the question why ZUN just didn't directly assign
the apparent default of `RANK_NORMAL`. Turns out that this is what
triggers the first-launch setup menu.
Part of P0262, funded by [Anonymous] and Blue Bolt.
I could have equally argued the opposite way, and in favor of `sgm` and
`ofs`, but I've also been using `seg` and `off` more prevalently
throughout the years.
Part of P0245, funded by [Anonymous], Blue Bolt, Ember2528, and Yanga.
And explicitly define observability in terms of an infinitely fast
PC-98. That's the only reasonable assumption to make when considering
ports to faster architectures that aren't bottlenecked by disappointing
blitter chips.
Part of P0239, funded by Ember2528.
The exact reason why pellets can be carried over from Sariel's first
form to her second… and why you probably shouldn't carelessly use that
redundant count of alive pellets to skip loops in the Anniversary
Edition, because that count will be incorrect after a reset.
Thanks to mu021 for reporting this issue!
Yup, unaligned! The prefilling case is quite broken on T98-Next, but
given that this emulator hasn't seen any development since 2010 and
every other emulator gets it right, we can reasonably assume that to be
a bug in that emulator.
Completes P0232, funded by [Anonymous].
nmlgc