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.
Yeah, no, I'm not going to declare all of those as `extern` and then
"Move all data to C land" after decompiling the entire segment. Once
again (94372d2), it's not too bad – heck, in REIIDEN.EXE, it's less
than a screen worth of identifiers that are still being referenced.
Part of P0214, funded by Ember2528.
The .PTN functions, vector functions, and egc_copy_rect_1_to_0_1()
(finally!) from TH01, as well as playfld.hpp from all games(finally!),
together with a bunch of other functions in their vicinity.
Part of P0201, funded by Ember2528 and Yanga.
TH01 doesn't use "back" and "front" pages in the way the later games
do, after all. Indicating that the source page of this parameter-less
function is the one that was previously set via graph_accesspage_func()
is going to make pretty much all its call sites way clearer, and stops
implying any further state.
Part of P0167, funded by Ember2528.
So, we have a problem. The ridiculously optimized graph_putsa_fx() used
in TH04 and TH05 swaps out the target of two CALL instructions at
run-time… because there *really* wasn't any free register left for an
indirect CALL, eh? Therefore, the necessary relative addresses have to
be calculated at assembly time, by subtracting the target function
label from the call site label.
Unfortunately, the resulting values are stored in the .DATA segment,
which we can't move out right now. Declaring the labels as EXTERN
wouldn't work either, since the linker can't do fancy arithmetic and is
limited to simply replacing address placeholders with one single
address. This is explained pretty well at:
http://computer-programming-forum.com/46-asm/48f3d4a463bb38d1.htm
Which means we're stuck, and can't separate out this function for the
foreseeable future.
So, time to approach the SHARED segment from the top instead, to at
least get everything around graph_putsa_fx() done now. 🤷
vram_planes_set() is the first common function there. But since it was
introduced in TH01, we've got some maintenance to do for that game
first…
Part of P0138, funded by [Anonymous] and Blue Bolt.
Whoops, turns out that the build has been broken on TASM32 version 5.3
(the one in the DevKit) ever since 7897bf1. In contrast to version 5.0
(which I use for my development), 5.3 actually defines 32-bit segments
if you specify a .386 CPU before using .MODEL.
That might have been the reason for the .286 workaround all along?
Turns out there's the USE16 modifier, which makes this much more
explicit than switching CPUs.
Since I'd still prefer to not use include guards *and* to have that
standalone .GRZ viewer, these would have actually caused somewhat of
an issue with the upcoming final stretch of the master.hpp transition.
Part of P0133, funded by [Anonymous].
Which gets rid of 13 redundant translation units. Definitely a good
start, before I figure out how to best handle the more complicated
cases.
(Maintenance mode commit)
And get rid of the constraining FX() macro, with its spacing parameter
that we haven't even seen used so far.
Part of P0124, funded by [Anonymous] and Blue Bolt.
By now, it's become obvious where it has to be. Apparently, the order
of translation units inside ZUN's modified master.lib did somehow
change with TH02?
(Maintenance mode commit)
ZUN might have gotten the impression that the EGC can *only* work with
multiples of 16 pixels per load or store? Which might explain why…
Part of P0102, funded by Yanga.
100% PI for both! Now, where are all the modders who wanted to replace
MDRV2 with PMD… because you can now prototype that, without worring
about x86 instruction lengths, at least inside the main menu.
Part of P0095, funded by Yanga.
> "Sure, this is a PI push, but this second-to-last set of PI false
positives so small, let's immediately decompile it ^.^"
> Time taken: 22 minutes
Nice when this works out!
Part of P0095, funded by Yanga.
Starting with the odd one out, the one that doesn't use master.lib and
has two input sense functions: one for the main menu, and one for the
option window.
Both of which also immediately perform the ring arithmetic on the menu
cursor variable… because there's nothing else to be done with these
inputs in OP.EXE? Separating input sensing from processing apparently
wasn't all too obvious of a thought, and it's only truly done in TH02
and later.
Part of P0090, funded by Yanga.
That's… pretty specific. The only thing on the main menu with this
color is the "1996 ZUN" text at the bottom… probably part of an
effect that we never got to see. Every other idea would be baseless
speculation, given that the snapped buffer isn't used anywhere else.
Part of P0090, funded by Yanga.
Also something that any future ReC project should be doing right at the
start. Finally, it made sense to do it here as well, because…
Part of P0084, funded by Yanga.
Which repurpose the .PTN image slots to store the background of
frequently updated VRAM sections, like all the numbers in the HUD.
Future games would simply use the text RAM and gaiji for numbers. Which
would have worked just fine for TH01 as well (especially since all the
functions we've seen so far are aligned to the 8-pixel byte grid), but
it looks as if ZUN simply wasn't aware of gaiji during the development
of TH01.
Part of P0083, funded by Yanga.
Mangled C++ function names would *not* have been a mistake if I hadn't
made the other mistake of restricting parts of the code to C…
Part of P0083, funded by Yanga.
nmlgc