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

342 lines
7.8 KiB
C
Raw Normal View History

[C decompilation] [th02/op] Music Room Yes, all of it. Including the bouncing polygons, of course. And since it's placed at the end of ZUN's code inside the executable, the code's already position-independent and fully hackable.
2015-02-24 14:45:38 +00:00
/* ReC98
* -----
* Code segment #6 of TH02's OP.EXE
*/
#include "th02\th02.h"
[Maintenance] Clean up PI function declarations and comments
2019-12-15 19:17:00 +00:00
#include "th02/formats/pi.h"
[C decompilation] [th02/op] Music Room Yes, all of it. Including the bouncing polygons, of course. And since it's placed at the end of ZUN's code inside the executable, the code's already position-independent and fully hackable.
2015-02-24 14:45:38 +00:00
#define TRACK_COUNT sizeof(MUSIC_FILES) / sizeof(MUSIC_FILES[0])
#define SEL_QUIT TRACK_COUNT + 1
#define MUSIC_POLYGONS 16
const char *MUSIC_TITLES[] = {
"NO.1 <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>^<5E>@<40>`<60><><EFBFBD>y<EFBFBD><79>䶗<EFBFBD>",
"NO.2 <20>@ <20><><EFBFBD><EFBFBD><EFBFBD>@<40>`Eastern Wind ",
"NO.3 <20>@ End of Daylight<68>@ ",
"NO.4 <20>@<40>@<40>@<40>@<40>@<40><><EFBFBD><EFBFBD><EFBFBD>E<EFBFBD>@<40>@<40>@<40>@",
"NO.5 <20>Ђ<EFBFBD><D082>났<EFBFBD>A<EFBFBD>ނ炳<DE82><E782B3><EFBFBD>ɂ<EFBFBD><C982><EFBFBD>",
"NO.6 <20>@<40><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>^<5E>@<40>`<60>H<EFBFBD><48><EFBFBD><EFBFBD><EFBFBD><EFBFBD>",
"NO.7 <20>@ She's in a temper!! ",
"NO.8 <20>@ <20>@ <20><><EFBFBD>݂̂<DD82><CC82><EFBFBD><EFBFBD><EFBFBD><EFBFBD>@<40>@ ",
"NO.9 <20>@<40>@<40>@<40>@<40><><EFBFBD><EFBFBD><EFBFBD>q<EFBFBD><71><EFBFBD>ā@<40>@<40>@",
"NO.10 <20>@ <20>@ <20><><EFBFBD>F<EFBFBD>}<7D>W<EFBFBD>b<EFBFBD>N <20>@ ",
"NO.11 Complete Darkness ",
"NO.12 <20>@<40>@<40><><EFBFBD><EFBFBD><EFBFBD>̐X<CC90>@<40>@<40>@ ",
"NO.13 <20>̘b<CC98><62><EFBFBD>񂾁[<5B><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> ",
"NO.14 <20>@ <20>G<EFBFBD>L<EFBFBD>X<EFBFBD>g<EFBFBD><67><EFBFBD><EFBFBD><EFBFBD>u ",
"NO.15 <20><><EFBFBD>Ԃނ<D482><DE82>߂݂̂<CC82><DD82><EFBFBD><EFBFBD><EFBFBD> ",
" <20>@<40>@ ",
" <20>@<40>@<40>p<EFBFBD><70><EFBFBD><EFBFBD><EFBFBD><EFBFBD> "
};
const char *MUSIC_FILES[] = {
"op.m",
"stage0.m",
"stage1.m",
"stage2.m",
"stage3.m",
"stage4.m",
"boss1.m",
"boss4.m",
"boss2.m",
"boss3.m",
"mima.m",
"end1.m",
"ending.m",
"stage5.m",
"boss5.m"
};
unsigned char music_sel;
unsigned char music_page;
char *screen_back_B;
char *cmt_back[PL_COUNT];
void pascal near draw_track(unsigned char sel, unsigned char color)
{
unsigned char other_page = 1 - music_page;
graph_accesspage(other_page);
[C decompilation] [th02] Code segment #2 of all three executables Only one code segment left in both OP and FUUIN! its-happening.gif Yeah, that commit is way larger than I'm comfortable with, but none of these functions is particularly large or difficult to decompile (with the exception of graph_putsa_fx(), which I actually did weeks ago), and OP and MAIN have their own unique functions in between the shared ones, so…
2015-03-14 22:25:50 +00:00
graph_putsa_fx(16, (sel + 6) * 16, FX(color, 2, 0), MUSIC_TITLES[sel]);
[C decompilation] [th02/op] Music Room Yes, all of it. Including the bouncing polygons, of course. And since it's placed at the end of ZUN's code inside the executable, the code's already position-independent and fully hackable.
2015-02-24 14:45:38 +00:00
graph_accesspage(music_page);
[C decompilation] [th02] Code segment #2 of all three executables Only one code segment left in both OP and FUUIN! its-happening.gif Yeah, that commit is way larger than I'm comfortable with, but none of these functions is particularly large or difficult to decompile (with the exception of graph_putsa_fx(), which I actually did weeks ago), and OP and MAIN have their own unique functions in between the shared ones, so…
2015-03-14 22:25:50 +00:00
graph_putsa_fx(16, (sel + 6) * 16, FX(color, 2, 0), MUSIC_TITLES[sel]);
[C decompilation] [th02/op] Music Room Yes, all of it. Including the bouncing polygons, of course. And since it's placed at the end of ZUN's code inside the executable, the code's already position-independent and fully hackable.
2015-02-24 14:45:38 +00:00
}
void pascal near draw_tracks(unsigned char sel)
{
int i;
for(i = 0; i < sizeof(MUSIC_TITLES) / sizeof(MUSIC_TITLES[0]); i++) {
draw_track(i, i == sel ? 15 : 3);
}
}
void pascal near screen_back_B_snap(void)
{
int p;
screen_back_B = MK_FP(hmem_allocbyte(PLANE_SIZE), 0);
PLANE_DWORD_BLIT(screen_back_B, VRAM_PLANE_B);
}
void pascal near screen_back_B_free(void)
{
hmem_free(FP_SEG(screen_back_B));
}
void pascal near screen_back_B_put(void)
{
int p;
PLANE_DWORD_BLIT(VRAM_PLANE_B, screen_back_B);
}
void pascal near polygon_build(Point near *pts, int x, int y, int rad, int npoint, char angle)
{
int i;
y >>= 4;
for(i = 0; i < npoint; i++) {
unsigned char point_angle = ((i << 8) / npoint) + angle;
pts[i].x = ((rad * (long)CosTable8[point_angle]) >> 8) + x;
pts[i].y = ((rad * (long)SinTable8[point_angle]) >> 8) + y;
}
pts[i].x = pts[0].x;
pts[i].y = pts[0].y;
}
void pascal near polygons_update_and_render(void)
{
#define VERTICES(i) (i / 4) + 3
[Maintenance] Fix any whitespace issues in our own code
2015-09-07 13:44:02 +00:00
[C decompilation] [th02/op] Music Room Yes, all of it. Including the bouncing polygons, of course. And since it's placed at the end of ZUN's code inside the executable, the code's already position-independent and fully hackable.
2015-02-24 14:45:38 +00:00
#define POLYGON_INIT_PART2 \
if(move_speed[i].x == 0) { \
move_speed[i].x = 1; \
} \
move_speed[i].y = ((rand() & 3) << 4) + 32; \
angle[i] = rand(); \
rot_speed[i] = 4 - (rand() & 7); \
if(rot_speed[i] == 0) { \
rot_speed[i] = 4; \
}
[Maintenance] Fix any whitespace issues in our own code
2015-09-07 13:44:02 +00:00
[C decompilation] [th02/op] Music Room Yes, all of it. Including the bouncing polygons, of course. And since it's placed at the end of ZUN's code inside the executable, the code's already position-independent and fully hackable.
2015-02-24 14:45:38 +00:00
static char initialized = 0;
static Point points[10];
static Point pos[MUSIC_POLYGONS];
static Point move_speed[MUSIC_POLYGONS];
static char angle[MUSIC_POLYGONS];
static char rot_speed[MUSIC_POLYGONS];
int i;
if(!initialized) {
for(i = 0; i < MUSIC_POLYGONS; i++) {
pos[i].x = rand() % 640;
pos[i].y = rand() % (400 * 16);
move_speed[i].x = 4 - (rand() & 7);
POLYGON_INIT_PART2;
}
initialized = 1;
}
for(i = 0; i < MUSIC_POLYGONS; i++) {
polygon_build(
points, pos[i].x, pos[i].y,
((i & 3) << 4) + 64, VERTICES(i), angle[i]
);
pos[i].x += move_speed[i].x;
pos[i].y += move_speed[i].y;
angle[i] += rot_speed[i];
if(pos[i].x <= 0 || pos[i].x >= 639) {
move_speed[i].x *= -1;
}
if(pos[i].y >= (400 * 20)) {
pos[i].x = rand() % 640;
pos[i].y = -1600;
move_speed[i].x = 8 - (rand() & 15);
POLYGON_INIT_PART2;
}
grcg_polygon_c(points, VERTICES(i));
}
}
void pascal near music_flip(void)
{
screen_back_B_put();
grcg_setcolor(GC_RMW | GC_B, 15);
polygons_update_and_render();
grcg_off();
graph_showpage(music_page);
music_page = 1 - music_page;
graph_accesspage(music_page);
frame_delay(1);
}
#define CMT_BACK_BLIT(dst, dp, src, sp) \
ps = 0; \
for(y = 64; y < 80; y++) { \
for(x = 160; x < 480; x += (4 * 8)) { \
[C decompilation] [th02/op] Shot type selection Oh, OK, so this is what the PC-98 GRCG is all about. You call grcg_setcolor(), and that puts the PC-98 hardware in some sort of "monochromatic mode". Then, you just write your pixels into any *single* one of the 4 VRAM bitplanes. This causes the hardware to automatically write to *all* bitplanes in such a way that the final palette index for each of the 8, 16, or 32 pixels you just wrote a 1 value to will actually end up to match the color you set earlier. Don't forget to call grcg_off() at the end though, or you can't draw any non-monochromatic graphics, heh.
2015-02-25 22:05:20 +00:00
pd = VRAM_OFFSET(x, y); \
[C decompilation] [th02/op] Music Room Yes, all of it. Including the bouncing polygons, of course. And since it's placed at the end of ZUN's code inside the executable, the code's already position-independent and fully hackable.
2015-02-24 14:45:38 +00:00
*(long*)(dst[PL_B] + (dp)) = *(long*)(src[PL_B] + (sp)); \
*(long*)(dst[PL_R] + (dp)) = *(long*)(src[PL_R] + (sp)); \
*(long*)(dst[PL_G] + (dp)) = *(long*)(src[PL_G] + (sp)); \
*(long*)(dst[PL_E] + (dp)) = *(long*)(src[PL_E] + (sp)); \
ps += 4; \
} \
} \
for(y = 80; y < 384; y++) { \
for(x = 304; x < 624; x += (4 * 8)) { \
[C decompilation] [th02/op] Shot type selection Oh, OK, so this is what the PC-98 GRCG is all about. You call grcg_setcolor(), and that puts the PC-98 hardware in some sort of "monochromatic mode". Then, you just write your pixels into any *single* one of the 4 VRAM bitplanes. This causes the hardware to automatically write to *all* bitplanes in such a way that the final palette index for each of the 8, 16, or 32 pixels you just wrote a 1 value to will actually end up to match the color you set earlier. Don't forget to call grcg_off() at the end though, or you can't draw any non-monochromatic graphics, heh.
2015-02-25 22:05:20 +00:00
pd = VRAM_OFFSET(x, y); \
[C decompilation] [th02/op] Music Room Yes, all of it. Including the bouncing polygons, of course. And since it's placed at the end of ZUN's code inside the executable, the code's already position-independent and fully hackable.
2015-02-24 14:45:38 +00:00
*(long*)(dst[PL_B] + (dp)) = *(long*)(src[PL_B] + (sp)); \
*(long*)(dst[PL_R] + (dp)) = *(long*)(src[PL_R] + (sp)); \
*(long*)(dst[PL_G] + (dp)) = *(long*)(src[PL_G] + (sp)); \
*(long*)(dst[PL_E] + (dp)) = *(long*)(src[PL_E] + (sp)); \
ps += 4; \
} \
}
void pascal near cmt_back_snap(void)
{
int ps, x, pd, y;
int i;
for(i = 0; i < PL_COUNT; i++) {
cmt_back[i] = MK_FP(
hmem_allocbyte(304 * (320 / 8) + 16 * (320 / 8)), 0
);
}
CMT_BACK_BLIT(cmt_back, ps, VRAM_PLANE, pd);
}
#include "th02\music\cmt_load.c"
void pascal near cmt_back_free(void)
{
hmem_free(FP_SEG(cmt_back[PL_B]));
hmem_free(FP_SEG(cmt_back[PL_R]));
hmem_free(FP_SEG(cmt_back[PL_G]));
hmem_free(FP_SEG(cmt_back[PL_E]));
}
void pascal near cmt_back_put(void)
{
int ps, x, pd, y;
CMT_BACK_BLIT(VRAM_PLANE, pd, cmt_back, ps);
}
void pascal near draw_cmt(int track)
{
int line;
int p;
music_cmt_load(track);
screen_back_B_put();
cmt_back_put();
[C decompilation] [th02] Code segment #2 of all three executables Only one code segment left in both OP and FUUIN! its-happening.gif Yeah, that commit is way larger than I'm comfortable with, but none of these functions is particularly large or difficult to decompile (with the exception of graph_putsa_fx(), which I actually did weeks ago), and OP and MAIN have their own unique functions in between the shared ones, so…
2015-03-14 22:25:50 +00:00
graph_putsa_fx(160, 64, FX(15, 1, 0), music_cmt[0]);
[C decompilation] [th02/op] Music Room Yes, all of it. Including the bouncing polygons, of course. And since it's placed at the end of ZUN's code inside the executable, the code's already position-independent and fully hackable.
2015-02-24 14:45:38 +00:00
for(line = 1; line < MUSIC_CMT_LINE_COUNT; line++) {
[C decompilation] [th02] Code segment #2 of all three executables Only one code segment left in both OP and FUUIN! its-happening.gif Yeah, that commit is way larger than I'm comfortable with, but none of these functions is particularly large or difficult to decompile (with the exception of graph_putsa_fx(), which I actually did weeks ago), and OP and MAIN have their own unique functions in between the shared ones, so…
2015-03-14 22:25:50 +00:00
graph_putsa_fx(304, (line + 4) * 16, FX(13, 1, 0), music_cmt[line]);
[C decompilation] [th02/op] Music Room Yes, all of it. Including the bouncing polygons, of course. And since it's placed at the end of ZUN's code inside the executable, the code's already position-independent and fully hackable.
2015-02-24 14:45:38 +00:00
}
PLANE_DWORD_BLIT(screen_back_B, VRAM_PLANE_B);
}
void pascal musicroom(void)
{
static unsigned char track_playing = 0;
music_page = 1;
palette_black();
graph_showpage(0);
graph_accesspage(0);
graph_clear();
graph_accesspage(1);
[C decompilation] [th02/op] Shot type selection Oh, OK, so this is what the PC-98 GRCG is all about. You call grcg_setcolor(), and that puts the PC-98 hardware in some sort of "monochromatic mode". Then, you just write your pixels into any *single* one of the 4 VRAM bitplanes. This causes the hardware to automatically write to *all* bitplanes in such a way that the final palette index for each of the 8, 16, or 32 pixels you just wrote a 1 value to will actually end up to match the color you set earlier. Don't forget to call grcg_off() at the end though, or you can't draw any non-monochromatic graphics, heh.
2015-02-25 22:05:20 +00:00
pi_load_put_free(0, "op3.pi");
[C decompilation] [th02/op] Music Room Yes, all of it. Including the bouncing polygons, of course. And since it's placed at the end of ZUN's code inside the executable, the code's already position-independent and fully hackable.
2015-02-24 14:45:38 +00:00
music_sel = track_playing;
draw_tracks(music_sel);
graph_copy_page(0);
graph_accesspage(1);
graph_showpage(0);
screen_back_B_snap();
cmt_back_snap();
graph_accesspage(1); draw_cmt(track_playing);
graph_accesspage(0); draw_cmt(track_playing);
palette_100();
do {
input_sense();
[ZUN symbols] key_det / shiftkey Not applying this leak to TH03 since it would have more than one `key_det` variable, resulting in names that are as much fanfiction as the current ones…
2019-11-30 15:15:03 +00:00
if(key_det) {
[C decompilation] [th02/op] Music Room Yes, all of it. Including the bouncing polygons, of course. And since it's placed at the end of ZUN's code inside the executable, the code's already position-independent and fully hackable.
2015-02-24 14:45:38 +00:00
music_flip();
continue;
}
controls:
input_sense();
[ZUN symbols] key_det / shiftkey Not applying this leak to TH03 since it would have more than one `key_det` variable, resulting in names that are as much fanfiction as the current ones…
2019-11-30 15:15:03 +00:00
if(key_det & INPUT_UP) {
[C decompilation] [th02/op] Music Room Yes, all of it. Including the bouncing polygons, of course. And since it's placed at the end of ZUN's code inside the executable, the code's already position-independent and fully hackable.
2015-02-24 14:45:38 +00:00
draw_track(music_sel, 3);
if(music_sel > 0) {
music_sel--;
} else {
music_sel = SEL_QUIT;
}
if(music_sel == TRACK_COUNT) {
music_sel--;
}
draw_track(music_sel, 15);
}
[ZUN symbols] key_det / shiftkey Not applying this leak to TH03 since it would have more than one `key_det` variable, resulting in names that are as much fanfiction as the current ones…
2019-11-30 15:15:03 +00:00
if(key_det & INPUT_DOWN) {
[C decompilation] [th02/op] Music Room Yes, all of it. Including the bouncing polygons, of course. And since it's placed at the end of ZUN's code inside the executable, the code's already position-independent and fully hackable.
2015-02-24 14:45:38 +00:00
draw_track(music_sel, 3);
if(music_sel < SEL_QUIT) {
music_sel++;
} else {
music_sel = 0;
}
if(music_sel == TRACK_COUNT) {
music_sel++;
}
draw_track(music_sel, 15);
}
[ZUN symbols] key_det / shiftkey Not applying this leak to TH03 since it would have more than one `key_det` variable, resulting in names that are as much fanfiction as the current ones…
2019-11-30 15:15:03 +00:00
if(key_det & INPUT_SHOT || key_det & INPUT_OK) {
[C decompilation] [th02/op] Music Room Yes, all of it. Including the bouncing polygons, of course. And since it's placed at the end of ZUN's code inside the executable, the code's already position-independent and fully hackable.
2015-02-24 14:45:38 +00:00
if(music_sel != SEL_QUIT) {
char midi_active = snd_midi_active;
snd_midi_active = snd_midi_possible;
snd_load(MUSIC_FILES[music_sel], SND_LOAD_SONG);
snd_midi_active = 0;
snd_load(MUSIC_FILES[music_sel], SND_LOAD_SONG);
snd_midi_active = midi_active;
[Maintenance] Rename snd_kaja_func() to snd_kaja_interrupt() Oh, right, these functions can have parameters. So, let's turn snd_kaja_func() into a macro that combines the function number and the parameter into the AX value for the driver.
2015-03-15 22:26:44 +00:00
snd_kaja_func(KAJA_SONG_PLAY, 0);
[C decompilation] [th02/op] Music Room Yes, all of it. Including the bouncing polygons, of course. And since it's placed at the end of ZUN's code inside the executable, the code's already position-independent and fully hackable.
2015-02-24 14:45:38 +00:00
track_playing = music_sel;
draw_cmt(music_sel);
music_flip();
draw_cmt(music_sel);
} else {
break;
}
}
[ZUN symbols] key_det / shiftkey Not applying this leak to TH03 since it would have more than one `key_det` variable, resulting in names that are as much fanfiction as the current ones…
2019-11-30 15:15:03 +00:00
if(key_det & INPUT_CANCEL) {
[C decompilation] [th02/op] Music Room Yes, all of it. Including the bouncing polygons, of course. And since it's placed at the end of ZUN's code inside the executable, the code's already position-independent and fully hackable.
2015-02-24 14:45:38 +00:00
break;
}
[ZUN symbols] key_det / shiftkey Not applying this leak to TH03 since it would have more than one `key_det` variable, resulting in names that are as much fanfiction as the current ones…
2019-11-30 15:15:03 +00:00
if(!key_det) {
[C decompilation] [th02/op] Music Room Yes, all of it. Including the bouncing polygons, of course. And since it's placed at the end of ZUN's code inside the executable, the code's already position-independent and fully hackable.
2015-02-24 14:45:38 +00:00
music_flip();
goto controls;
}
} while(1);
while(1) {
input_sense();
[ZUN symbols] key_det / shiftkey Not applying this leak to TH03 since it would have more than one `key_det` variable, resulting in names that are as much fanfiction as the current ones…
2019-11-30 15:15:03 +00:00
if(key_det) {
[C decompilation] [th02/op] Music Room Yes, all of it. Including the bouncing polygons, of course. And since it's placed at the end of ZUN's code inside the executable, the code's already position-independent and fully hackable.
2015-02-24 14:45:38 +00:00
music_flip();
} else {
break;
}
};
screen_back_B_free();
cmt_back_free();
graph_showpage(0);
graph_accesspage(0);
graph_clear();
graph_accesspage(1);
[C decompilation] [th02/op] Shot type selection Oh, OK, so this is what the PC-98 GRCG is all about. You call grcg_setcolor(), and that puts the PC-98 hardware in some sort of "monochromatic mode". Then, you just write your pixels into any *single* one of the 4 VRAM bitplanes. This causes the hardware to automatically write to *all* bitplanes in such a way that the final palette index for each of the 8, 16, or 32 pixels you just wrote a 1 value to will actually end up to match the color you set earlier. Don't forget to call grcg_off() at the end though, or you can't draw any non-monochromatic graphics, heh.
2015-02-25 22:05:20 +00:00
pi_load_put_free(0, "op2.pi");
[C decompilation] Finish TH02's OP.EXE
2015-03-16 21:35:52 +00:00
palette_entry_rgb_show("op.rgb");
[C decompilation] [th02/op] Music Room Yes, all of it. Including the bouncing polygons, of course. And since it's placed at the end of ZUN's code inside the executable, the code's already position-independent and fully hackable.
2015-02-24 14:45:38 +00:00
graph_copy_page(0);
graph_accesspage(0);
}