2019-09-15 17:36:17 +00:00
|
|
|
/* ReC98
|
|
|
|
* -----
|
|
|
|
* Types shared between TH04 and TH05
|
|
|
|
*/
|
|
|
|
|
|
|
|
/// Math
|
|
|
|
/// ----
|
|
|
|
class Subpixel {
|
|
|
|
private:
|
|
|
|
int v;
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
|
|
|
Subpixel& operator =(float screen_v) {
|
|
|
|
v = static_cast<int>(screen_v * 16.0f);
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
struct SPPoint {
|
|
|
|
Subpixel x, y;
|
|
|
|
|
|
|
|
void set(float screen_x, float screen_y) {
|
|
|
|
x = screen_x;
|
|
|
|
y = screen_y;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
SPPoint cur;
|
|
|
|
SPPoint prev;
|
|
|
|
SPPoint velocity;
|
|
|
|
|
|
|
|
void init(float screen_x, float screen_y) {
|
|
|
|
cur.x = screen_x;
|
|
|
|
prev.x = screen_x;
|
|
|
|
cur.y = screen_y;
|
|
|
|
prev.y = screen_y;
|
|
|
|
}
|
|
|
|
} motion_t;
|
|
|
|
/// ----
|
|
|
|
|
[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
|
|
|
|
);
|
|
|
|
/// ----
|
|
|
|
|
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"
|
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
|
|
|
|
2019-10-06 12:25:54 +00:00
|
|
|
/// Player
|
|
|
|
/// ------
|
2019-10-07 19:51:11 +00:00
|
|
|
#include "th04/player/player.h"
|
|
|
|
|
2019-10-06 12:25:54 +00:00
|
|
|
// Shots
|
|
|
|
// -----
|
|
|
|
// Sets [velocity] to a vector with the given [angle] and a 12-pixel length.
|
|
|
|
//
|
|
|
|
// TH05 also insists on setting shot_t::angle via a ridiculous out-of-bounds
|
|
|
|
// access, and therefore *must* be called with [velocity] pointing inside a
|
|
|
|
// shot_t structure!
|
|
|
|
SPPoint pascal near shot_velocity_set(
|
|
|
|
SPPoint near* velocity, unsigned char angle
|
|
|
|
);
|
|
|
|
// -----
|
|
|
|
/// ------
|
|
|
|
|
[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
|
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);
|
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
|
|
|
// ------
|
|
|
|
|
2019-09-15 17:36:17 +00:00
|
|
|
/// Score
|
|
|
|
/// -----
|
2019-09-18 16:33:38 +00:00
|
|
|
#define score_delta SCORE_DELTA
|
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);
|
|
|
|
/// -----
|