With TH05 definitely being the Galaxy Brain version of this function.
You'll see once I get to push the C decompilation for that one…
Anyway, that covers all shared input functions of TH02-TH05!
Funded by zorg.
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.
nmlgc