These could have been nicely separated into per-device translations
(one for GDC, one for EGC, one for regular VRAM accesses)… if their
original order followed that classification.
OK, so let's make it one full `graph_ex.cpp` translation unit… nope,
FUUIN.EXE needs graph_2xscale_byterect_1_to_0_slow() with different
compilation flags. 🤦
Whatever, fuck it, let's go for individual translation units, with
individual headers, so that we at least get predictably organized
source code out of this.
Part of P0196, funded by Yanga.
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.
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.
*Still* no need for the classic `if(ptr) { delete[] ptr; ptr = NULL }`
macro, because who cares about dangling pointers anyway, right?
:zunpet:
Part of P0123, funded by Yanga.
All this CPU time spent optimizing the unblitting mask, yet the code
still ends up glitching if the two sprites are more than 2 horizontal
bytes away. So, Reimu's slide speed can only be as high as 8 pixels per
frame, before this function fails to unblit the previous sprite and
leaves little Reimu parts in VRAM.
Part of P0123, funded by Yanga.
"Let's add a row to the offset, and then subtract it again" :zunpet:
This could only *possibly* have been intended as a DoS attack against a
future manual decompilation, right?
Part of P0123, funded by Yanga.
nmlgc