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

29 lines
590 B
C
Raw Normal View History

[C decompilation] [th02/op] [th03/op] [th04/op] Frame delay #1
2015-03-03 09:20:20 +00:00
/* ReC98
* -----
* Code segment #2 of TH02's OP.EXE
*/
#include "th02/th02.h"
[C decompilation] [th02] PI display
2015-03-04 03:28:16 +00:00
#pragma option -3
[C decompilation] [th02/op] Second set of sound driver calls So yeah, after ignoring this issue for a week, we indeed have no choice but to decompile these functions into this horrible mess of C and inline assembly. And you know what? Since the compiled result still matches with ZUN's binary, it's entirely possible that this *was* the original format this code was written in! Seriously, how intoxicated do you have to be to write (or rather, slur) code like this? Keeping these functions entirely in assembly would have surely been better. However, it would have made linking practically impossible, especially for the later games which still need them in the current assembly slice format.
2015-03-12 11:46:51 +00:00
#pragma option -k-
[C decompilation] [th02] PI display
2015-03-04 03:28:16 +00:00
[C decompilation] [th02] First set of sound driver calls
2015-03-04 01:39:36 +00:00
char snd_active = 0;
char snd_unused = 0;
[C decompilation] [th02/op] Second set of sound driver calls So yeah, after ignoring this issue for a week, we indeed have no choice but to decompile these functions into this horrible mess of C and inline assembly. And you know what? Since the compiled result still matches with ZUN's binary, it's entirely possible that this *was* the original format this code was written in! Seriously, how intoxicated do you have to be to write (or rather, slur) code like this? Keeping these functions entirely in assembly would have surely been better. However, it would have made linking practically impossible, especially for the later games which still need them in the current assembly slice format.
2015-03-12 11:46:51 +00:00
extern char snd_interrupt_if_midi;
extern char snd_fm_possible;
[C decompilation] [th02] First set of sound driver calls
2015-03-04 01:39:36 +00:00
extern char snd_midi_active;
#include "th02/snd/se_data.c"
[C decompilation] [th02/op] Second set of sound driver calls So yeah, after ignoring this issue for a week, we indeed have no choice but to decompile these functions into this horrible mess of C and inline assembly. And you know what? Since the compiled result still matches with ZUN's binary, it's entirely possible that this *was* the original format this code was written in! Seriously, how intoxicated do you have to be to write (or rather, slur) code like this? Keeping these functions entirely in assembly would have surely been better. However, it would have made linking practically impossible, especially for the later games which still need them in the current assembly slice format.
2015-03-12 11:46:51 +00:00
#include "th02/snd/mmd_res.c"
#include "th02/snd/detmode.c"
#include "th02/snd/pmd_res.c"
#include "th02/snd/load.c"
[C decompilation] [th02] PI display
2015-03-04 03:28:16 +00:00
#include "th02/formats/pi_put.c"
[C decompilation] [th02] First set of sound driver calls
2015-03-04 01:39:36 +00:00
#include "th02/snd/kajafunc.c"
#include "th02/snd/delaymea.c"
#include "th02/snd/se.c"
[C decompilation] [th02/op] [th03/op] [th04/op] Frame delay #1
2015-03-03 09:20:20 +00:00
#include "th02/hardware/frmdely1.c"