Very helpful at this small scale, as it allows us to directly decompile
floating-point literals. These will be added to Sariel's regular
translation unit in the same order, so we merely have to remove them
from this temporary translation unit then.
Part of P0174, funded by Ember2528.
"I don't need the return value in MAINL.EXE? Let's copy-paste the
function and remove all of its `return` statements then!" :zunpet:
Completes P0172, funded by [Anonymous] and Blue Bolt.
Featuring inline assembly for a single ROR instruction. Turbo C++ 4.0J
unfortunately only offers intrinsics for 16-bit rotations.
Part of P0172, funded by [Anonymous] and Blue Bolt.
Aha! TH05 actually loads every single rendered dialog image
individually before rendering it, either from the EMS area or disk.
That's one way to save memory, I guess?
Part of P0169, funded by Blue Bolt.
No, I'm not copying exactly what was on ZUN's monitor during the 2010
MAG・ネット documentary. Also, this one was very lucky not to receive
a stupid function name.
Part of P0168, funded by Blue Bolt and rosenrose.
I've long moved to a convention of putting every .OBJ compiled from ZUN
code into the subdirectory of the game that introduced it. These four
are the last remaining inconsistencies from earlier in development.
Part of P0162, funded by Ember2528.
Only seen in Mima's fight, but initialized for all non-final boss
fights. Also with explicit support for all 8 origin edges, not just the
top-right one used in Mima's fight… and an off-by-one error?!
Completes P0160, funded by Yanga.
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.
Third longest function in all of PC-98 Touhou, and it's even more of a
copy-pasta than the patterns we've seen earlier. Certainly didn't feel
that long.
Part of P0156, funded by Ember2528.
Reason: That switch statement. How should we even?
Well, the code *is* fairly good. After looking very deep into it, and
spending 35% of that function on blank lines (for logical grouping) and
explanatory comments, that is…
Part of P0152, funded by -Tom- and [Anonymous].
… (24 + (difficulty * 8) + rank) in TH04, and (42 + (difficulty * 8))
in TH05. Also, TH05 only doesn't have TH04's bullet zap animation
because ZUN didn't consistently use constants…
Completes P0151, funded by Blue Bolt and -Tom-.
Slow Mode only does one thing: It looks at how many 8×8 pellets or
16×16 bullets are alive, and reduces the frame rate by 33% (i.e., turns
every second frame into two frames) if that number is…
Part of P0151, funded by Blue Bolt and -Tom-.
… Wait, we *can* decompile functions with both parameters, no stack
frame, and a Pascal calling convention?! Good that I already forgot how
impossible it was to decompile the first function I looked at that fell
into this category!
Part of P0148, funded by [Anonymous].
Including the pointless DOS I/O variation in TH05's MAIN.EXE.
I'm slowly running out of characters to remove from the first segment
name in that file, though…
Part of P0148, funded by [Anonymous].
Last one! Done with the SHARED segment for the forseeable future! 🎉
Sure, not the best C++ code either, but still by far the sanest
implementation of this function in any of the 4 games.
Completes P0139, funded by [Anonymous].
Segment alignment issues once again… but that completes the SHARED
segments of all TH03 and TH05 binaries, for now!
Part of P0139, funded by [Anonymous].
4 games, 4 different versions of this function. Interestingly,
moving the game-specific differences to inline functions makes it
obvious that this function was only intended for BGM, not sound
effects.
Part of P0139, funded by [Anonymous].
We've been using the three-letter extension names for everything else
that isn't .DAT, so it's more consistent to do the same for .MPN,
however particularly nice and readable its FOURCC may be. 8.3 filenames
also really appreciate that they'll have to accommodate one fewer
letter.
Part of P0138, funded by [Anonymous] and Blue Bolt.
Segment alignment forces us to do all of those at once… but now, we've
not only caught up with the segment split point in TH04's OP.EXE and
MAINE.EXE, but also decompiled all instances of DEFCONV functions!
Part of P0138, funded by [Anonymous] and Blue Bolt.
Boom! Clever segment renaming allows us to link the same .OBJ into 12
binaries.
(Well, 10 for now, due to alignment issues in TH04's OP.EXE and
MAINE.EXE.)
Part of P0138, funded by [Anonymous] and Blue Bolt.
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.
Exhibit B for the theory that ZUN did *not* set the default calling
convention to `pascal` for TH03.
Part of P0138, funded by [Anonymous] and Blue Bolt.
nmlgc