Rooba
/
ReC98
mirror of https://github.com/nmlgc/ReC98.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity
ReC98/th05/main/boss/vars2[bss].asm

45 lines
1.1 KiB
NASM
Raw Normal View History

[Reverse-engineering] [th05] Secondary boss position and sprite ID 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-.
2019-03-01 12:08:45 +00:00
; Variables for the secondary on-screen boss. Used for Yuki in the first part
; of the Stage 4 boss fight, for Shinki's leave animation at the beginning of
; the Stage 5 boss fight, and, weirdly enough, for the knife launch position
; in Phase 8 of the same fight.
[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 18:14:00 +00:00
public _boss2, _yuki
[Reverse-engineering] [th04/th05] Remaining generic boss variables … 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.
2019-09-11 20:05:49 +00:00
public _boss2_pos, _boss2_hp, _boss2_sprite, _boss2_phase, _boss2_phase_frame
public _yuki_pos, _yuki_hp, _yuki_sprite, _yuki_phase, _yuki_phase_frame
public _boss2_damage_this_frame, _boss2_mode, _boss2_angle, _boss2_mode_change
public _yuki_damage_this_frame, _yuki_mode, _yuki_angle, _yuki_mode_change
public _boss2_phase_end_hp
public _yuki_phase_end_hp
[Reverse-engineering] [th05] Secondary boss position and sprite ID 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-.
2019-03-01 12:08:45 +00:00
[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 18:14:00 +00:00
label _boss2 byte
label _yuki byte
[Reverse-engineering] [th05] Secondary boss position and sprite ID 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-.
2019-03-01 12:08:45 +00:00
label _yuki_pos motion_t
_boss2_pos motion_t <?>
label _yuki_hp word
_boss2_hp dw ?
label _yuki_sprite byte
_boss2_sprite db ?
[Reverse-engineering] [th04/th05] Remaining generic boss variables … 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.
2019-09-11 20:05:49 +00:00
label _yuki_phase byte
_boss2_phase db ?
label _yuki_phase_frame word
_boss2_phase_frame dw ?
label _yuki_damage_this_frame byte
_boss2_damage_this_frame db ?
label _yuki_mode byte
_boss2_mode db ?
label _yuki_angle byte
_boss2_angle db ?
label _yuki_mode_change byte
_boss2_mode_change db ?
label _yuki_phase_end_hp word
_boss2_phase_end_hp dw ?