And that's it, actual position dependence achieved! 🎉 Again, the
website won't quite show 100% PI, but that (again) are all false
positives, to be covered in an upcoming push…
Completes P0112, funded by [Anonymous] and Blue Bolt.
Making sure that we don't ever have to iterate over the 8×8 pellet part
of the bullet array during rendering… sure, but why not give the same
optimization treatment to the 16×16 bullets?
Part of P0112, funded by [Anonymous] and Blue Bolt.
Right, *_TRAM_W refers to 8-pixel halfwidth characters, and *_KANJI_W
to 16-pixel full-width characters… which also include gaiji, which are
what the entire HUD is made out of.
Part of P0112, funded by [Anonymous] and Blue Bolt.
…Wow. A 32-element lookup table for the very computationally expensive
operation of (i * 320), needlessly limiting the amount of unique 384×80
tile sections in a stage to 32… and then TH05 further "optimizes" this
lookup by pre-multiplying all section IDs in the .STD file with the
element size of that table, to save a grand total of 1 x86 instruction.
Part of P0112, funded by [Anonymous] and Blue Bolt.
After ternary expressions straight out of Jigoku in 57be510, we now got
pointer arithmetic straight out of Jigoku… with, unsurprisingly, two
ZUN bugs.
Part of P0112, funded by [Anonymous] and Blue Bolt.
Final structure in TH05's `MAIN.EXE`! And, just like this game's custom
entities, every character uses the same structure fields with vastly
different semantics and high-level types… yup, time for separate
structures again.
Part of P0112, funded by [Anonymous] and Blue Bolt.
We've been establishing `screen` as meaning "a coordinate rooted at the
top-left corner of the display", whereas most of the Subpixels in >TH01
are rooted at the top-left of the playfield.
Part of P0112, funded by [Anonymous] and Blue Bolt.
Final unknown entity in TH05 that can collide with the player!
Get position independence hype!
(Also, no structure member comments necessary, thanks to the new
types!)
Part of P0111, funded by [Anonymous] and Blue Bolt.
Whew, time to look at every `int` variable we ever declared! The best
moment to do this would have been a year ago, but well, better late
than never. No need to communicate that in comments anymore.
These shouldn't be used for widths, heights, or sprite-space
coordinates. Maybe we'll cover that another time, this commit is
already large enough.
Part of P0111, funded by [Anonymous] and Blue Bolt.
With all the memmove()-style shifting of individual lines, there's
probably a point to reserving 20 lines per set, but only ever rendering
4 of them. We'll see once I get to decompile all of these functions.
Part of P0110, funded by [Anonymous] and Blue Bolt.
Not just used for the zooming lines in Shinki's background, but also
for the pentagram (and circle!) in EX-Alice's background.
Part of P0110, funded by [Anonymous] and Blue Bolt.
Wow, so the boss_stuff_t structure did exist in the original code after
all. This is the only function in all of TH04 and TH05 that confirms
it – in dea40ad, it just seemed like something I made up, out of
convenience.
Completes P0109, funded by [Anonymous] and Blue Bolt.
Right, because you'd also want to automatically shift the IDs for every
stage-specific sprite if you add or remove a new stage-independent one.
Part of P0109, funded by [Anonymous] and Blue Bolt.
If C allowed labels of other functions as `goto` targets, this *might*
have been decompilable into something useful to modders. But like this,
there's no point in even trying.
Yeah, you *really* don't want to base your fangame mod on TH05.
Part of P0109, funded by [Anonymous] and Blue Bolt.
Found a uth05win inaccuracy! Once the Y coordinate gets close enough to
the target point, it actually speeds up twice as much as the X
coordinate would. This might make uth05win a couple of frames slower in
all boss fights from Stage 3 on.
And yeah, got too used to decompilation to go back to splitting off
RE'd functions in ASM land 😛
Part of P0109, funded by [Anonymous] and Blue Bolt.
One fewer magic number. And one more deliberate dependency on a
PC-98-specific hardware constant, to further drive home just how
unportable these games are, even once decompilation will be complete.
Part of P0105, funded by Yanga.
Also great news for those people who want to remove any and all C++ in
their mods, because this forces us to spell out subpixel literals as
actual floats, every time. And with that, you're back to being able to
simply search-replace for all the instances you'll have to change.
Part of P0099, funded by Ember2528.
A future sprite converter (documented in #8) could then convert these
to C or ASM arrays.
(Except for the piano sprites for TH05's Music Room, which are stored
and used in such a compressed way that it defeats the purpose of
storing them as bitmaps.
Otherwise, TASM would simply convert all EXTRN declarations in those
files to uppercase. Then, the linker would expect them in uppercase,
forcing both the case-sensitive big 32-bit .ASM files *and* the entire
C land to declare them as uppercase as well.
For functions with __pascal convention which are always uppercased
anyway, this makes no difference. It does matter for regular __cdecl
variables, though, and the C declaration of [score_delta] in e6294c2
already showed that we'd then be forced to use macros if we wanted to
pretend that these names still had lowercase characters.
Doing this for every variable referenced in both C land and 16-bit ASM
land gets annoying quickly. So, no need to force this inconsistency if
we can get rid of it by slightly uglifying ASM land.
Part of P0089, funded by [Anonymous] and Blue Bolt.
A bit tricky with those ASM translation units near-calling functions in
the very first segment, and #pragma codeseg requiring an additional
group parameter to correctly calculate array offsets (including those
used for `switch` statements). But doable.
Part of P0089, funded by [Anonymous] and Blue Bolt.
Last one of the shared entity types! The TH05 version of the .STD enemy
VM would now be ready for decompilation in one single future push.
Completes P0088, funded by -Tom-.
Copying out the shot position might have actually been a decent
optimization for hit detection, to avoid the indirection if the shot
is not colliding with anything.
Part of P0088, funded by -Tom-.
TH04's z_super_roll_put_tiny_32x32(), which this is based on, had
checks for not writing empty rows to VRAM. Why would ZUN remove them
here?
Completes P0086, funded by [Anonymous] and Blue Bolt.