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.
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.
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.
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.
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.
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.
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.
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.
A function which does so many individual things that I can't even
summarize it in a comment without spelling out each line of code. And
then, this entire clamped movement system is only used for Kikuri's
soul sprites. The usage code for every other entity just parties on
the [cur_left] and [cur_top] members, and passes a delta of (0, 0) to
this function. 🤷
Part of P0108, funded by Yanga.
Yet another unused function. No idea what it could have been intended
for – no boss sprite has animated sections that small.
But come on, out of all places that could have required the macro form
of a VRAM offset function, it had to be a unused one…
Anyway, that completes the low-level blitting functions for boss
entities!
Part of P0108, funded by Yanga.
Another unused function! This might indicate that Elis could originally
split herself into two sprites, similar to TH04 Stage 6 Yuuka?
Or it might just have been some other kind of animation effect, who
knows.
Part of P0108, funded by Yanga.
Used for Elis' entrance animation. Including an unused unblitting +
blitting function – apparently, ZUN wrote that one before the sloppy
EGC-accelerated wavy unblitting function that I decompiled way back in
6d2fa9f.
Oh well, the latter one is fine in context, since there are no other
sprites on screen during the animation.
Part of P0108, funded by Yanga.
… except that those single-plane functions provide basically no
useful abstraction in the context of a 4-plane image format. Should
have just gone all the way and directly take something like our
Planar<dots16_t> type to operate on all 4 planes, so that I wouldn't
have had to add that layer of abstraction myself.
Apparently, early ZUN was allergic to passing structures by reference?
Part of P0107, funded by Yanga.
Yes, functions! Those would have been nice earlier!
Also documented another overly specific Borland C++ code generation
quirk with regard to assigning expression results to elements of 16-bit
arrays…
Part of P0107, funded by Yanga.
"Oh wait, actually, I *do* want to blit 8 pixels at a time in some
cases" :zunpet:
First time in a long while that the VRAM access macros couldn't do the
job, because code generation wants *both* pointer arithmetic *and*
subscripts within the same expression.
But *come on*, just blit the 16 pixels for the byte-aligned case!
Part of P0107, funded by Yanga.
So if the boss entity class stores all non-pixel metadata for its
associated .BOS file, how can YuugenMagan have 5 independent eye
sprites, or Kikuri have more than one soul and tear sprite?
By duplicating that data, of course!
Those structure copies to local variables seen in the load functions
of these bosses still remain pointless, though.
Completes P0106, funded by Yanga.
"Hm, I have this format that specifies sprite width in multiples of 8,
but *actually*, I'd like to blit 16 pixels at a time… well, time to
pepper the code with divisions and casts, I guess :zunpet:"
Which becomes even more hilarious once you realize that the `operator
new` function does require bytes after all. Which leads
new dots16_t[image_size / 2];
to compile to
operator new((image_size / 2) * 2);
:tannedcirno:
Part of P0106, funded by Yanga.
What else to call something a boss can have multiple of, that may or
may not be part of a larger boss sprite, may or may not be animated,
and that may or may not have a orb hitbox?
Needed to be RE'd before the .BOS loading functions, because those are
actually methods of this class. And because renaming all these
variables in ASM land is tedious anyway, we might as well name each
individual entity of every boss.
Still, what's with the pointless local variable copies in the
YuugenMagan and Kikuri functions?
Part of P0106, funded by Yanga.
And that's all? No unblitting or non-aligned functions? Oh well, at
least this one correctly clips the sprite at all 4 edges of VRAM, for
once.
Part of P0105, funded by Yanga.
nmlgc