ReC98/th01/th01.h

87 lines
1.7 KiB
C
Raw Normal View History

/* ReC98
* -----
* Include file for TH01
*/
#include "ReC98.h"
// Graphics
// --------
void egc_copy_rect_1_to_0(int x, int y, int w, int h);
void graph_accesspage_func(int page);
[C decompilation] [th01/fuuin] Slow 2x VRAM region scaling This function raises one of those essential questions about the eventual ports we'd like to do. I'll explain everything more thoroughly here, since people who might complain about the ports not being faithful enough need to understand this. ---- The original plan was aim for "100% frame-perfect" ports and advertise them as such. However, the PC-98 is not a console with fixed specs. As the name implies, it's a computer architecture, and a plethora of different, more and more powerful PC-98 models were released during its lifespan. Even if we only consider the subset of products that fulfills the minimum requirements to run the PC-98 Touhou games, that's still a sizable number of systems. Therefore, the only true definition of a *frame* can be "everything that is drawn between two Vsync wait calls". Such a *frame* may contain certain expensive function calls, and certain systems may run these functions slower than the developer expected, thus effectively leading to more *frames* than the developer explicitly specified. This is one of those functions. Here, we have a scaling function that appears to be written deliberately to run very slow, which ends up creating the rolling effect you see in the route selection and the high score and continue screens of TH01. However, that doesn't change the fact that the function is still CPU-bound, and neither waits for Vsync nor is iteratively called by something that does. The faster your CPU, the faster the rolling effect gets… until ultimately, it's faster than one frame and therefore vanishes altogether. Mind you, this is true on both emulators and real hardware. The final PC-98 model, the Ra43, had a CPU clocked at 433 Mhz, and it may have even been instant there. If you use more optimized algorithm, it also runs faster on the same CPU (I tried this, and it worked beautifully)… you get the idea. Still, it may very well be that this algorithm was not a deliberate choice and simply resulted from a lack of experience, especially since this was ZUN's first game. That leaves us with two approaches to porting functions like these: 1) Look at the recommended system requirements ZUN specified, configure the PC-98 emulator accordingly, measure how much of the work is done in each frame, then rewrite the function to be bound to that specific frame rate… 2) …or just continue using a CPU-bound algorithm, which will pretty much complete instantly on any modern system. I'd argue that 2) is actually the more "faithful" approach. It will run faster than the typical clock speeds people emulate the games at, and maybe draw a bit of criticism because of that, but it seems a lot more rational than the approximation provided by 1). Not to mention that it's undeniably easier to implement, and hey, a faster game feels a lot better than a slower one, right? … Oh well, maybe we'll still encounter some kind of CPU-bound animation that is so essential to the experience that we do want to lock it to a certain frame rate…
2015-03-09 16:58:30 +00:00
void grcg_setcolor_rmw(int color);
void grcg_off_func(void);
#undef graph_accesspage
#define graph_accesspage graph_accesspage_func
#undef grcg_off
#define grcg_off grcg_off_func
// --------
// master.lib text function reimplementations
// ------------------------------------------
typedef enum {
CURSOR_HIDE,
CURSOR_BLOCK,
CURSOR_UNDERLINE
} z_text_cursor_t;
void z_test_init(void);
void z_text_25line(void);
void z_text_20line(void);
void z_text_systemline_show(void);
void z_text_systemline_hide(void);
void z_text_clear(void);
void z_text_show(void);
void z_text_hide(void);
void z_text_setcursor(z_text_cursor_t type);
void z_text_print(const char *cmd);
// ----
// Game
#define STAGES_PER_SCENE 4
#define SCENE_COUNT 4
// Resident structure
#define RES_ID "ReiidenConfig"
typedef enum {
ROUTE_MAKAI,
ROUTE_JIGOKU
} route_t;
typedef enum {
MODE_REGULAR = 0,
MODE_TEST = 1,
MODE_DEBUG = 3
} mode_t;
#pragma option -a1
typedef struct {
char id[RES_ID_LEN];
char rank;
char bgm_mode; // 0 = off, 1 = FM
char bombs;
char start_lives_extra; // Add 2 for the actual number of lives
char end_flag;
char unused_1;
char route;
char rem_lives;
char snd_need_init;
char unused_2;
char mode;
int bullet_speed;
long rand;
long score;
long continues_total;
int continues_per_scene[SCENE_COUNT];
long bonus_per_stage[STAGES_PER_SCENE]; // of the current scene
int stage;
long hiscore;
long score_highest; // among all continues
unsigned int p_value;
} resident_t;
#pragma option -a2