Seemingly included in every other larger structure describing anything
remotely sprite-like. Couldn't find this in the earlier games,
unfortunately…
Funded by zorg.
TH02 just seems to use a sequence of branches in sub_D6CA.
I thought about keeping variable and function names consistent with
uth05win (on which most upcoming reverse-engineering commits will be
based). But as it will turn out, it ignored a certain very important
substructure, so I don't think it's worth introducing this naming style
clash.
Funded by zorg.
Comparing with uth05win, I renamed some
label so that easy to see.
I should not test whether there is grammer error.
So if you find some grammer error, please notice me.
• Mention the existence of DOSBox-X
• Add more reasons why this project is a good idea
• PyTouhou is actually quite the opposite of what we are doing
• JynX's Re:Mystic Square wasn't actually written in Danmakufu, thanks
to Ryann1908#9434 for reporting this oversight
• Move details about our planned remakes down to the Moddability section
of the roadmap (yeah, I no longer believe we're ever gonna see those)
• Who needs this entire "we are not a wholesome FOSS project" sentence
anyway
Now you can mix and match characters and shot types any way you want.
TH02 and TH05 simply use the regular shot sprites associated with the
character/shot type no matter which function is used, which quite
surprisingly works without glitches for the few combinations I've tried.
TH04, however, always uses the sprites that were originally intended to
be used with that shot function, regardless of the character you assign
the function to, meaning that it always loads all 4 shot sprite sheets
into memory. Not doing that would have been one way to reduce the game's
memory footprint so that it doesn't require an extender…
Funded by -Tom-.
TH01 was done in 3b175c8, TH03 obviously has two of those and uses a
structure for it, TH04 doesn't move it out of the resident structure.
Funded by -Tom-.
Mostly used for animations, but NOPping out the assignments causes
Ultra-like behavior in some (mid)bosses, at least in TH04 and TH05?
Funded by -Tom-.
In which ZUN actively refuses help from master.lib and rips out
everything that isn't immediately related to reading the one joystick
port of the PC-9801-86 sound board.
Maybe there actually was a good reason for that?
Funded by -Tom-.
Two DOS utilities were made for this:
- gensize: generates TASM macro definitions with filesizes.
- copycat: similar to copy/b a+b+c d, except a+b+c is specified in a
separate file to avoid command line length limitations.
th02/zun.com is bit-perfect
th03/zun.com is almost there, with insignificant differences in
zunsp.com and res_yume.com.
TASM crashes if you try to define a structure member with the same name
as an existing numeric equate.
And yes, we should have solved this by finally librarifying master.lib,
but that'll be a rather involved subtask as well.
DOSBox-X seems to have some problems with it, or maybe that's just me
having configured something wrong. In any case, it's not like we need
that extra memory, so removing the need for the DPMI driver removes
one more potential source of problems.
Oh, and it has always been part of the devkit. :P
word_20616 in TH02's MAIN.EXE does the same, but uses a weird unit.
Half-seconds, maybe?
thcrap-like Skipgame functionality is still out of reach, unfortunately.
But eh, now you can practice midbosses while being underpowered, if you
want to.
Funded by -Tom-.
Yes, you're reading that correctly. If the cursor is at 255, reading a
16-bit value will fill the upper 8 bits with the neighboring cursor
value, which always is 0xFF.
Funded by -Tom-.
TH03 is still rather confusing with apparently three of those, TH02 was
done in 17f6ac7d, TH01 doesn't even copy it out of the resident
structure.
Funded by -Tom-.
Look at that TH05 vector2_at_opt function. What the hell, the caller is
supposed to set up the stack frame for the function? How do you even get
a compiler to do this (and no, I haven't found a compiler switch)? No
way around writing a separate "optimizer" as part of the compilation
pipeline, it seems.
OK, let's not identify the arrays in a file-based fashion just yet, and
first reduce all shared ZUN code that uses arrays. Less stressful, we'll
have to do this anyway, and I just can't resist the urge to immediately
reverse-engineer everything I find.
And already, the script begins to crumble, reminding me of what a
terrible idea it actually was. Like, if you did it for real, you'd get
so many false positives that the script stops being useful, since
every raw number above 0x90 (the size of the _DATA segment of the
Borland C++ DOS startup code) can potentially be a memory reference.
I do think that the script now covers the sweet spot between full-blown
emulation and shallow parsing though, so going to do at least a few
more files.
Which is the last step on the way to completely position-independent
code, with no random hex numbers that should have been data pointers,
but weren't automatically turned into data pointers by IDA because
they're only ever addressed in the indirect fashion of
mov bx, [bp-array_index]
mov ax, [bx+0D00h] ; 0D00h is obviously an array of some sort
Removing all of these makes it practicable to add or delete code without
breaking the game in the process. Basic "modding", so to speak.
Automatically catching all possible cases where this happens actually
amounts to emulating the entire game, and *even then*, we're not
guaranteed that the *size* of the array just falls out as a byproduct
of this emulation and the tons of heuristics I would have thrown on top
of that. ZUN hates proper bounds checking and the correct size of each
array may simply never be implied anywhere.
So, rather than going through all that trouble of that (and hell, I
haven't even finished *parsing* this nasty MASM assembly format), and
since nothing really has happened in this project for almost two years,
I chose to just turn this into a text manipulation issue and figure out
the rest manually. Yeah, quick and dirty, and it probably won't scale if
I ever end up doing the same for PC-98 Policenauts, but it'd better work
at least for the rest of PC-98 Touhou.
Trying to do one of those per day from now on. Probably won't make it
due to the reverse-engineering effort required for the big main
executables of each game, but it'd sure be cool if I did.
This, hands down, has been the single worst stretch of decompilation so far.
Three extremely difficult functions that each still required inline assembly.
And no, this didn't even work out with any of the optimization features in
Borland C++ that aren't included in Turbo C++.
Oh, right, these functions can have parameters. So, let's turn snd_kaja_func()
into a macro that combines the function number and the parameter into the AX
value for the driver.
And renaming them all to the short filenames they will be decompiled to for
consistency. These functions aren't really immediately hardware-related, as
we've established earlier in the decompilation.
nmlgc