Since a few annoying alignment bytes suggested more translation units
than previously expected, using many small headers has proved to be
better than one big shared TH04/TH05 header file. Or should we *really*
pepper the code with lots of `#pragma codestring`? 😛
And in case we have multiple translation units which all #include the
same set of headers, we'll just go with situational shared headers,
using a common prefix.
Part of P0062, funded by Touhou Patch Center.
Should have remembered this from all the times I've looked at the list
of #pragma directives supported by Turbo C++… Still, I would have at
least expected a warning, but not even the `ill` warning covers this.
Part of P0062, funded by Touhou Patch Center.
As used for the title screen fade-in effect. Another function that
apparently was deliberately written to run not that fast, by blitting
each row individually to the 400th VRAM row just so that it can then
turn on the EGC, perform the *actual* masked blit to the VRAM
destination, and then turn the EGC off before moving to the next now.
The same effect could have entirely been accomplished by copying
graph_pack_put_8() and applying the mask there; it's not like ZUN
didn't know how to modify master.lib…
(See also 44ad3eb4) --Nmlgc
At least wherever Turbo C++ and master.lib want us to use a
non-pointer, since both use uint16_t for segment values throughout
their APIs instead of the more sensible void __seg*. Maybe, integer
arithmetic on segment values was widely considered more important than
dereferencing?
*Finally*. We already used `(unsigned) int` in quite a few places where
we actually want a 16-bit value, which was bound to annoy future port
developers.
"bgimage" really was the best name I could come up with here, given
what it's used for. Everything else sounded way too ambiguous. Even
something like "mempage", in the meaning of "a third memory-backed
graphics page"… --Nmlgc
I think cmt_back_* type functions need more universal name
Because at th04 and th05, it used in zunsoft opening animation
--WindowsTiger
And in MAINE.EXE. So I agree for TH04 and TH05, but TH03 still only
allocates, snaps, and recovers only the VRAM area occupied by the music
comments. --Nmlgc
No need to declare most of these in C land if 1) it isn't even clear
yet whether we can even decompile these functions with their 2)
complex __usercall conventions, which 3) aren't even called from
outside this slice. --Nmlgc
Meh, can't overload arithmetic operators that take a Subpixel without
generating a needless load and store, even with -Z. But heck, slightly
uglifying subpixel/subpixel arithmetic is exactly the right trade-off.
Completes P0061, funded by Touhou Patch Center.
nmlgc