Commit Graph

12 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 a84fa33beb [Reverse-engineering] [th04/th05] Player shot cycle counter
Part of P0036, funded by zorg.
2019-10-14 23:42:02 +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 5ebbe7bda9 [Maintenance] Move all shot-related slices to the player/ subdirectory
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.
2019-10-14 23:41:46 +02:00
nmlgc a533b5d3ea [Reverse-engineering] [th04/th05] Player sprite area invalidation
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.
2019-09-24 22:04:26 +02:00
nmlgc 290935fe3e [Reverse-engineering] [th04/th05] Player character display
Including options and the death explosions.

Part of P0035, funded by zorg.
2019-09-24 21:58:09 +02:00
nmlgc 6f1f36722f [Reverse-engineering] [th01/th02/th04/th05] Player invincibility frames
Completes P0034, funded by zorg.
2019-09-24 21:57:53 +02:00
nmlgc c77a9276d3 [Reverse-engineering] [th04/th05] Death-related variables
Including the confirmation that both games have an 8-frame deathbomb
window.
The placement of the variables is all over the place though, what the
hell?

Part of P0034, funded by zorg.
2019-09-24 21:57:46 +02:00
nmlgc 881f2c671e [Reverse-engineering] [th04/th05] Player option position
They are supposed to lag behind the player's movement by one frame, and
therefore have to be tracked separately.

I would have also included TH02, if it weren't for the weird sprite
indirection system (not storing X and Y positions directly in the
structure, but taking them from a buffer, with their addresses
always changing, WTF?!) that absolutely needs separate attention.

Part of P0034, funded by zorg.
2019-09-24 21:57:35 +02:00
nmlgc b7d204aeec [Reverse-engineering] [th02/th04/th05] Player option sprite number
Part of P0034, funded by zorg.
2019-09-24 21:57:29 +02:00
nmlgc 6cdd2296bb [Reverse-engineering] [th04/th05] Input → player movement
Completes P0033, funded by zorg.
2019-09-21 14:01:51 +02:00