And that's the intended way to play back the hidden DEMO5.REC. Unlock
the Extra Stage with all 4 characters, then hold the left and right
arrow keys in the main menu while waiting the usual demo replay.
For a recording of that replay, see
https://www.youtube.com/watch?v=iP2ywlW2u4U
Completes P0119, funded by [Anonymous] and -Tom-.
Why does this function also have to load sprites for the viewing mode
of the high score menu?! Oh well, ridiculous functions deserve
ridiculous names…
Part of P0119, funded by [Anonymous] and -Tom-.
The TH04 one might have the same function structure, but the only thing
that's actually identical in both games is the picture darkening loop.
Part of P0119, funded by [Anonymous] and -Tom-.
Wow, this is the first time we're about to call any of these from C
land in ≥TH03? Found no built-in way to just uppercase an identifier
in TASM, so apparently we have to spell out the names in both lower-
and uppercase.
So, let's go back to regular, non-macro PUBLIC / PROC / ENDP code
wherever we can – for all functions introduced in ≥TH03, and for
everything that takes no parameters. It's simply not worth the
trouble.
Part of P0114, 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.
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.
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.
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.
… 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.
The kind of minor copy-pasting mistake that should have been caught by
a proper type system… which ReC98 can only simulate to an extent.
Part of P0110, 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.
As in, the global variables describing the area that should be checked
for collisions with player shots in the next call to the shot hit test
function.
Part of P0109, funded by [Anonymous] and Blue Bolt.
Because pretty much all of TH05's bullet spawn code is micro-optimized
and undecompilable ASM, we'll unfortunately have to keep those ASM
versions around forever 😕
Well, the TH05 ones at least.
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.
ZUN might have gotten the impression that the EGC can *only* work with
multiples of 16 pixels per load or store? Which might explain why…
Part of P0102, funded by Yanga.
nmlgc