Even that part's the same in these three games… except for the 27 small
places where it isn't, 7 of which are purely coding style cosmetics.
Completes P0224, funded by Splashman and -Tom-.
The later games need this constant for their buffers as well, and it's
not just needed for loading sound files. Might be overkill to force all
of `master.hpp` to be #included in some additional places, but the
alternative would have been to move it to a `fn_len.hpp` file.
Ultimately, this constant *is* related to master.lib.
Part of P0223, funded by Blue Bolt and rosenrose.
• 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.
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.
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.
Looking back at the MAG.Net footage, that out-of-focus block of pixels
is clearly separated from the opening parenthesis with an `l`, with the
second word alone making up four monospaced ASCII characters. `Execl`
is also a much more descriptive name, given what the function does.
Part of P0192, funded by [Anonymous], nrook, and -Tom-.
The one where Shinki spawns her wings, which fire 50 quick random
bullets as soon as they appear. Featuring the first reliance on a piece
of state set by an earlier boss, which technically affects gameplay!
Part of P0190, funded by nrook.
Less fancy token pasting, replacing them with inline functions where
possible, entirely removing unnecessary ones, and fixing smaller
issues here and there.
Part of P0186, funded by [Anonymous] and Blue Bolt.
If the macro itself is local to a function, these can work in certain
scenarios, but never for global ones.
Part of P0186, funded by [Anonymous] and Blue Bolt.
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].
Most notably from `th01/core/str_val`, where it's really in the way.
That mistake will haunt me until this all is done, probably…
Part of P0158, funded by Yanga.
… (24 + (difficulty * 8) + rank) in TH04, and (42 + (difficulty * 8))
in TH05. Also, TH05 only doesn't have TH04's bullet zap animation
because ZUN didn't consistently use constants…
Completes P0151, funded by Blue Bolt and -Tom-.
First place to confirm the hitbox of both the 8×8 pellets and the 16×16
sprite bullets!
Well, "hitbox". It's really more of a kill delta of 8×8 pixels between
the center points of a bullet and the player. You can distribute these
pixels to any combination of bullet and player "hitboxes" that make up
8×8. 4×4 around both the player and bullets? 1×1 for bullets, and 8×8
for the player? All equally valid… or perhaps none of them, once you
keep in mind that other entity types might have different kill deltas,
which turns the concept of a "hitbox" into just a confusing abstraction.
Part of P0150, funded by Blue Bolt.
motion_t is also used for certain animations in MAINE.EXE, so not all
instances refer to entities in playfield space. Explicitly specifying
the latter now allows us to gain…
Part of P0149, funded by Blue Bolt, Ember2528, and -Tom-.
Will make it easier to comprehend that the bullet update function is
actually correct with regards to only looking at a single variable.
(Yes, I know, hard to believe!)
Part of P0149, funded by Blue Bolt, Ember2528, and -Tom-.
Boom! Decompilable after all. And look what that made us finally point
out: In all 4 games that use this function, its return value is
undefined if BGM is inactive. (That is, if the user disabled it, or if
no FM sound board is installed.)
Part of P0148, funded by [Anonymous].
… Wait, we *can* decompile functions with both parameters, no stack
frame, and a Pascal calling convention?! Good that I already forgot how
impossible it was to decompile the first function I looked at that fell
into this category!
Part of P0148, funded by [Anonymous].
The bullet update function really needs this one declared in C land to
link without a fixup overflow? Guess we'll have another technical debt
push before then…
Part of P0148, funded by [Anonymous].
nmlgc