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

163 lines
3.9 KiB
C
Raw Normal View History

Make the VRAM plane constants available to C
2015-02-24 15:17:50 +00:00
/* ReC98
* -----
Centrally include master.h in ReC98.h
2015-03-03 05:47:23 +00:00
* Main include file
Make the VRAM plane constants available to C
2015-02-24 15:17:50 +00:00
*/
[Maintenance] Add include guards to ReC98.h They do make everything so much simpler, after all. Especially now that th01/formats/grz.cpp should compile as a freestanding translation unit, as part of the .GRZ viewer. Part of P0082, funded by Ember2528.
2020-03-13 00:42:40 +00:00
#ifndef REC98_H
#define REC98_H
Centrally include master.h in ReC98.h
2015-03-03 05:47:23 +00:00
#include <master.h>
[C decompilation] Finish TH02's OP.EXE
2015-03-16 21:35:52 +00:00
#include <stddef.h>
[Decompilation] Finally declare <stdint.h> types *Finally*. We already used `(unsigned) int` in quite a few places where we actually want a 16-bit value, which was bound to annoy future port developers.
2019-12-11 20:42:27 +00:00
#include "platform.h"
[Maintenance] Move PC-98 hardware constants to a separate include file SPRITE16 would also like to refer to those later. Part of P0061, funded by Touhou Patch Center.
2019-11-08 20:03:03 +00:00
#include "pc98.h"
[C decompilation] Finish TH02's OP.EXE
2015-03-16 21:35:52 +00:00
// master.lib extensions
// ---------------------
#define palette_entry_rgb_show(fn) \
palette_entry_rgb(fn); \
palette_show();
[Position independence] [th02/th03/th04/th05] Color palettes Part of P0060, funded by Touhou Patch Center.
2019-11-26 21:47:07 +00:00
[Maintenance] Templatize RGB and palette types for 4- and 8-bit components Right, PC-98 hardware only supports 4 bits per RGB component, for a total of 4,096 possible colors. The 8-bit RGB color values we've been seeing throughout the later games are a master.lib extension, to allow for more toning precision. Which TH01, with all its NIH syndrome, doesn't use. And yup, that means templates in the most basic header files… Since that would have meant renaming *everything* to compile as C++, I simply made these types exclusive to C++ code, thcrap style. Part of P0066, funded by Keyblade Wiedling Neko and Splashman.
2020-01-05 11:05:42 +00:00
#ifdef __cplusplus
// master.lib palettes use twice the bits per RGB component for more
// toning precision
[Decompilation] Encode the per-component range in the RGB color template Allowing us to then retrieve it using a function call with no run-time cost, although we do have to be careful with the types here. Also, is that another solution to decompilation puzzles that involve types of number literals? Part of P0080, funded by Ember2528 and Splashman.
2020-03-01 11:24:18 +00:00
typedef RGB<uint8_t, 256> RGB8;
[Maintenance] Templatize RGB and palette types for 4- and 8-bit components Right, PC-98 hardware only supports 4 bits per RGB component, for a total of 4,096 possible colors. The 8-bit RGB color values we've been seeing throughout the later games are a master.lib extension, to allow for more toning precision. Which TH01, with all its NIH syndrome, doesn't use. And yup, that means templates in the most basic header files… Since that would have meant renaming *everything* to compile as C++, I simply made these types exclusive to C++ code, thcrap style. Part of P0066, funded by Keyblade Wiedling Neko and Splashman.
2020-01-05 11:05:42 +00:00
typedef Palette<RGB8> Palette8;
#endif
[C decompilation] Finish TH02's OP.EXE
2015-03-16 21:35:52 +00:00
// ---------------------
Centrally include master.h in ReC98.h
2015-03-03 05:47:23 +00:00
Add some useful increment and decrement macros Which we'd really like to have for the highscore entering screen.
2015-03-01 21:52:25 +00:00
// Macros
// ------
#define CLAMP_INC(val, max) \
(val)++; \
if((val) > (max)) { \
(val) = (max); \
}
#define CLAMP_DEC(val, min) \
(val)--; \
if((val) < (min)) { \
(val) = (min); \
}
#define RING_INC(val, ring_end) \
(val)++; \
if((val) > (ring_end)) { \
(val) = 0; \
}
#define RING_DEC(val, ring_end) \
(val)--; \
if((val) < 0) { \
(val) = ring_end; \
}
[C decompilation] [th01/op] [th01/reiiden] Random resident structure stuff
2015-03-07 16:35:30 +00:00
// Resident structure
#define RES_ID_LEN sizeof(RES_ID)
#define RES_ID_STRLEN (RES_ID_LEN - 1)
#define RES_PARASIZE ((sizeof(resident_t) + 0xF) >> 4)
Add some useful increment and decrement macros Which we'd really like to have for the highscore entering screen.
2015-03-01 21:52:25 +00:00
// ------
[Maintenance] Correctly declare all input functions The pascal calling convention for TH03's input mode functions actually sort of matters, since we have this nice function pointer type that expects pascal.
2019-11-30 14:48:36 +00:00
typedef union {
struct {
[Decompilation] Finally declare <stdint.h> types *Finally*. We already used `(unsigned) int` in quite a few places where we actually want a 16-bit value, which was bound to annoy future port developers.
2019-12-11 20:42:27 +00:00
int8_t lo, hi;
[Maintenance] Correctly declare all input functions The pascal calling convention for TH03's input mode functions actually sort of matters, since we have this nice function pointer type that expects pascal.
2019-11-30 14:48:36 +00:00
} byte;
[Decompilation] Finally declare <stdint.h> types *Finally*. We already used `(unsigned) int` in quite a few places where we actually want a 16-bit value, which was bound to annoy future port developers.
2019-12-11 20:42:27 +00:00
int16_t v;
[Maintenance] Correctly declare all input functions The pascal calling convention for TH03's input mode functions actually sort of matters, since we have this nice function pointer type that expects pascal.
2019-11-30 14:48:36 +00:00
} twobyte_t;
[Decompilation] Define generic function pointer types Going with the classic pointer-in-typedef approach here, because the syntax you'd otherwise have to use is terribly inconsistent. It'd be farfunc_t *near near_ptr_to_far_func; but nearfunc_t near *near_ptr_to_near_func; And that'd hopefully be the last change to ReC98.h for a long time! Those glacial compile times if every .c file is affected… Really stands out if your build system is otherwise perfect. Part of P0030, funded by zorg.
2019-09-15 14:09:08 +00:00
/// Typedefs
/// --------
// Generic callback function types. Note the difference between function
// distance (nearfunc / farfunc) and pointer variable distance
// (t_near / t_far).
typedef void (near pascal *near nearfunc_t_near)(void);
typedef void ( far pascal *near farfunc_t_near)(void);
typedef void (near pascal * far nearfunc_t_far)(void);
typedef void ( far pascal * far farfunc_t_far)(void);
/// --------
Add some useful increment and decrement macros Which we'd really like to have for the highscore entering screen.
2015-03-01 21:52:25 +00:00
// PC-98 VRAM planes
// -----------------
[Maintenance] Use `dots` for 1bpp lines, and `planar` for B/R/G/E dot structs I tried `brge` for the latter, but that had *the* most horrible ergonomics, and I misspelled it as `bgre` 100% of the times I typed it manually. Turns out that `dots` is also consistent with master.lib's naming scheme, leaving `planar` to *actually* refer to types storing multiple planes worth of pixels. These types are showing up more and more, and deserve something better than their previous long-winded and misleading name. Part of P0081, funded by Ember2528.
2020-03-06 23:25:03 +00:00
// 1bpp types, describing horizontal lines of 8, 16, or 32 pixels.
typedef uint8_t dots8_t;
typedef uint16_t dots16_t;
typedef uint32_t dots32_t;
[Decompilation] Add separate types for 1bpp planar pixel lines
2019-12-12 14:01:13 +00:00
// ... and the same for the rare cases where ZUN's code used signed types.
[Maintenance] Use `dots` for 1bpp lines, and `planar` for B/R/G/E dot structs I tried `brge` for the latter, but that had *the* most horrible ergonomics, and I misspelled it as `bgre` 100% of the times I typed it manually. Turns out that `dots` is also consistent with master.lib's naming scheme, leaving `planar` to *actually* refer to types storing multiple planes worth of pixels. These types are showing up more and more, and deserve something better than their previous long-winded and misleading name. Part of P0081, funded by Ember2528.
2020-03-06 23:25:03 +00:00
typedef int8_t sdots8_t;
typedef int16_t sdots16_t;
typedef int32_t sdots32_t;
[Decompilation] Add separate types for 1bpp planar pixel lines
2019-12-12 14:01:13 +00:00
Make the VRAM plane constants available to C
2015-02-24 15:17:50 +00:00
typedef enum {
PL_B, PL_R, PL_G, PL_E, PL_COUNT
} vram_plane_t;
[C decompilation] [th01/reiiden] Randomly shaped VRAM copy functions, #1 So apparently, TH01 isn't double-buffered in the usual sense, and instead uses the second hardware framebuffer (page 1) exclusively to keep the background image and any non-animated sprites, including the cards. Then, in order to limit flickering when animating the bullet, character and boss sprites on top of that (or just to the limit number of VRAM accesses, who knows), ZUN goes to great lengths and tries to make sure to only copy back the pixels that were modified on plane 0 in the last frame. (Which doesn't work that well though. When you play the game, you still notice tons of flickering whenever sprites overlap.) And by "great lengths", I mean "having a separate counterpart function for each shape and sprite animated which recalculates and copies back the same pixels from plane 1 to plane 0", because that's what the new functions here lead me to believe. Both of them are only called at one place: the wave function on the second half of Elis' entrance animation, and the horizontal masked line function for Reimu's X attack animations.
2015-03-10 16:39:00 +00:00
typedef struct {
[Maintenance] Use `dots` for 1bpp lines, and `planar` for B/R/G/E dot structs I tried `brge` for the latter, but that had *the* most horrible ergonomics, and I misspelled it as `bgre` 100% of the times I typed it manually. Turns out that `dots` is also consistent with master.lib's naming scheme, leaving `planar` to *actually* refer to types storing multiple planes worth of pixels. These types are showing up more and more, and deserve something better than their previous long-winded and misleading name. Part of P0081, funded by Ember2528.
2020-03-06 23:25:03 +00:00
dots8_t B, R, G, E;
} planar8_t;
[C decompilation] [th01/reiiden] Randomly shaped VRAM copy functions, #1 So apparently, TH01 isn't double-buffered in the usual sense, and instead uses the second hardware framebuffer (page 1) exclusively to keep the background image and any non-animated sprites, including the cards. Then, in order to limit flickering when animating the bullet, character and boss sprites on top of that (or just to the limit number of VRAM accesses, who knows), ZUN goes to great lengths and tries to make sure to only copy back the pixels that were modified on plane 0 in the last frame. (Which doesn't work that well though. When you play the game, you still notice tons of flickering whenever sprites overlap.) And by "great lengths", I mean "having a separate counterpart function for each shape and sprite animated which recalculates and copies back the same pixels from plane 1 to plane 0", because that's what the new functions here lead me to believe. Both of them are only called at one place: the wave function on the second half of Elis' entrance animation, and the horizontal masked line function for Reimu's X attack animations.
2015-03-10 16:39:00 +00:00
typedef struct {
[Maintenance] Use `dots` for 1bpp lines, and `planar` for B/R/G/E dot structs I tried `brge` for the latter, but that had *the* most horrible ergonomics, and I misspelled it as `bgre` 100% of the times I typed it manually. Turns out that `dots` is also consistent with master.lib's naming scheme, leaving `planar` to *actually* refer to types storing multiple planes worth of pixels. These types are showing up more and more, and deserve something better than their previous long-winded and misleading name. Part of P0081, funded by Ember2528.
2020-03-06 23:25:03 +00:00
dots16_t B, R, G, E;
} planar16_t;
[C decompilation] [th01/reiiden] Randomly shaped VRAM copy functions, #1 So apparently, TH01 isn't double-buffered in the usual sense, and instead uses the second hardware framebuffer (page 1) exclusively to keep the background image and any non-animated sprites, including the cards. Then, in order to limit flickering when animating the bullet, character and boss sprites on top of that (or just to the limit number of VRAM accesses, who knows), ZUN goes to great lengths and tries to make sure to only copy back the pixels that were modified on plane 0 in the last frame. (Which doesn't work that well though. When you play the game, you still notice tons of flickering whenever sprites overlap.) And by "great lengths", I mean "having a separate counterpart function for each shape and sprite animated which recalculates and copies back the same pixels from plane 1 to plane 0", because that's what the new functions here lead me to believe. Both of them are only called at one place: the wave function on the second half of Elis' entrance animation, and the horizontal masked line function for Reimu's X attack animations.
2015-03-10 16:39:00 +00:00
[Decompilation] [th01] Restorable line drawing Yes, when clipping the start and end points to the screen area, ZUN uses an integer division to calculate the line slopes, rather than a floating-point one. Doesn't seem like it actually causes any incorrect lines to be drawn, though; that case is only hit in the Mima boss fight, which draws a few lines with a bottom coordinate of 400 rather than 399. It *might* also restore the wrong pixels at parts of the YuugenMagan fight, causing weird flickering, but seriously, that's an issue everywhere you look in this game. Part of P0069, funded by [Anonymous] and Yanga.
2020-01-12 18:13:26 +00:00
typedef struct {
[Maintenance] Use `dots` for 1bpp lines, and `planar` for B/R/G/E dot structs I tried `brge` for the latter, but that had *the* most horrible ergonomics, and I misspelled it as `bgre` 100% of the times I typed it manually. Turns out that `dots` is also consistent with master.lib's naming scheme, leaving `planar` to *actually* refer to types storing multiple planes worth of pixels. These types are showing up more and more, and deserve something better than their previous long-winded and misleading name. Part of P0081, funded by Ember2528.
2020-03-06 23:25:03 +00:00
dots32_t B, R, G, E;
} planar32_t;
[Decompilation] [th01] Restorable line drawing Yes, when clipping the start and end points to the screen area, ZUN uses an integer division to calculate the line slopes, rather than a floating-point one. Doesn't seem like it actually causes any incorrect lines to be drawn, though; that case is only hit in the Mima boss fight, which draws a few lines with a bottom coordinate of 400 rather than 399. It *might* also restore the wrong pixels at parts of the YuugenMagan fight, causing weird flickering, but seriously, that's an issue everywhere you look in this game. Part of P0069, funded by [Anonymous] and Yanga.
2020-01-12 18:13:26 +00:00
[Decompilation] [th01] PTN-sized page 0→1 copies Final shared function in TH01's OP.EXE. Part of P0084, funded by Yanga.
2020-03-19 13:12:13 +00:00
// Abstracted dot and planar types, with their width defined by a macro.
#define dots_t_(x) dots##x##_t
#define dots_t(x) dots_t_(x)
#define planar_t_(x) planar##x##_t
#define planar_t(x) planar_t_(x)
Make the VRAM plane constants available to C
2015-02-24 15:17:50 +00:00
// Since array subscripts create slightly different assembly in places, we
// offer both variants.
[Maintenance] Use `dots` for 1bpp lines, and `planar` for B/R/G/E dot structs I tried `brge` for the latter, but that had *the* most horrible ergonomics, and I misspelled it as `bgre` 100% of the times I typed it manually. Turns out that `dots` is also consistent with master.lib's naming scheme, leaving `planar` to *actually* refer to types storing multiple planes worth of pixels. These types are showing up more and more, and deserve something better than their previous long-winded and misleading name. Part of P0081, funded by Ember2528.
2020-03-06 23:25:03 +00:00
extern dots8_t *VRAM_PLANE[PL_COUNT];
extern dots8_t *VRAM_PLANE_B;
extern dots8_t *VRAM_PLANE_G;
extern dots8_t *VRAM_PLANE_R;
extern dots8_t *VRAM_PLANE_E;
[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
[Maintenance] Define VRAM access macros for arbitrary bit counts Templates would have been nicer, but as soon as you add just one non-immediate parameter, Turbo C++ generates a useless store to a new local variable, ruining the generated code. Part of P0069, funded by [Anonymous] and Yanga.
2020-01-12 19:34:42 +00:00
#define VRAM_OFFSET(x, y) ((x) >> 3) + (y << 6) + (y << 4)
[Decompilation] Add an inline function for VRAM offset calculation Which actually does inline… in C++, because Turbo C++ doesn't support the `inline` keyword in C mode. So much for the superiority of that language, even in 1994… Part of P0083, funded by Yanga.
2020-03-15 19:11:55 +00:00
#ifdef __cplusplus
static inline unsigned int vram_offset_shift(int x, int y)
{
return VRAM_OFFSET(x, y);
}
[Decompilation] [th01] .PTN file loading and non-transparent display What is this, error checking in a ZUN game?! And surprisingly good code for deriving the alpha plane?! Part of P0083, funded by Yanga.
2020-03-16 17:54:02 +00:00
static inline unsigned int vram_offset_muldiv(int x, int y)
{
return (y * ROW_SIZE) + (x / 8);
}
[Decompilation] Add an inline function for VRAM offset calculation Which actually does inline… in C++, because Turbo C++ doesn't support the `inline` keyword in C mode. So much for the superiority of that language, even in 1994… Part of P0083, funded by Yanga.
2020-03-15 19:11:55 +00:00
#endif
[Maintenance] Define VRAM access macros for arbitrary bit counts Templates would have been nicer, but as soon as you add just one non-immediate parameter, Turbo C++ generates a useless store to a new local variable, ruining the generated code. Part of P0069, funded by [Anonymous] and Yanga.
2020-01-12 19:34:42 +00:00
#define VRAM_CHUNK(plane, offset, bit_count) \
[Maintenance] Use `dots` for 1bpp lines, and `planar` for B/R/G/E dot structs I tried `brge` for the latter, but that had *the* most horrible ergonomics, and I misspelled it as `bgre` 100% of the times I typed it manually. Turns out that `dots` is also consistent with master.lib's naming scheme, leaving `planar` to *actually* refer to types storing multiple planes worth of pixels. These types are showing up more and more, and deserve something better than their previous long-winded and misleading name. Part of P0081, funded by Ember2528.
2020-03-06 23:25:03 +00:00
*(dots##bit_count##_t *)(VRAM_PLANE_##plane + offset)
[Maintenance] Define VRAM access macros for arbitrary bit counts Templates would have been nicer, but as soon as you add just one non-immediate parameter, Turbo C++ generates a useless store to a new local variable, ruining the generated code. Part of P0069, funded by [Anonymous] and Yanga.
2020-01-12 19:34:42 +00:00
#define VRAM_SNAP(dst, plane, offset, bit_count) \
dst = VRAM_CHUNK(plane, offset, bit_count);
[Maintenance] Use `dots` for 1bpp lines, and `planar` for B/R/G/E dot structs I tried `brge` for the latter, but that had *the* most horrible ergonomics, and I misspelled it as `bgre` 100% of the times I typed it manually. Turns out that `dots` is also consistent with master.lib's naming scheme, leaving `planar` to *actually* refer to types storing multiple planes worth of pixels. These types are showing up more and more, and deserve something better than their previous long-winded and misleading name. Part of P0081, funded by Ember2528.
2020-03-06 23:25:03 +00:00
#define VRAM_SNAP_PLANAR(dst, offset, bit_count) \
[Maintenance] Define VRAM access macros for arbitrary bit counts Templates would have been nicer, but as soon as you add just one non-immediate parameter, Turbo C++ generates a useless store to a new local variable, ruining the generated code. Part of P0069, funded by [Anonymous] and Yanga.
2020-01-12 19:34:42 +00:00
VRAM_SNAP(dst.B, B, offset, bit_count); \
VRAM_SNAP(dst.R, R, offset, bit_count); \
VRAM_SNAP(dst.G, G, offset, bit_count); \
VRAM_SNAP(dst.E, E, offset, bit_count);
#define VRAM_PUT(plane, offset, src, bit_count) \
VRAM_CHUNK(plane, offset, bit_count) = src;
[Maintenance] Use `dots` for 1bpp lines, and `planar` for B/R/G/E dot structs I tried `brge` for the latter, but that had *the* most horrible ergonomics, and I misspelled it as `bgre` 100% of the times I typed it manually. Turns out that `dots` is also consistent with master.lib's naming scheme, leaving `planar` to *actually* refer to types storing multiple planes worth of pixels. These types are showing up more and more, and deserve something better than their previous long-winded and misleading name. Part of P0081, funded by Ember2528.
2020-03-06 23:25:03 +00:00
#define VRAM_PUT_PLANAR(offset, src, bit_count) \
[Maintenance] Define VRAM access macros for arbitrary bit counts Templates would have been nicer, but as soon as you add just one non-immediate parameter, Turbo C++ generates a useless store to a new local variable, ruining the generated code. Part of P0069, funded by [Anonymous] and Yanga.
2020-01-12 19:34:42 +00:00
VRAM_PUT(B, offset, src.B, bit_count); \
VRAM_PUT(R, offset, src.R, bit_count); \
VRAM_PUT(G, offset, src.G, bit_count); \
VRAM_PUT(E, offset, src.E, bit_count);
[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 PLANE_DWORD_BLIT(dst, src) \
[Maintenance] Use `dots` for 1bpp lines, and `planar` for B/R/G/E dot structs I tried `brge` for the latter, but that had *the* most horrible ergonomics, and I misspelled it as `bgre` 100% of the times I typed it manually. Turns out that `dots` is also consistent with master.lib's naming scheme, leaving `planar` to *actually* refer to types storing multiple planes worth of pixels. These types are showing up more and more, and deserve something better than their previous long-winded and misleading name. Part of P0081, funded by Ember2528.
2020-03-06 23:25:03 +00:00
for(p = 0; p < PLANE_SIZE; p += (int)sizeof(dots32_t)) { \
*(dots32_t*)((dst) + p) = *(dots32_t*)((src) + p); \
[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
}
[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
[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
void pascal vram_planes_set(void);
Add some useful increment and decrement macros Which we'd really like to have for the highscore entering screen.
2015-03-01 21:52:25 +00:00
// -----------------
[Maintenance] Add include guards to ReC98.h They do make everything so much simpler, after all. Especially now that th01/formats/grz.cpp should compile as a freestanding translation unit, as part of the .GRZ viewer. Part of P0082, funded by Ember2528.
2020-03-13 00:42:40 +00:00
#endif /* REC98_H */