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.
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.
By now, it has become clear that this the norm rather than the
exception among these units. Thankfully!
Part of P0245, funded by [Anonymous], Blue Bolt, Ember2528, and Yanga.
If the macro itself is local to a function, these can work in certain
scenarios, but never for global ones.
Part of P0186, funded by [Anonymous] and Blue Bolt.
This gets rid of a couple of per-entity sprite bitplane types, makes
sprite declarations easier to read by putting width and height next to
each other… and points out a number of array dimension mistakes -.-
Even in places where we can't use it.
Part of P0138, funded by [Anonymous] and Blue Bolt.
Might look uglier, but has the advantage of not generating an empty
segment with the default name… *and* the default padding, which will
really come in handy with the following breakthrough.
Part of P0137, 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].
It's not necessary for assigning `__seg` pointers to `far` ones, which
might even remove the <dos.h> dependency in some translation units.
Part of P0134, funded by [Anonymous].
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.
Whew, time to look at every `int` variable we ever declared! The best
moment to do this would have been a year ago, but well, better late
than never. No need to communicate that in comments anymore.
These shouldn't be used for widths, heights, or sprite-space
coordinates. Maybe we'll cover that another time, this commit is
already large enough.
Part of P0111, funded by [Anonymous] and Blue Bolt.
nmlgc