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.
And dissolve the "vars" units, which would be too annoying to merge on
the `debloated` branch otherwise. This interpretation of these globals
further highlights the type differences between REIIDEN.EXE and
FUUIN.EXE.
Placing them in directly in `resident.hpp`; on the `debloated` branch,
we could neatly define each of these fields in a matching .cpp file,
but that file would need to be compiled twice due to the aforementioned
differences between binaries. Better to keep those in `op_01.cpp`,
`main_01.cpp`, or `fuuin_01.cpp`, respectively.
Part of P0229, funded by Ember2528.
The `credit_` prefix may seem redundant within the REIIDEN.CFG
structure, but consistency seems more important here. Makes it much
easier to follow how these fields are copied around.
Part of P0229, funded by Ember2528.
Neatly dissolves two of the three game-specific preprocessor branches
in `th01/hardware/grppsafx.h`. Moving at least one function into a
corresponding .cpp file will also simplify the corresponding debloating
commit on the respective branch.
Part of P0229, funded by Ember2528.
No frame delay after its blitting call, immediately overwritten on the
next iteration… but if EGC "acceleration" leads to 8000 VRAM page
switches, you don't need additional delay for parts of the image to
remain visible after all.
Part of P0200, funded by Yanga.
You can definitely make an argument that these if/else if branches are
easier to read than their implied formula, especially with all
variables being signed here.
Completes P0197, funded by Yanga and Ember2528.
nmlgc