... and then I end up copying modified versions into the individual game
subdirectories after all, because the changes between games were simply too
drastic. (That's also why I'm counting pfopen() itself twice.)
Only one slice left now, and then we're done with reduction!
Yup, packfiles finally proved that we really have a different set of changes
to master.lib in every game. Also, there are bound to be more of these game-
specific small changes to otherwise identical code in ZUN's own code.
And hey, no need to define that value in the build scripts anymore.
(I've also considered just copying modified versions into the individual game
subdirectories, but it's not too nice to expect people to diff them in order
to actually understand why these copies exist and where the changes actually
are.)
> introduce a new macro to halve the lines of a far function pointer
assignment, hoping that this commit will end up deleting more lines than it
adds, because TH03 has lots of those
> oh wait, these games mainly use near function pointers
> unearth even more new functions in the process
Seriously, how many more functions are still hidden in this codebase? And all
that just because IDA was not smart enough to begin with.
(Damn, the other commit prepared for today is not getting done, why does IDA
have to be so terrible...!)
Anyway, here's a small consistency edit instead.
Once you've actually found the right syntax that makes the assembler just use
the default call type of the current memory model for both procedures (where
it's just "PROC" without anything else) and labels (where it's "LABEL PROC"),
these constants become completely unneccessary, even with TASM.
> randomly google "PC-98 ライブラリ"
> 3rd hit: http://www.vector.co.jp/soft/dos/prog/se037608.html
> Oh look, it's the mystery code at the beginning of the TH01 executables!
This library also has dedicated support for transparency, which is used in the
Konngara fight (BOSS8_D*.GRP) and which we couldn't edit during the
development of the static English patches.
But of course, ZUN just had to change the format magic in order to make it
seem unique.
I guess this marks the final demystification of how segment declarations work
and how they are compiled. However, it only really makes sense for anything
outside the TEXT segment, like these floating-point functions. As long as the
slices aren't immediately next to each other, it would still be annoying to
have segment declarations inside of them, since we'd have to copy-paste these
declarations around every INCLUDE directive...
Finally - and there was indeed no way around switching to JWlink, as ALINK
v1.6 refuses to link the TH01 executables with a nondescript "Undefined base
seg" message once nec_fpinit.asm is included.
Since DSEG is *supposed* to be aligned to a paragraph boundary, this should
have never mattered. However, JWlink seems to not obey this segment alignment
in some layer of the linking process.
This now guarantees identical builds with TLINK, ALINK and JWlink.
So that's the - admittedly rather weird - solution to the problem that has
been plaguing this project ever since the beginning of the reduction step.
Without any 32-bit dummy segments in the compiled object files, more linkers
will be able to build this project, one of them being JWlink
(http://sourceforge.net/projects/jwlink/).
Still can't rename dseg to _DATA though, as TASM stupidly refuses to accept
any ALIGN directives above a segment's alignment attribute value. TH01's
floating-point data slices already require larger alignments, and we're very
likely to have even more of those in the future.
Also, we're finally defining the Borland C++ model symbols directly in the
code, rather than in my unpublished build batch files. :)
nmlgc