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

114 lines
2.2 KiB
C++
Raw Normal View History

[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
/* ReC98
* -----
* Types shared between TH04 and TH05
*/
/// Math
/// ----
[Maintenance] Move the Subpixel class to a separate header, under TH03 Part of P0061, funded by Touhou Patch Center.
2019-12-01 15:41:14 +00:00
#include "th03/math/subpixel.hpp"
[Maintenance] [th05] Minimize #includes for the shot type translation units 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.
2019-12-20 19:06:42 +00:00
#include "th04/math/motion.hpp"
[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-13 19:52:02 +00:00
#include "th03/math/randring.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
/// ----
[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
/// Rank
/// ----
int pascal far select_for_rank(
int for_easy, int for_normal,
int for_hard, int for_lunatic
);
/// ----
[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
/// -------
[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
#include "th03/formats/cdg.h"
[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
#include "th04/formats/bb.h"
/// -------
[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] 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-13 19:52:02 +00:00
/// Sound
/// -----
#include "th02/snd/snd.h"
/// -----
[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-06 12:25:54 +00:00
/// Player
/// ------
[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-07 19:51:11 +00:00
#include "th04/player/player.h"
[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-06 12:25:54 +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
/// Stages
/// ------
extern nearfunc_t_near stage_invalidate;
extern nearfunc_t_near stage_render;
/// ------
/// Midbosses
/// ---------
typedef struct {
motion_t pos;
unsigned int frames_until;
int hp;
unsigned char sprite;
unsigned char phase;
int phase_frame;
// Treated as a bool in TH04
unsigned char damage_this_frame;
unsigned char angle;
} midboss_stuff_t;
extern midboss_stuff_t midboss;
// Callbacks
extern farfunc_t_near midboss_update_func;
extern nearfunc_t_near midboss_render_func;
#define MIDBOSS_DEC(stage) \
void pascal far midboss##stage##_update(void); \
void pascal near midboss##stage##_render(void);
/// ---------
// Bosses
// ------
typedef struct {
motion_t pos;
int hp;
unsigned char sprite;
unsigned char phase;
int phase_frame;
unsigned char damage_this_frame;
unsigned char mode;
// Used for both movement and bullet angles.
unsigned char angle;
unsigned char mode_change;
int phase_end_hp;
} boss_stuff_t;
extern boss_stuff_t boss;
extern SPPoint boss_hitbox_radius;
// Callbacks
[Decompilation] [th05] Resetting boss-related variables Part of P0031, funded by zorg.
2019-09-16 12:07:37 +00:00
extern farfunc_t_near boss_update;
extern nearfunc_t_near boss_fg_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 farfunc_t_near boss_update_func;
extern nearfunc_t_near boss_backdrop_colorfill;
extern nearfunc_t_near boss_bg_render_func;
extern nearfunc_t_near boss_fg_render_func;
#define BOSS_DEC(name) \
void pascal far name##_update(void); \
void pascal near name##_bg_render(void); \
void pascal near name##_fg_render(void);
[Decompilation] [th05] Resetting boss-related variables Part of P0031, funded by zorg.
2019-09-16 12:07:37 +00:00
// Explosions
void pascal far explosions_small_reset(void);
[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] [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
/// Score
/// -----
[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-18 16:33:38 +00:00
#define score_delta SCORE_DELTA
[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
extern unsigned long score_delta;
void pascal near score_update_and_render(void);
// Adds the entire score delta at once to the current score.
void pascal score_delta_commit(void);
/// -----