• Comments that describe all lines of code until a blank one are placed
into the lines immediately above
• Comments that describe an entire demarcated block are placed
immediately below the dash row at the top
• In any case, there should be a blank line after the top comment of
a demarcated block, to keep IntelliSense-style systems from applying
the block comment to the first actual line of code…
• …but there shouldn't be one before the dash row at the bottom, where
it'd be redundant.
Part of P0207, funded by GhostPhanom.
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.
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.
The one where Elis fires 11 (yes, 11) evenly spaced lasers from her
left eye (?) across the whole playfield, from either the left or right
edge to the other one. First pattern you see in the fight.
Part of P0193, funded by Ember2528.
The single underscore version is actually slightly more supported among
the compilers I've seen so far. Also added the exact list now.
Part of P0183, funded by Yanga and [Anonymous].
So ZUN *did* want to clip those at the left and right edges of VRAM,
but accidentally tested the Y instead of the X coordinate 🎺
Part of P0121, funded by Yanga.
Which works in both Borland C++, Open Watcom, and Visual C++.
Not that we're about to port any of the games to these compilers, just
something I noticed while evaluating 32-bit compilers for ReC98's own
32-bit pipeline tools. Modders might want to look into that though,
since 100% position independence also makes it easier to change
compilers.
"Physics". Not only did ZUN restrict the X velocity to the 5 discrete
states of -8, -4, 0, 4, and 8 (because hey, unaligned blitting is slow
anyway?), but gravity is also only applied every 5 frames.
We're still missing quite a bit of usage code, but these are the core
functions. One of which turned out to be undecompilable, due to… a
rigorously defined instruction order when performing arithmetic between
`double`s and `float`s?! Still, spelling out all this stuff in ASM
seems much better than somehow splitting the data segment, just so that
we can immediately use literals there.
Part of P0097, funded by Ember2528.
nmlgc