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!
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].
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.
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.
These are more generally useful for general text width calculations
that don't necessarily involve TRAM.
Part of P0223, funded by Blue Bolt and rosenrose.
Since it also sets an activation flag, it does much more in context
than checking for a board. This name also highlights why OP.EXE and
FUUIN.EXE ignore the BGM mode specified in the option menu.
Part of P0216, funded by JonathKane.
And name the FM state in a way that already prepares modded PMD
support. That's the number 1 TH01 mod idea, after all.
Part of P0216, funded by JonathKane.
Turns out I've misread the execl() documentation. That function does in
fact *not* need a second `nullptr` parameter for envp, because it
doesn't pass envp.
Part of P0216, funded by JonathKane.
The only game to show an error message if you try directly launching a
game through its main executable without setting up sound drivers or
the resident structure, and a really good one at that. "Please start
from the batch file" is the most user-friendly sentence you could print
in that case.
Part of P0215, funded by Ember2528 and Yanga.
Hiding a lot of dynamic .PTN buffer size information behind misleading
labels. Nothing there to tell ZUN that he could have just easily saved
20% of all this memory by using a structure without an unneeded alpha
plane.
Completes P0214, funded by Ember2528.
Where ZUN forgets the trigonometry functions used everywhere else in
the game, attempts to implement a velocity calculation from scratch
instead, and fails in every way possible. Oh, and it also has an
out-of-bounds memory access…
Part of P0214, funded by Ember2528.
There might only be three functions between the second and new third
split, but these seem to depend on the entire rest of the code for
card-flipping stages…
Part of P0160, funded by Yanga.
Used for the 東方★靈異伝 effect at the beginning of each scene. Good
that there's this second TRAM page, that's how we can be lazy and just
write into the 26th row :tannedcirno:
Part of P0157, funded by Yanga.
A small function that prompted lots of research into whether it's
actually correct… which then revealed that every single widely used
PC-98 emulator is broken in this regard. More about that in two
upcoming pushes…
Part of P0157, funded by Yanga.
Which works in both Borland C++, Open Watcom, and Visual C++.
Not that we're about to port any of the games to these compilers, just
something I noticed while evaluating 32-bit compilers for ReC98's own
32-bit pipeline tools. Modders might want to look into that though,
since 100% position independence also makes it easier to change
compilers.
"Physics". Not only did ZUN restrict the X velocity to the 5 discrete
states of -8, -4, 0, 4, and 8 (because hey, unaligned blitting is slow
anyway?), but gravity is also only applied every 5 frames.
We're still missing quite a bit of usage code, but these are the core
functions. One of which turned out to be undecompilable, due to… a
rigorously defined instruction order when performing arithmetic between
`double`s and `float`s?! Still, spelling out all this stuff in ASM
seems much better than somehow splitting the data segment, just so that
we can immediately use literals there.
Part of P0097, funded by Ember2528.
Yes, TH01's memory info screen will recurse into itself for every 3
frames the PgUp key is held, requiring one additional PgDown press per
recursion to actually get out of it.
You can, of course, also crash the system via a stack overflow this
way, if that's your thing.
Part of P0091, funded by Ember2528.
nmlgc