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].
Moving the code from TH01 to a new platform layer, and deciding against
the `pc98_` prefix, which is sort of implied by the directory of the
header file it came from. Namespaces would be ideal, but Turbo C++ 4.0J
sadly doesn't support them.
Part of P0232, funded by [Anonymous].
We'd like to use this optimization in the platform layer as well.
Turning it into an inline function via __emit__() also allows us to
turn a bunch of other macros into proper inline functions.
Part of P0232, funded by [Anonymous].
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.
Allows us to use them as switch cases in the `debloated` branch, in
exchange for turning some inline functions to macros.
Part of P0229, funded by Ember2528.
This variable makes more sense if we name it after its one actual and
consistent usage. All others make more sense when interpreted as a bug
or bloat.
Part of P0229, funded by Ember2528.
Same rationale here – this naming scheme clarifies how these variables
are just redundant copies out of the resident structure.
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.
In all places visited during the next 6 pushes: The resident structure
and copies of its values, the packfile implementation, boss entities,
rendering font ROM glyphs to VRAM, and overall inconsistent code
between the three binaries.
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.
Started out with the usual amount of decompilation workarounds for this
low-level laser code, but ended up requiring one on almost every line
just because ZUN reversed the function prolog… 🙄
Part of P0228, funded by [Anonymous] and nrook.
It's easy to blame ASM micro-optimizations for bugs like these, but the
original C++ version from TH01 was equally bugged for FX_WEIGHT_BLACK.
Part of P0225, funded by Enderwolf, Blue Bolt, 32th System, and Yanga.
Even that part's the same in these three games… except for the 27 small
places where it isn't, 7 of which are purely coding style cosmetics.
Completes P0224, funded by Splashman and -Tom-.
The later games need this constant for their buffers as well, and it's
not just needed for loading sound files. Might be overkill to force all
of `master.hpp` to be #included in some additional places, but the
alternative would have been to move it to a `fn_len.hpp` file.
Ultimately, this constant *is* related to master.lib.
Part of P0223, funded by Blue Bolt and rosenrose.