All but one of the writes to these globals follow the consistent scheme
of assigning hardcoded literals to first `w` and then `h`, so it makes
sense to encapsulate the conversion from display-space pixels to VRAM
words and heights in a method.
(On that note, we also need a new type to encode the notion of
VRAM-space heights as opposed to the display-space heights of
`pixel_t`.)
Part of P0280, funded by [Anonymous], Blue Bolt, and JonathKane.
Unfortunately, it's still premature to start a separate header file for
display-space coordinates like I'm doing with Shuusou Gyoku. What does
make sense, though, is moving the display-space vector types next to
the display-space scalar types in `pc98.h`. This makes much more sense
than keeping them in `master.hpp` just because master.lib also has a
Point type. Would have thought that this lets us remove more than two
`master.hpp` inclusions, though…
Part of P0240, funded by JonathKane.
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.
• Comments that describe all lines of code until a blank one are placed
into the lines immediately above
• Comments that describe an entire demarcated block are placed
immediately below the dash row at the top
• In any case, there should be a blank line after the top comment of
a demarcated block, to keep IntelliSense-style systems from applying
the block comment to the first actual line of code…
• …but there shouldn't be one before the dash row at the bottom, where
it'd be redundant.
Part of P0207, funded by GhostPhanom.
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.
Allowing us to consistently mirror the declaration in pc98.inc
without adding a planar.inc file. 😛 And points us to two more
dots8_t* arrays that should have used the Planar<> template.
Part of P0135, funded by [Anonymous].
The regular master.h is big, uncomfortable in C++ mode, and bloated
with all those portability `#define`s that effectively only cover a
small portion of the PC-98-specific code anyway. So, let's gradually
transition to a new smaller header that is more integrated into the
ReC98 codebase, by simply no longer #including `master.h` in new code.
Which also explains its weird place in the root directory. Even though
`libs/master.lib/` contains plenty of game-specific modifications, it
didn't feel right to have anything in this directory refer to types
from `pc98.h`.
Part of P0124, funded by [Anonymous] and Blue Bolt.
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.
One fewer magic number. And one more deliberate dependency on a
PC-98-specific hardware constant, to further drive home just how
unportable these games are, even once decompilation will be complete.
Part of P0105, funded by Yanga.
Again, 11 necessary workarounds, vs. forcing byte aligment in at least
18 places, and that number would have significantly grown in the
future.
Part of P0085, funded by -Tom-.
No macros for the port numbers here! Anyone who will try to read and
understand this code will probably want to look those up in PC-98
hardware documentation, and macros would just be an annoying layer of
indirection then.
Part of P0080, funded by Ember2528 and Splashman.
Page… 2? On a system with only page 0 and 1? Had to get out my real
PC-98 to double-check that I wasn't missing anything here, since
every emulator only looks at the bottom bit of the page number. But
real hardware seems to do the same, and there really is nothing special
to it semantically, being equivalent to page 0. 🤷
Part of P0080, funded by Ember2528 and Splashman.
Allowing us to then retrieve it using a function call with no run-time
cost, although we do have to be careful with the types here.
Also, is that another solution to decompilation puzzles that involve
types of number literals?
Part of P0080, funded by Ember2528 and Splashman.
I did consider not doing this, because "well, can't anyone who's
*actually* interested just diff the TH01 and TH02 implementations to
figure out the differences themselves", but that duplication ended up
feeling too filthy after all.
And hey, it's a nice excuse to update TH02's version to current naming
standards! 😛
Part of P0068, funded by Yanga.
Semi-unused, that is, the one use of this function doesn't actually
move the rectangle to a different position. Ironically, the non-moving
back-to-front function immediately above *is* unused…
Also, too bad that stack order is the only reason we can't use structs
to combine all plane variables into a single object.
Part of P0067, funded by Splashman.
Previously sloppily mis-RE'd as "some page variable, idk", back in
2015…
Now also with a page number typedef. And yeah, restricting bool to C++
has now proven to be stupid after all.
Part of P0067, funded by Splashman.
Right, PC-98 hardware only supports 4 bits per RGB component, for a
total of 4,096 possible colors. The 8-bit RGB color values we've been
seeing throughout the later games are a master.lib extension, to allow
for more toning precision. Which TH01, with all its NIH syndrome,
doesn't use.
And yup, that means templates in the most basic header files… Since
that would have meant renaming *everything* to compile as C++, I simply
made these types exclusive to C++ code, thcrap style.
Part of P0066, funded by Keyblade Wiedling Neko and Splashman.
Oh, OK, so this is what the PC-98 GRCG is all about. You call grcg_setcolor(),
and that puts the PC-98 hardware in some sort of "monochromatic mode". Then,
you just write your pixels into any *single* one of the 4 VRAM bitplanes. This
causes the hardware to automatically write to *all* bitplanes in such a way
that the final palette index for each of the 8, 16, or 32 pixels you just wrote
a 1 value to will actually end up to match the color you set earlier.
Don't forget to call grcg_off() at the end though, or you can't draw any
non-monochromatic graphics, heh.
Yes, all of it. Including the bouncing polygons, of course. And since it's
placed at the end of ZUN's code inside the executable, the code's already
position-independent and fully hackable.
nmlgc