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 .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.
Common sense: Entity backgrounds always go into slot X, missile sprites
into slot Y, and wave sprites into slot Z
ZUN: "Nah, let's set aside two slots, and bosses can just freely use
them as they want 🎺"
Part of P0165, funded by Ember2528.
Functions with 12 parameters are hard to describe, y'know. Looking
forward to decompiling these giant expressions for the actual
boss↔orb collision parameter passed to this function…
Oh well, at least we're now totally ready for some boss code next
year. 😌
Completes P0131, funded by Yanga.
And we're right back to things not being nice. Because yeah, why
shouldn't these three distinct rendering functions be part of a single
function, selected by magic numbers?
Or why shouldn't the 16×16 wrapper around a 32×32 set of graphics
functions be used to handle backgrounds for 16×8 sprites, resulting in
needlessly complex parameter calculations that lead to sloppy code?
Part of P0131, funded by Yanga.
nmlgc