Commit Graph

9 Commits

Author SHA1 Message Date
nmlgc db4de240e9 [Decompilation] Prepare the C side for the shot type control functions
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.
2019-10-14 23:42:20 +02:00
nmlgc f33a3ef220 [Maintenance] [th04/th05] Separate constant for the player↔option distance
Used in pretty much all shot type control functions.

Part of P0036, funded by zorg.
2019-10-14 23:41:57 +02:00
nmlgc b801d24a34 [Reverse-engineering] [th04/th05] Setting the player shot velocity
The TH05 difference: A ridiculous out-of-bounds structure field access.
Could have done safely by just passing a shot_t*, but ZUN's too cool
for that?

Also, about time we started putting the function prototypes directly
into the C headers, and the C headers *only*, upon reverse-engineering…

Part of P0036, funded by zorg.
2019-10-14 23:41:52 +02:00
nmlgc 0b542125a5 [Decompilation] [th04/th05] Remove the Subpixel constructors
They just create unnecessary code when passing Subpixels by value to
functions.

Part of P0034, funded by zorg.
2019-09-24 21:57:23 +02:00
nmlgc e6294c2c1a [Reverse-engineering] [th02/th04/th05] Score update and display
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.
2019-09-21 14:01:47 +02:00
nmlgc 3383a4558b [Decompilation] [th05] Resetting boss-related variables
Part of P0031, funded by zorg.
2019-09-21 13:01:30 +02:00
nmlgc b0c2122eec [Decompilation] [th05] Stage-related .BB file loading boilerplate
Yay for alignment, allowing us once again to only move unrelated
variable declarations over to C…

Part of P0031, funded by zorg.
2019-09-21 12:59:22 +02:00
nmlgc dea40ad770 [Decompilation] [th05] Stage setup
"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.
2019-09-15 20:35:15 +02:00
nmlgc 9d121c7cce [Decompilation] [th04/th05] Handle subpixels at the C++ type level
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.
2019-09-15 20:30:35 +02:00