You know that things are complicated when you have to resort to Unicode
box drawing character art to explain how two hitboxes relate to each
other. I *hope* this makes enough sense, and that I won't be rewriting
this in terms of ORB_W and ORB_H after all in the future. For now
though, it's immediately obvious when the hitbox reaches outside the
entity. In the case of YuugenMagan, it even simplifies the coordinates
so much that we don't need separate constants.
Part of P0205, funded by [Anonymous] and Yanga.
The flag that blocks collision handling for vertical bars might prevent
some of the potential glitches here, but definitely not all of them.
Thanks to touhou-memories for bringing this to my attention, this was
indeed a glaring omission.
The fact that the game insists on this translation unit is already bad
enough – thanks to the static constructor for the CCards and CObstacles
instances, we can't merge it with segment 31. Just `#include`ing
str_val.cpp here is much less bad than having more than one extra
source file.
Part of P0204, funded by [Anonymous] and Yanga.
The nondescript nature of `core/` has been annoying me for a while, and
these function kind of are number-related after all.
Part of P0204, funded by [Anonymous] and Yanga.
In which ZUN needs a hack to make columns of vertical bumper bars work
at all with the way the Orb's X velocity is implemented… and may have
just deliberately ensured that the Orb can definitely loop infinitely
between two bumpers.
(Those two wrong NOPCALLs aren't worth working around. It would
basically require taking apart the entire function, and they'll be gone
by the next two commits anyway.)
Part of P0203, funded by [Anonymous] and GhostRiderCog.
All throughout this codebase, `X_put_8()` implies that just the single
sprite of X is blitted on top of whatever is in VRAM at the given
position. This function blits more than one sprite though. (Also,
portal rendering is going to introduce a helper function that does only
blit a single thing.)
Part of P0203, funded by [Anonymous] and GhostRiderCog.
The fact that it's only mutated internally by applying a force on the
Orb is going to become very relevant.
Part of P0203, funded by [Anonymous] and GhostRiderCog.
It's been highly useful for debug output at specific screen positions
for a number of times now.
Part of P0203, funded by [Anonymous] and GhostRiderCog.
Let's see if anyone ever tries to compile this codebase with a pre-C89
compiler that enforces the # at the beginning of the line.
Part of P0203, funded by [Anonymous] and GhostRiderCog.
Then again, this more flexible architecture points towards SinGyoku's
male form potentially having had way more varied patterns earlier in
development… or planned, but never realized.
Part of P0202, funded by [Anonymous] and Yanga.
The one where SinGyoku's male form fires 3 sets of 10 aimed sling
pellets from random locations within its sprite.
Part of P0202, funded by [Anonymous] and Yanga.
Complete with callback function parameters that are completely ignored
by SinGyoku's female-form patterns. That's all the entity
synchronization code in this fight though?! Nice.
Part of P0202, funded by [Anonymous] and Yanga.
The one where SinGyoku slams their sphere form into Reimu and then
returns to not quite its base Y coordinate.
One big collidable object == technically a pattern, right?
(90 functions remaining in TH01!)
Completes P0201, funded by Ember2528 and Yanga.
The one where SinGyoku's sphere form sprays a half-circle of pellets
at static downwards angles, randomly selecting either a direction from
right to left or from left to right. First pattern you see in the
fight, and the only pellet pattern in phase 1.
Part of P0201, funded by Ember2528 and Yanga.
With 3 ZUN bugs, this one small function is technically buggier than
the entirety of Kikuri… or at least *as* buggy, with only two of them
being visible in the original game.
Oh well, that's 80% of REIIDEN.EXE RE'd!
Part of P0201, funded by Ember2528 and Yanga.
The .PTN functions, vector functions, and egc_copy_rect_1_to_0_1()
(finally!) from TH01, as well as playfld.hpp from all games(finally!),
together with a bunch of other functions in their vicinity.
Part of P0201, funded by Ember2528 and Yanga.
Nobody cares about preserving perfect semantics across a macro whose
only job is to worsen code generation on one specific compiler. And
even aside from semantics, signedness would be the only difference that
types would make, and parameter passing couldn't care less about it.
Part of P0201, funded by Ember2528 and Yanga.
Noooo, SinGyoku will in fact prove the existence of this getter method
via the given code generation detail. Might as well go fully consistent
then and exclusively use the methods, ending the previous party time.
Part of P0201, funded by Ember2528 and Yanga.
nmlgc