2020-08-21 18:13:08 +00:00
|
|
|
static const pixel_t ORB_W = 32;
|
|
|
|
static const pixel_t ORB_H = 32;
|
2020-06-08 15:31:16 +00:00
|
|
|
|
2020-08-20 19:59:45 +00:00
|
|
|
static const screen_x_t ORB_LEFT_MIN = (PLAYFIELD_LEFT);
|
|
|
|
static const screen_x_t ORB_LEFT_MAX = (PLAYFIELD_RIGHT - ORB_W);
|
|
|
|
static const screen_y_t ORB_TOP_MIN = (PLAYFIELD_TOP);
|
|
|
|
static const screen_y_t ORB_TOP_MAX = (PLAYFIELD_BOTTOM - ORB_H);
|
2020-06-08 15:31:16 +00:00
|
|
|
|
2020-08-20 19:59:45 +00:00
|
|
|
static const screen_x_t ORB_LEFT_START = (ORB_LEFT_MAX - 8);
|
|
|
|
static const screen_y_t ORB_TOP_START = ( ORB_TOP_MAX - 88);
|
2020-06-08 15:31:16 +00:00
|
|
|
|
2020-08-20 19:59:45 +00:00
|
|
|
extern screen_x_t orb_cur_left;
|
|
|
|
extern screen_y_t orb_cur_top;
|
|
|
|
extern screen_x_t orb_prev_left;
|
|
|
|
extern screen_y_t orb_prev_top;
|
2020-06-10 08:54:40 +00:00
|
|
|
extern bool16 orb_in_portal;
|
[Decompilation] [th01] Orb physics
"Physics". Not only did ZUN restrict the X velocity to the 5 discrete
states of -8, -4, 0, 4, and 8 (because hey, unaligned blitting is slow
anyway?), but gravity is also only applied every 5 frames.
We're still missing quite a bit of usage code, but these are the core
functions. One of which turned out to be undecompilable, due to… a
rigorously defined instruction order when performing arithmetic between
`double`s and `float`s?! Still, spelling out all this stuff in ASM
seems much better than somehow splitting the data segment, just so that
we can immediately use literals there.
Part of P0097, funded by Ember2528.
2020-06-09 18:39:44 +00:00
|
|
|
|
|
|
|
/// Physics
|
|
|
|
/// -------
|
|
|
|
enum orb_velocity_x_t {
|
|
|
|
OVX_0 = 0,
|
|
|
|
OVX_4_LEFT = 1,
|
|
|
|
OVX_4_RIGHT = 2,
|
|
|
|
OVX_8_LEFT = 3,
|
|
|
|
OVX_8_RIGHT = 4,
|
2021-10-02 17:25:13 +00:00
|
|
|
|
|
|
|
_orb_velocity_x_t_FORCE_INT16 = 0x7FFF
|
[Decompilation] [th01] Orb physics
"Physics". Not only did ZUN restrict the X velocity to the 5 discrete
states of -8, -4, 0, 4, and 8 (because hey, unaligned blitting is slow
anyway?), but gravity is also only applied every 5 frames.
We're still missing quite a bit of usage code, but these are the core
functions. One of which turned out to be undecompilable, due to… a
rigorously defined instruction order when performing arithmetic between
`double`s and `float`s?! Still, spelling out all this stuff in ASM
seems much better than somehow splitting the data segment, just so that
we can immediately use literals there.
Part of P0097, funded by Ember2528.
2020-06-09 18:39:44 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
enum orb_force_t {
|
|
|
|
OF_BOUNCE_FROM_GROUND = 0,
|
|
|
|
OF_BOUNCE_FROM_TOP = 1,
|
|
|
|
OF_SHOT = 2,
|
|
|
|
OF_IMMEDIATE = 3, // new force passed directly in [immediate]
|
2021-10-02 17:25:13 +00:00
|
|
|
|
|
|
|
_orb_force_t_FORCE_INT16 = 0x7FFF
|
[Decompilation] [th01] Orb physics
"Physics". Not only did ZUN restrict the X velocity to the 5 discrete
states of -8, -4, 0, 4, and 8 (because hey, unaligned blitting is slow
anyway?), but gravity is also only applied every 5 frames.
We're still missing quite a bit of usage code, but these are the core
functions. One of which turned out to be undecompilable, due to… a
rigorously defined instruction order when performing arithmetic between
`double`s and `float`s?! Still, spelling out all this stuff in ASM
seems much better than somehow splitting the data segment, just so that
we can immediately use literals there.
Part of P0097, funded by Ember2528.
2020-06-09 18:39:44 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
// Initial value of the current force acting on the orb
|
|
|
|
extern double orb_force;
|
|
|
|
|
|
|
|
// Number of frames that [orb_force] has been acting on the orb
|
|
|
|
extern int orb_force_frame;
|
|
|
|
|
|
|
|
extern orb_velocity_x_t orb_velocity_x;
|
|
|
|
extern double orb_velocity_y;
|
|
|
|
|
|
|
|
// Applies a new force of the given type onto the orb. Sets [orb_force], and
|
2020-06-18 18:01:29 +00:00
|
|
|
// resets [orb_force_frame].
|
[Decompilation] [th01] Orb physics
"Physics". Not only did ZUN restrict the X velocity to the 5 discrete
states of -8, -4, 0, 4, and 8 (because hey, unaligned blitting is slow
anyway?), but gravity is also only applied every 5 frames.
We're still missing quite a bit of usage code, but these are the core
functions. One of which turned out to be undecompilable, due to… a
rigorously defined instruction order when performing arithmetic between
`double`s and `float`s?! Still, spelling out all this stuff in ASM
seems much better than somehow splitting the data segment, just so that
we can immediately use literals there.
Part of P0097, funded by Ember2528.
2020-06-09 18:39:44 +00:00
|
|
|
void orb_force_new(double immediate, orb_force_t force);
|
|
|
|
|
|
|
|
// Updates [orb_velocity_y] with the currently active force, and returns the
|
|
|
|
// orb's velocity for this frame, in pixels to be added to [orb_cur_top].
|
|
|
|
int orb_velocity_y_update(void);
|
|
|
|
|
2020-06-18 18:01:29 +00:00
|
|
|
// Updates [orb_cur_left] depending on the passed [velocity_x], *as well as*
|
|
|
|
// the global [orb_velocity_x] (!) to bounce the orb off the left or right
|
|
|
|
// edge of the playfield, if necessary.
|
[Decompilation] [th01] Orb physics
"Physics". Not only did ZUN restrict the X velocity to the 5 discrete
states of -8, -4, 0, 4, and 8 (because hey, unaligned blitting is slow
anyway?), but gravity is also only applied every 5 frames.
We're still missing quite a bit of usage code, but these are the core
functions. One of which turned out to be undecompilable, due to… a
rigorously defined instruction order when performing arithmetic between
`double`s and `float`s?! Still, spelling out all this stuff in ASM
seems much better than somehow splitting the data segment, just so that
we can immediately use literals there.
Part of P0097, funded by Ember2528.
2020-06-09 18:39:44 +00:00
|
|
|
void orb_move_x(orb_velocity_x_t velocity_x);
|
|
|
|
/// -------
|