In which we exchange variable names for the ability to decompile more
than just 3 instructions here.
… yeah, "decompilation" is still a stretch.
Part of P0114, funded by Lmocinemod.
About time I finally developed this piece of tech. Towards TH05, this
segment got more and more undecompilable ASM functions mixed inbetween
C ones. Which means that pretty much all of the current ASM land
`#include`s in that segment will have to become translation units. And
we *really* don't want an additional layer of numbered, per-binary
translation units that just `#include` maybe one or two functions.
Also yeah, no _TEXT suffix, to drive home the point that this is a
"library" segment, and not really "owned" by any one file.
Part of P0113, funded by Lmocinemod.
No need to make the function names more complicated if we already
expressed the one subtle format difference between TH03 and TH04/TH05
in the plane layout enum.
Part of P0113, funded by Lmocinemod.
Yeah, why *were* we assembling them in the 16-bit part before?!
Possible reasons:
• In a time before Tup, it made no actual difference whether these
little files were assembled in the 32-bit or 16-bit part. Now it sort
of does, since we've temporarily given up on minimal rebuilds in the
16-bit part.
• Emphasizing the temporary nature of the 32-bit part by deliberately
moving everything to the 16-bit part as early as possible?
• It all started with the ZUN.COM ASM code, which doesn't include any
other files, and can therefore be perfectly tracked by a Makefile.
Which *was* superior than the exclusive dumb batch file we had in the
past. And then I've simply cargo-culted all new .ASM translation
units into the 16-bit part well.
Oh, and another positive side effect of temporarily not using 16-bit
TASM: The build process now also runs on Windows 95.
Part of P0113, funded by Lmocinemod.
This Tupfile does in fact date back to January 2017, and I've been
using it myself ever since. Time to finally deliver it on master!
Part of P0001, funded by GhostPhanom.
If the output file already exists, TASM interprets a filename with
extension as a directory, and then concatenates the implicitly
generated output file name to that path… yup.
Part of P0001, funded by GhostPhanom.
Yup, let's completely avoid any of the benefits a Makefile might have
had, because they're completely unreliable without spelling out every
single #include. Such a trash technology, unsuited for pretty much
anything it's touted for.
Oh well, you can still call `maker` manually without the -B flag, if
you know for a fact that you've only modified the dependencies
currently listed. 🤷
At least this flag exists, and we don't have to add something like a
dummy .OBJ to each and every list of dependencies, so that we then can
force rebuilds by simply `touch`ing that one file…
Part of P0001, funded by GhostPhanom.
Lol, this led the bmp2arr compilation to fail on a clean checkout.
Lesson learned: Always test on a clean clone, not in your separate test
repo that you just `git pull` up to the final commit in a push, but
with all the build artifacts still in there…
Also, yes, `mkdir` only supports backslashes.
Part of P0001, funded by GhostPhanom.
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.
No structure declaration in the header file needed, since the game
doesn't party on its members from outside, for once!
Part of P0112, funded by [Anonymous] and Blue Bolt.
Which does have the practical effect of communicating more information
via IntelliSense during regular development!
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.
The trivial one first, while I try to wrap my head around what's going
on with Reimu's TH05 bomb animation…
Part of P0111, 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.
… and this one, while I'm at it. I've been using pretty much every
possible type for VRAM offset variables, depending on my mood that day,
since signedness apparently never matters for those.
Except that it does. And so, just like with most of our high-level
types, we also have to account for ZUN's little signedness
inconsistencies here. Oh well, at least it's now only one of two types,
and there's no need to choose between `int` or `unsigned int` or
`short` or `unsigned short` or `int16_t` or `uint16_t` or `size_t` or…
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.
nmlgc