Adding op/, main/, and end/ directories does nicely cover a great
majority of the "not really further classifiable slices" implied in
d56bd45.
Part of P0086, funded by [Anonymous] and Blue Bolt.
Again, 11 necessary workarounds, vs. forcing byte aligment in at least
18 places, and that number would have significantly grown in the
future.
Part of P0085, funded by -Tom-.
5 enums where code generation wants an `int`, vs. 11 cases where using
the minimum size is exactly the right default. So it's way more
idiomatic to force those 5 to 16 bits via a dummy element… except that
we can't give it a single, consistent name, because you can't redeclare
the same element in a different enum later.
Oh well, let's have this ugly naming convention instead, which makes it
totally clear that the force element not, in fact, a valid value of
that enum.
Part of P0085, funded by -Tom-.
I tried `brge` for the latter, but that had *the* most horrible
ergonomics, and I misspelled it as `bgre` 100% of the times I typed it
manually. Turns out that `dots` is also consistent with master.lib's
naming scheme, leaving `planar` to *actually* refer to types storing
multiple planes worth of pixels. These types are showing up more and
more, and deserve something better than their previous long-winded and
misleading name.
Part of P0081, funded by Ember2528.
Which need to be separate from Mai's and Yuki's 32×32 balls because…
they have a delay cloud, whose radius absolutely has to be stored
redundantly, rather then deriving it from the [age]? Same for the decay
frame count. And the _update() function was copy-pasted from the knife
one…
Part of P0079, funded by -Tom-.
Heavily hardcoded for only two of them, even though there'd be space
for 65, even without position independence. Puppet army mod when?
Part of P0078, funded by iruleatgames and -Tom-.
On the surface, TH05 uses one single 26-byte structure for
• the Stage 2 starfield,
• Alice's puppets,
• curve bullet heads,
• Mai's snowballs and Yuki's fireballs,
• Yumeko's knives,
• and Shinki's 32×32 bullets.
But looking closer, it turns out that the fields of all these have very
different semantics, and in some cases, even different types. uth05win
treated all of those as distinct structures, and we're going to do the
same, merely overlaying the pointers onto the same generic array.
Part of P0078, funded by iruleatgames and -Tom-.
7 individually moving curve bullets × (16 trail points + 1 head point)
= 117 effective hitboxes. And yes, the game only renders half of them.
Part of P0078, funded by iruleatgames and -Tom-.
And with all possible .COM executables decompiled, this set of changes
reaches an acceptable scope, allowing us to *finally*…
Part of P0077, funded by Splashman and -Tom-.
And of course, TH05 ruins the consistency once again. Sure, the added
file error handling is nice, but we also have changes in the playful
messages (lol), and now need a third distinct optimization barrier
(🤦)… But as it turns out, inlined calls to empty functions work as
well. They also seem closer to what ZUN might have actually written
there, given that their function body could have been removed by the
preprocessor, similar to the logging functions in the Windows Touhou
games. (With the difference that the latter infamously *aren't*
inlined…)
Part of P0077, funded by Splashman and -Tom-.
The supposedly low-hanging fruit that almost every outside contributor
wanted to grab a lot earlier, but (of course) always just for a single
game… Comprehensively covering all of them has only started to make
sense recently 😛
Also, yes, the variable with the uppercase .CFG filename has itself a
lowercase name and vice versa…
Part of P0077, funded by Splashman and -Tom-.
Oh hey, guarding declarations with complicated types via #ifdef limits
the header files we additionally have to #include!
Part of P0076, funded by [Anonymous] and -Tom-.
Well… how else to call a variable that handles
• pellet vs. 16×16 sprite (TH04),
• the delay cloud flags from bullet_spawn_state_t, but with different
values (which is restricted to 16×16 sprites in TH04),
• optionally showing the gather animation before spawning the bullet
… whether the bullet uses the basic slowdown motion (TH05),
(which is restricted to pellets in TH04),
• and defining what happens *after* the gather animation – not actually
spawning any bullets (TH04), or using the special motion type from
the bullet template (TH05)
🤯
Completes P0075, funded by Myles and -Tom-.
uth05win TL note: "n-way all-around" means "ring"… yep, let's better
improve on the naming here, once again using established terminology
from Sparen's Danmaku Design Guide at
https://sparen.github.io/ph3tutorials/ddsga3.html
Since TH04 only supports rings *or* spreads *or* stacks, overloading
[delta] to store both spread angle and stack speed, that enum does
serve kind of a purpose in TH04. Unlike TH05, where it could be vastly
simplified to a bitfield with 4 flags: aim to player, randomize angle,
randomize speed, force single. Which could then actually create *more*
types of patterns than these uselessly defined 14 distinct types, all
of which can already be derived from the other values of the upcoming
template structure:
• Set [stack] to 1 if you don't want a stack
• Set [spread] to 1 if you don't want a spread
• Set [spread_delta_angle] to 0 to turn a N-way spread into a ring
Easy.
Part of P0075, funded by Myles and -Tom-.
Since they're determined by the order of sprites in a .BFT file,
they're best auto-generated by an enum as much as possible.
Part of P0074, funded by Myles.
Might as well cover this one while I've got this type of function in my
head. This one is used for the animated star backgrounds during Stage 2
and the Shinki battle.
Completes P0073, funded by [Anonymous] and -Tom-.
Which finally allows us to use the PLANE_SIZE macro in ASM land. Yeah,
(ROW_SIZE * RES_Y) has finally got old.
Part of P0073, funded by [Anonymous] and -Tom-.
WTF. Fine, let's have separate, micro-optimized ASM implementations for
decoding and encoding inr MAIN.EXE, but still, all those minute
difference between OP.EXE and MAINE.EXE…
This is as far as anyone should reasonably go before decompilation;
things will get really ugly with the loading functions once the file
name is involved as well…
Completes P0063, funded by -Tom-.
Funny how the actual scores are stored as little-endian gaiji strings
in the bold font, yet never actually used as such.
Part of P0063, funded by -Tom-.
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.
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
*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.
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
The pascal calling convention for TH03's input mode functions actually
sort of matters, since we have this nice function pointer type that
expects pascal.
Yeah… such fun pretending that the original code wasn't copy-pasted.
And yes, Reimu will have to wait until the next one.
Completes P0037, funded by zorg.
And if I don't manage to cover Reimu in this push, it's because ZUN
switched around the cases in half of the functions here… 😵 Here's
some macros instead, to make the code at least *look* as table-driven
and readable as it should have been in the first place.
Part of P0037, funded by zorg.
Ooh, shot position being determined by RNG at lower shot levels? That's
some RNG manipulation TAS potential right there! Maybe.
Part of P0037, funded by zorg.
That should make this convoluted copypasta a bit easier to read. And
sure, I could have done something about the loop as well, but
SHOT_FUNC_INIT already hides enough control flow behind a macro…
Part of P0037, funded by zorg.
A TH05 innovation that actually makes the game code easier to read?!
Although it was quite hard to actually reverse-engineer it, with the
confusing flag ordering pointing to some deeper meaning behind the
flags, which really doesn't exist.
Completes P0036, funded by zorg.
It seems that the main th0?/ directories should only contain actual
translation units (of which there are more than previously assumed)
as well as other not really further classifiable slices?
Part of P0036, funded by zorg.
And once again, the TH05 version is un-decompilable. :/ It was pretty
close this time, though, as the entire block between PUSH DI and POP DI
kind of resembles a separate inlined function, in accordance with Turbo
C++'s automatic backup of the DI register, as researched in 7f971a0.
Except that it contains a loop, and Turbo C++ refuses to inline any
function with `do`, `while`, `for`, or `goto`. If it didn't, it would
have totally worked.
Also, yes, C++ class methods are treated identically in this regard.
Oh well. Shot type control functions next, finally!
Completes P0035, funded by zorg.
Yes, if you collect more than 255 point items in one TH04 stage, the
counter will overflow to 0.
It's a 16-bit word in both TH02 and TH05.
Part of P0034, funded by zorg.
So it's *_put(), inherited from master.lib, for everything just writing
to text RAM, and *_render() for everything more involved? But what
about master.lib's own graphics RAM functions like super_put()? Need to
fix that inconsistency some day.
Once again no decompilation, because…
Part of P0033, funded by zorg.
The TH02 version is a piece of cake…
… but TH04 starts turning it into this un-decompilable piece of
unnecessarily micro-optimized ZUN code. Couldn't have chosen anything
better for the first separate ASM translation unit.
Aside from now having to convert names of exported *variables* to
uppercase for visibility in ASM translation units, the most notable
lesson in this was the one about avoiding fixup overflows. From the
Borland C++ Version 4.0 User's Guide:
"In an assembly language program, a fixup overflow frequently
occurs if you have declared an external variable within a
segment definition, but this variable actually exists in a
different segment."
Can't be restated often enough.
Completes P0032, funded by zorg.
Rule of thumb going forward: Everything that emits data is .asm,
everything that doesn't is .inc.
(Let's hope that th01_reiiden_2.inc won't exist for that much longer!)
Part of P0032, funded by zorg.
"Yeah, let's do this real quick, how can this possibly be hard, it's
just MOVs and a few function calls"…
…except that these MOVs access quite a lot of data, which we now all
have to declare in the C world, hooray.
Once it came to midbosses and bosses, I just turned them into C structs
after all. Despite what I said in 260edd8… after all, the ASM world
doesn't care about the representation in the C world, so they don't
necessarily have to be the same.
Since these structs can't contain everything related to midbosses and
bosses (really, why did all those variables have to be spread out like
this, ZUN?), it also made for a nice occasion to continue the "stuff"
naming scheme, describing "an obviously incomplete collection of
variables related to a thing", first seen in 160d4eb.
Also, PROCDESC apparently is the only syntactically correct option to
declare an extern near proc?
Also, that `boss_phase_timed_out` variable only needs to be here
already because TCC enforces word alignment for the .data segment…
yeah, it's technically not related to this commit, but why waste time
working around it if we can just include that one variable.
Completes P0030, funded by zorg.
I've had the idea to hide this implementation detail and improve code
readability for some time now, but it obviously must still all inline,
to be indistinguishable from a direct assignment of the correct value…
… which, amazingly, it does! Even the static_cast from float to int.
The latter allows us to exclusively implement this for float, since we
do have to express the occasional value smaller than 16.
Who needs macros anyway. Yay, C++ in TH04 and TH05 after all!
Part of P0030, funded by zorg.
… yeah, I don't really like these ambiguous "mode" and "mode change"
variable names either, but what's the alternative? Something something
"sub-phase", to distinguish them from regular phases? Feels way too
early to decide on something more specific. And pretty much nothing I
could come up with right now would have made their inconsistent use any
clearer.
But I need to decide on *something* before moving on, so… eh, let's
just go with what uth05win chose.
Also, yeah, dealing with those 0xFE and 0xFD boss_phase constants some
other time 😛
Also, today in "Weird TASM crashes": Trailing commas at the end of
`public` lines…
Completes P0028, funded by zorg.
Many thanks to http://bytepointer.com/tasm/index.htm for providing a
better searchable resource for TASM's default `LEA imm16` → `MOV imm16`
optimization, which we initially had to hack around here.
Funded by -Tom-.
So apparently, this way of distorting a circle into an ellipse (?) by
adding a value to the angle for one of the two coordinates isn't
actually widely known in math and doesn't have a name. Fair enough.
Funded by -Tom-.
Sure, I like me some global variables too. If you have to temporarily
replace them for a single function call though, it's pretty much the
textbook example of where *not* to use them.
Funded by -Tom-.
Yup, nothing interesting in here.
Except for maybe the confirmation that LS00.BB is used for the curved
bullets used by Shinki and EX-Alice?
Funded by -Tom-.
… because TH04's version of this takes the ASCII stage ID directly from
the resident structure.
So boss battles are simply triggered by setting the background tile
scroll speed to 0? That means…
Funded by zorg.
nmlgc