And of course, TH05 ruins the consistency once again. Sure, the added
file error handling is nice, but we also have changes in the playful
messages (lol), and now need a third distinct optimization barrier
(🤦)… But as it turns out, inlined calls to empty functions work as
well. They also seem closer to what ZUN might have actually written
there, given that their function body could have been removed by the
preprocessor, similar to the logging functions in the Windows Touhou
games. (With the difference that the latter infamously *aren't*
inlined…)
Part of P0077, funded by Splashman and -Tom-.
Huh, C++ wants its `char`s to be unsigned in order to *not* sign-extend
them to 16 bits for comparison against ASCII literals?!
Anyway, that completes TH03's ZUN.COM, with bascially no new C code.
Part of P0077, funded by Splashman and -Tom-.
The supposedly low-hanging fruit that almost every outside contributor
wanted to grab a lot earlier, but (of course) always just for a single
game… Comprehensively covering all of them has only started to make
sense recently 😛
Also, yes, the variable with the uppercase .CFG filename has itself a
lowercase name and vice versa…
Part of P0077, funded by Splashman and -Tom-.
Oh wow, caff4fe introduced wrong bytes into RES_KSO.COM by confusing
[cfg_bombs] with [credit_lives] -.- Which I didn't find out back then
because all the RES_*.COM binaries still had some different instruction
encodings anyway and I just didn't care enough to base my diff of those
files on the wrong encoding versions to notice the bug…
Whoops.
Part of P0077, funded by Splashman and -Tom-.
4½ years after aa56a7c, it turns out that the correct decompilation
involves… no-ops generated by assigning variables that just happen to
be in registers to themselves?! Which does get optimized out, but only
after TCC folded identical tail code in all branches of a function,
thus effectively functioning as an optimization barrier.
The initial attempt used register pseudovariables, but this definitely
is the best possible way this could work – portable, and doesn't
unnecessarily shred the code into tiny inlined functions pieces. The
mindblowing thing here is that ZUN could have actually written this to
have additional, albeit unnecessary, lines to place breakpoints on. But
that means he must have chosen those two local variables in SI and DI
completely by chance… 🤯
The best thing though? ~#pragma inline is gone~
Part of P0076, funded by [Anonymous] and -Tom-.
Necessary to make string literals from the first one end up at their
correct positions in the data segment even after the upcoming
deduplication…
Part of P0076, funded by [Anonymous] and -Tom-.
Something small that came out of the resident structure review.
Including more research to suggest that we probably can't ever use C++
constructors for anything in ReC98.
Part of P0076, funded by [Anonymous] and -Tom-.
Now with the correct types, more consistency with the other games with
some field names (rank, is_cpu, rand, bgm_mode, demo_num), and some
more research to improve some of the TH03-specific fields.
Part of P0076, funded by [Anonymous] and -Tom-.
Both player/player.hpp and resident.hpp (in case of TH03's PLAYER_COUNT)
and th04/shared.hpp (in case of TH04/TH05's MAIN_STAGE_COUNT) have way
too much additional stuff that we don't want to include everywhere we
need these constants. So let's try this "no types allowed" approach
instead… maybe that'll work out for once.
Part of P0076, funded by [Anonymous] and -Tom-.
Much better than the previous incorrect comment, since the char_id()
method now easily generates the correct sequence of conversion
instructions, seen all throughout the ASM. Even within array
subscripts!
Part of P0076, funded by [Anonymous] and -Tom-.
Oh hey, guarding declarations with complicated types via #ifdef limits
the header files we additionally have to #include!
Part of P0076, funded by [Anonymous] and -Tom-.
Well… how else to call a variable that handles
• pellet vs. 16×16 sprite (TH04),
• the delay cloud flags from bullet_spawn_state_t, but with different
values (which is restricted to 16×16 sprites in TH04),
• optionally showing the gather animation before spawning the bullet
… whether the bullet uses the basic slowdown motion (TH05),
(which is restricted to pellets in TH04),
• and defining what happens *after* the gather animation – not actually
spawning any bullets (TH04), or using the special motion type from
the bullet template (TH05)
🤯
Completes P0075, funded by Myles and -Tom-.
Turns out that angles are more clearly expressed in hex after all. And
if we use negative values for everything greater than 80h, we still
remove those from the PI calculation.
*Really* not sure about using that delta union in the TH04 one though.
Might be saner to just hide the complexity of the technically two
separate types after all… Let's see.
Part of P0075, funded by Myles and -Tom-.
uth05win TL note: "n-way all-around" means "ring"… yep, let's better
improve on the naming here, once again using established terminology
from Sparen's Danmaku Design Guide at
https://sparen.github.io/ph3tutorials/ddsga3.html
Since TH04 only supports rings *or* spreads *or* stacks, overloading
[delta] to store both spread angle and stack speed, that enum does
serve kind of a purpose in TH04. Unlike TH05, where it could be vastly
simplified to a bitfield with 4 flags: aim to player, randomize angle,
randomize speed, force single. Which could then actually create *more*
types of patterns than these uselessly defined 14 distinct types, all
of which can already be derived from the other values of the upcoming
template structure:
• Set [stack] to 1 if you don't want a stack
• Set [spread] to 1 if you don't want a spread
• Set [spread_delta_angle] to 0 to turn a N-way spread into a ring
Easy.
Part of P0075, funded by Myles and -Tom-.
Since they're determined by the order of sprites in a .BFT file,
they're best auto-generated by an enum as much as possible.
Part of P0074, funded by Myles.
Might as well cover this one while I've got this type of function in my
head. This one is used for the animated star backgrounds during Stage 2
and the Shinki battle.
Completes P0073, funded by [Anonymous] and -Tom-.
Which *looks* like a master.lib function, but only because ZUN adapted
his own micro-optimized super_roll_put_tiny() for 32×32. Good thing we
covered that one first!
Part of P0073, funded by [Anonymous] and -Tom-.
So, master.lib has:
• super_put_tiny() for tiny-format 16×n sprites
• super_roll_put_tiny() for vertically wrapped tiny-format 16×16
sprites
• super_put_tiny_small() for tiny-format 8×n sprites
• yet *no* super_roll_put_tiny_small() function
And now we have ZUN adding micro-optimized versions of:
1) vertically-wrapped tiny-format 16×16, clearly based on master.lib's
super_roll_put_tiny(), RE'd in 35f9bd7
2) vertically-wrapped tiny-format 32×32
3) vertically-wrapped non-tiny monochrome 16×16 (TH05 only)
Conclusion: Even though 1) does duplicate a master.lib function, trying
to continue following master.lib's inconsistent naming convention only
leads to more confusion here. master.lib also already designates the _8
suffix to mean "x will be byte-aligned, ⌊x/8⌋*8"…
So let's:
• spell out both coordinates of the sprite size directly in the
function
• keep the z_ prefix to encode ZUN's optimized calling convention
(left/top coordinates in registers, ES already set to the beginning
of a VRAM plane, GRCG already on) for all of these, not just 1).
• and prefix the actual functions with _raw, since C land will want
to handle the coordinate parameter registers in a macro.
Part of P0073, funded by [Anonymous] and -Tom-.
Which finally allows us to use the PLANE_SIZE macro in ASM land. Yeah,
(ROW_SIZE * RES_Y) has finally got old.
Part of P0073, funded by [Anonymous] and -Tom-.
And since everyone always cares about caps:
• TH04: 240 for the white 8×8 pellets, 220 for 16×16 sprites
• TH05: 180 for the white 8×8 pallets, 240 for 16×16 sprites
Completes P0072, funded by [Anonymous] and -Tom-.
夢時空.TXT calls this a "Gauge Power-Up", but that's both misleading
and too verbose, so let's go with how scoreplayers call it.
Part of P0071, funded by KirbyComment and -Tom-.
The _add function pointer is part of the 128-byte player structure,
that's why it's already named differently here 🙃
Part of P0071, funded by KirbyComment and -Tom-.
Yup, in the first 6 stages, the CPU always takes more damage per hit
than P1. 1½ hearts in stages 1 and 2, 1 heart in stages 3 and 4, and
½ heart in stages 5 and 6.
Part of P0071, funded by KirbyComment and -Tom-.
Probably going to refine those `pid_other` variables later; it almost
seems as if there's one to store the attacked player for every entity
type?
Part of P0070, funded by KirbyComment.
Little-endian BCD, again… Far less crazy than in TH04 and TH05,
though, thanks to updating and rendering being two different functions
here.
Part of P0070, funded by KirbyComment.
In which our typedefs mercilessly reveal ZUN's original sloppiness, and
the unncessary sign extension taking place here. Also, ❎ unused…
Completes P0069, funded by [Anonymous] and Yanga.
Yes, when clipping the start and end points to the screen area, ZUN
uses an integer division to calculate the line slopes, rather than a
floating-point one. Doesn't seem like it actually causes any incorrect
lines to be drawn, though; that case is only hit in the Mima boss
fight, which draws a few lines with a bottom coordinate of 400 rather
than 399. It *might* also restore the wrong pixels at parts of the
YuugenMagan fight, causing weird flickering, but seriously, that's an
issue everywhere you look in this game.
Part of P0069, funded by [Anonymous] and Yanga.
nmlgc