Rooba
/
ReC98
mirror of https://github.com/nmlgc/ReC98.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity
ReC98/th05/th05.hpp

58 lines
1.1 KiB
C++
Raw Normal View History

[Decompilation] [th05] Committing the score delta Completes P0029, funded by zorg.
2019-09-14 14:41:16 +00:00
/* ReC98
* -----
* Include file for TH05
*/
#include "ReC98.h"
[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 17:36:17 +00:00
#include "th04/shared.hpp"
[Reverse-engineering] [th04/th05] Resident structure And yes, you can get it in your own tool by simply #including th04/th04.hpp or th05/th05.hpp. Completes P0065, funded by Touhou Patch Center.
2020-01-02 19:55:22 +00:00
#include "th05/resident.hpp"
[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
[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-16 11:01:53 +00:00
/// Formats
/// -------
bb_seg_t pascal near bb_load(const char far *fn);
/// -------
[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
/// Stages
/// ------
void pascal near stage2_update(void);
void pascal near stage2_invalidate(void);
/// ------
/// Midbosses
/// ---------
MIDBOSS_DEC(1);
MIDBOSS_DEC(2);
MIDBOSS_DEC(3);
MIDBOSS_DEC(4);
MIDBOSS_DEC(5);
MIDBOSS_DEC(x);
/// ---------
/// Bosses
/// ------
[Decompilation] [th05] Resetting boss-related variables Part of P0031, funded by zorg.
2019-09-16 12:07:37 +00:00
// Callbacks
extern nearfunc_t_near boss_custombullets_render;
[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
extern unsigned int boss_sprite_left;
extern unsigned int boss_sprite_right;
extern unsigned int boss_sprite_stay;
extern boss_stuff_t boss2;
BOSS_DEC(sara);
BOSS_DEC(louise);
BOSS_DEC(alice);
BOSS_DEC(mai_yuki);
// Pointing to the same address as `boss2`! Might not be possible anymore once
// that variable has to be moved to a C++ translation unit...
extern boss_stuff_t yuki;
BOSS_DEC(yumeko);
extern unsigned char yumeko_interval_phase4;
extern unsigned char yumeko_interval_phase7;
BOSS_DEC(shinki);
BOSS_DEC(exalice);
[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 17:36:17 +00:00
/// ------