It has a hidden dependency on TH04's scroll functions, and TH02 seems
to use screen coordinates throughout.
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.
Much more than usual, now that we've got a snappy build system! This
commit covers
• All .PI functions across all games
• TH02's High Score entry functions
• TH03's shots_update() and shots_render()
• All functions declared in `th04/op/op.hpp`
• TH04/TH05's bb_txt_put_8_raw(), bullet_template_clip(),
player_pos_update_and_clamp(), score_update_and_render(), and
slowdown_frame_delay()
• TH05's reimu_stars_update_and_render(), score_delta_commit(),
stage2_invalidate(), stage2_update(), and space_window_set()
Part of P0284, funded by [Anonymous] and Blue Bolt.
Borland's C preprocessor does not track enum values, so this check
always failed when running the code through just `CPP.EXE`.
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.
MS-DOS Player translates long names to the 8.3 format via
GetShortPathNameA(), but it fundamentally can't do Unicode.
Part of P0284, funded by [Anonymous] and Blue Bolt.
Especially helpful on Linux where there's the Linux-native `PATH`, the
completely unrelated `PATH` inside Wine, and `WINEPATH` to prefill the
latter from the former.
Part of P0284, funded by [Anonymous] and Blue Bolt.
Creates at least somewhat of a better diff than if we had renamed the
batch file two commits ago.
Now that we invoke TLINK ourselves, the `tlink.exe` error can no longer
appear. Since it did take a few hours to RE this back in 624e0cb, I've
preserved the section at a more dedicated place, at
https://gist.github.com/nmlgc/6229345c74d1a7d3c6c1b3e988beb0e9
It will also be spelled out in the blog post of this delivery.
Completes P0004, funded by GhostPhanom.
I considered disabling it by default and only enabling it through an
optional `CONFIG_RESEARCH` variable, but that turned out to be too
annoying and inconsistent when `build_dumb.bat` generation came into
play.
Part of P0004, funded by GhostPhanom.
Compiling as many source files as possible within a single TCC process
is the single most important build time optimization we can do. Sadly,
it won't work with Tup's parallel nature, but it can really shine in a
dumb batch build. This is the reason why Windows 9x can compile this
entire codebase on a single core in half the time it takes MS-DOS
Player to do the same on 64-bit Windows, on the same hardware.
That weird double-spacing, however, is the most ridiculous workaround
for a bug I have seen in a long while…
Completes P0282, funded by [Anonymous].
`tup generate` does this as well, but only emits the `mkdir` calls for
the directories that are missing in the current working tree, requiring
a clean checkout to actually emit all necessary ones. This is much more
convenient.
Part of P0282, funded by [Anonymous].
Yup, a 64-bit build. 32-bit Tup won't make sense going forward because
it can neither inject into a 64-bit MS-DOS Player nor into 16-bit DOS
build tools.
Completes P0003, funded by GhostPhanom.
A perfect `tup refactor`, already featuring most of the structure we're
going to use for the merged 32-bit and 16-bit build.
Also, inlining all the BCC32 stuff because we're no longer going to use
this compiler anyway.
Part of P0003, funded by GhostPhanom.
Single backslashes are still preserved as such in the `tup generate`d
batch file, and we don't need two there. This allows us to cleanly
refactor these commands into the new Lua code.
Completes P0002, funded by GhostPhanom.
Finally, a clean `bin/` tree. 😌
And as for the additional complexities in the Makefile, well, we're
about to get rid of that one anyway. 🚮
Part of P0002, funded by GhostPhanom.
The ones we use in `Research/` and for the Anniversary Edition. Better
code generation at the cost of having to explicitly declare `main` as
`__cdecl` so that the linker can find it.
Part of P0002, funded by GhostPhanom.
These are just as much of a part of the PC-98 Touhou build pipeline as
the sprite compiler. The future Tupfile will use the tupblocks concept
of treating the build configuration as a branching tree, so we'd like
everything under `Pipeline/` to share a single set of configuration
flags.
Part of P0002, funded by GhostPhanom.
Finally removing that one inconsistency that dates back to 1f1847d.
Now, every file in the `th0?/` subdirectory is meant to be assembled
with `/dGAME=?`.
Part of P0002, funded by GhostPhanom.
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.
The string literal placement issue mentioned in 942373e doesn't seem to
be an actual problem (anymore). This is also much simpler, as we get to
save tons of `extern` declarations at the cost of one additional
`#pragma option`.
Part of P0002, funded by GhostPhanom.
Unfortunate, but we won't be able to reuse the same .OBJ file once we
compile all pipeline tools with the `pascal` calling convention.
Separately compiling `th01/formats/img_data.cpp` would also turn into a
mess with the upcoming `#include` cleanup:
• `img_data.cpp` requires `ptn.hpp`,
• which will require `egc.h`,
• which requires `defconv.h`,
• which requires `GAME` to be defined,
• which makes no sense for pipeline tools.
Part of P0002, funded by GhostPhanom.
Windows 9x requires CRLF for batch files to work at all. While Windows
XP and later appear to work with LF line endings, they introduce
devious glitches with certain commands:
https://www.dostips.com/forum/viewtopic.php?t=8988
However, we still want to use LF endings in the repo to prevent the
annoying ^M whitespace errors.
Part of P0002, funded by GhostPhanom.
nmlgc