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

214 lines
5.4 KiB
C
Raw Normal View History

[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
/* ReC98
* -----
* Code segment #5 of TH02's OP.EXE
*/
[Maintenance] Consistently use forward slashes in #include paths Completes P0087, funded by -Tom-.
2020-04-15 15:48:40 +00:00
#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] 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
char sel = 1;
[Build] Don't word-align everything by default Again, 11 necessary workarounds, vs. forcing byte aligment in at least 18 places, and that number would have significantly grown in the future. Part of P0085, funded by -Tom-.
2020-03-30 18:17:28 +00:00
int8_t sel_padding = 0;
[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
const char *DESC[SHOTTYPE_COUNT][3] = {
" <20>A<EFBFBD>z<EFBFBD>ʂ̗͂<CC97><CD82>g<EFBFBD><67><EFBFBD>Ȃ<EFBFBD> ",
" <20>L<EFBFBD>͈͂ł<CD82><C582>‹@<40><><EFBFBD>͂<EFBFBD> ",
"<EFBFBD>@<40><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>@<40><><EFBFBD>̓^<5E>C<EFBFBD>v<EFBFBD>@",
" <20>@<40>ˌ<EFBFBD><CB8C><EFBFBD><EFBFBD>D<EFBFBD><44><EFBFBD>Ă<EFBFBD><C482><EFBFBD> <20>@",
"<EFBFBD>@ <20>o<EFBFBD><6F><EFBFBD><EFBFBD><EFBFBD>X<EFBFBD>̎<EFBFBD><CC8E>ꂽ<EFBFBD>@ ",
"<EFBFBD>@<40>@<40>h<EFBFBD><68><EFBFBD>d<EFBFBD><64><EFBFBD>^<5E>C<EFBFBD>v<EFBFBD>@<40>@",
" <20>@<40>A<EFBFBD>z<EFBFBD>ʂ̗͂Ő키 ",
"<EFBFBD>@<40>U<EFBFBD><55><EFBFBD>͂<EFBFBD><CD82>D<EFBFBD><44><EFBFBD>Ă<EFBFBD><C482><EFBFBD><EFBFBD>@",
"<EFBFBD>@<40>@<40>U<EFBFBD><55><EFBFBD>d<EFBFBD><64><EFBFBD>^<5E>C<EFBFBD>v<EFBFBD>@<40>@"
};
const char *CHOOSE = "<EFBFBD>˖<EFBFBD><EFBFBD>̐퓬<EFBFBD>X<EFBFBD>^<5E>C<EFBFBD><43><EFBFBD><EFBFBD><EFBFBD>A<EFBFBD><41><EFBFBD>̂R<CC82>‚<EFBFBD><C282>炦<EFBFBD><E782A6><EFBFBD><EFBFBD><EFBFBD>ł<EFBFBD>";
const char *EXTRA_NOTE[] = {
"<EFBFBD><EFBFBD><EFBFBD>j<EFBFBD>@<40>G<EFBFBD>L<EFBFBD>X<EFBFBD>g<EFBFBD><67><EFBFBD>X<EFBFBD>e<EFBFBD>[<5B>W<EFBFBD>ł́A<CD81><41><EFBFBD>Փx<D593>A<EFBFBD>v<EFBFBD><76><EFBFBD>C<EFBFBD><43><EFBFBD>[<5B>A<EFBFBD>{<7B><><EFBFBD><EFBFBD><EFBFBD>͕ύX<CF8D>o<EFBFBD><6F><EFBFBD>܂<EFBFBD><DC82><EFBFBD>",
"<EFBFBD>@<40>@<40>@<40><><EFBFBD>ꂼ<EFBFBD><EA82BC><EFBFBD>A<EFBFBD><41><EFBFBD>Փx<D593>d<EFBFBD>w<EFBFBD>s<EFBFBD>q<EFBFBD>`<60>A<EFBFBD>v<EFBFBD><76><EFBFBD>C<EFBFBD><43><EFBFBD>[<5B>R<EFBFBD>l<EFBFBD>A<EFBFBD>{<7B><><EFBFBD>P<EFBFBD>‚ƂȂ<C682><C882>܂<EFBFBD> "
};
const char *CLEARED = " <20><><EFBFBD><EFBFBD><EFBFBD>b<EFBFBD>k<EFBFBD>d<EFBFBD>`<60>q<EFBFBD>d<EFBFBD>c<EFBFBD><63><EFBFBD><EFBFBD> ";
char cleared_game_with[SHOTTYPE_COUNT];
char cleared_extra_with[SHOTTYPE_COUNT];
long unused[2];
Rename the *_copy_region_* functions to *_copy_rect_* TH01 copies a lot of different shapes from plane 1 to 0, so "region" feels awfully unspecific.
2015-03-10 12:59:12 +00:00
void pascal graph_copy_rect_1_to_0(int x, int y, int w, int h);
[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
void copy_pic_back(int sel, int highlight)
{
int x, y;
if(!highlight) {
switch(sel) {
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
case 0: x = 16; y = 128; break;
case 1: x = 224; y = 224; break;
[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
case 2: x = 432; y = 128; break;
}
Rename the *_copy_region_* functions to *_copy_rect_* TH01 copies a lot of different shapes from plane 1 to 0, so "region" feels awfully unspecific.
2015-03-10 12:59:12 +00:00
graph_copy_rect_1_to_0(x, y, 16, 144);
graph_copy_rect_1_to_0(x, y, 192, 10);
[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
} else {
switch(sel) {
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
case 0: x = 208; y = 136; break;
case 1: x = 416; y = 232; break;
[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
case 2: x = 624; y = 136; break;
}
Rename the *_copy_region_* functions to *_copy_rect_* TH01 copies a lot of different shapes from plane 1 to 0, so "region" feels awfully unspecific.
2015-03-10 12:59:12 +00:00
graph_copy_rect_1_to_0(x, y, 16, 144);
[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
switch(sel) {
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
case 0: x = 24; y = 272; break;
case 1: x = 232; y = 368; break;
[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
case 2: x = 440; y = 272; break;
}
Rename the *_copy_region_* functions to *_copy_rect_* TH01 copies a lot of different shapes from plane 1 to 0, so "region" feels awfully unspecific.
2015-03-10 12:59:12 +00:00
graph_copy_rect_1_to_0(x, y, 192, 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
}
}
void darken_pic_at(int x, int y)
{
int row_p = VRAM_OFFSET(x, y);
int row, col;
grcg_setcolor(GC_RMW, 0);
for(row = 0; row < 144; row++, row_p += 640 / 8) {
for(col = 0; col < 192 / 8; col += 2) {
[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, row_p + col, (row & 1 ? 0xAAAA : 0x5555), 16);
[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
}
}
grcg_off();
}
void draw_shottype_desc(int sel, int color)
{
int x, y;
switch(sel) {
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
case 0: x = 16; y = 296; break;
case 1: x = 224; y = 136; break;
[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
case 2: x = 432; y = 296; break;
}
grcg_setcolor(GC_RMW, color);
grcg_round_boxfill(x + 8, y + 8, x + 200, y + 72, 8);
grcg_setcolor(GC_RMW, 0);
grcg_round_boxfill(x, y, x + 192, y + 64, 8);
grcg_off();
[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(x + 8, y + 8 + 0, FX(color, 2, 0), DESC[sel][0]);
graph_putsa_fx(x + 8, y + 8 + 16, FX(color, 2, 0), DESC[sel][1]);
graph_putsa_fx(x + 8, y + 8 + 32, FX(color, 2, 0), DESC[sel][2]);
[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
}
void pascal draw_header(void)
{
grcg_setcolor(GC_RMW, 12); grcg_round_boxfill(136, 24, 520, 56, 8);
grcg_setcolor(GC_RMW, 0); grcg_round_boxfill(128, 16, 512, 48, 8);
grcg_off();
[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(144, 24, FX(12, 2, 0), CHOOSE);
[Maintenance] Use the same resident structure pointer name for every game The TH04/TH05 BGM/SE mode setup is a good example for code where different structure field offsets will vanish completely upon reverse- engineering. If we continued to use the per-game ID string as the variable name, we'd only have another game-specific "difference" there. Part of P0065, funded by Touhou Patch Center.
2019-12-30 14:48:17 +00:00
if(resident->stage == 5) {
[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
grcg_setcolor(GC_RMW, 12); grcg_round_boxfill(24, 56, 632, 104, 8);
grcg_setcolor(GC_RMW, 0); grcg_round_boxfill(16, 48, 624, 96, 8);
grcg_off();
[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(32, 56, FX(15, 2, 0), EXTRA_NOTE[0]);
graph_putsa_fx(32, 72, FX(15, 2, 0), EXTRA_NOTE[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
}
}
void pascal shottype_menu_init(void)
{
#define DRAW_CLEARED_FOR(mode) \
if(cleared_##mode##_with[0]) { \
[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, 112, FX(15, 2, 0), CLEARED); \
[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
} \
if(cleared_##mode##_with[1]) { \
[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(224, 112, FX(15, 2, 0), CLEARED); \
[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
} \
if(cleared_##mode##_with[2]) { \
[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(432, 112, FX(15, 2, 0), CLEARED); \
[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
}
palette_black();
graph_accesspage(0);
pi_load_put_free(3, "TSELECT.pi");
graph_copy_page(1);
graph_accesspage(0);
[Maintenance] Use the same resident structure pointer name for every game The TH04/TH05 BGM/SE mode setup is a good example for code where different structure field offsets will vanish completely upon reverse- engineering. If we continued to use the per-game ID string as the variable name, we'd only have another game-specific "difference" there. Part of P0065, funded by Touhou Patch Center.
2019-12-30 14:48:17 +00:00
if(resident->stage != 5) {
[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
DRAW_CLEARED_FOR(game);
} else {
DRAW_CLEARED_FOR(extra);
}
pi_slot_put( 24, 136, 0);
pi_slot_put(224, 224, 1);
pi_slot_put(440, 136, 2);
[Maintenance] Use the same resident structure pointer name for every game The TH04/TH05 BGM/SE mode setup is a good example for code where different structure field offsets will vanish completely upon reverse- engineering. If we continued to use the per-game ID string as the variable name, we'd only have another game-specific "difference" there. Part of P0065, funded by Touhou Patch Center.
2019-12-30 14:48:17 +00:00
resident->shottype = 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
darken_pic_at( 24, 136);
darken_pic_at(440, 136);
draw_shottype_desc(0, 7);
draw_shottype_desc(1, 12);
draw_shottype_desc(2, 7);
draw_header();
palette_black_in(2);
}
void pascal shottype_menu(void)
{
int input_locked = 0;
int pic_x[] = { 16, 224, 432};
int pic_y[] = {128, 224, 128};
unsigned int input_delay = 0;
shottype_menu_init();
#define DRAW_NEW_SEL() \
frame_delay(1); copy_pic_back(sel, 1); \
frame_delay(1); draw_shottype_desc(sel, 12); \
frame_delay(1); pi_slot_put(pic_x[sel], pic_y[sel], sel);
do {
input_sense();
if(!input_locked) {
[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_LEFT) {
[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
draw_shottype_desc(sel, 7);
frame_delay(1);
copy_pic_back(sel, 0);
frame_delay(1);
pi_slot_put(pic_x[sel] + 8, pic_y[sel] + 8, sel);
frame_delay(1);
darken_pic_at(pic_x[sel] + 8, pic_y[sel] + 8);
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
RING_DEC(sel, SHOTTYPE_COUNT - 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
DRAW_NEW_SEL();
}
[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_RIGHT) {
[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
copy_pic_back(sel, 0);
frame_delay(1);
pi_slot_put(pic_x[sel] + 8, pic_y[sel] + 8, sel);
frame_delay(1);
draw_shottype_desc(sel, 7);
frame_delay(1);
darken_pic_at(pic_x[sel] + 8, pic_y[sel] + 8);
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
RING_INC(sel, SHOTTYPE_COUNT - 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
DRAW_NEW_SEL();
}
[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) {
[Maintenance] Use the same resident structure pointer name for every game The TH04/TH05 BGM/SE mode setup is a good example for code where different structure field offsets will vanish completely upon reverse- engineering. If we continued to use the per-game ID string as the variable name, we'd only have another game-specific "difference" there. Part of P0065, funded by Touhou Patch Center.
2019-12-30 14:48:17 +00:00
resident->shottype = sel;
[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
break;
}
}
frame_delay(1);
[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
input_locked = key_det;
[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
if(input_locked) {
input_delay++;
if(input_delay > 30) {
input_locked = 0;
}
} else {
input_delay = 0;
}
} while(1);
graph_pi_free(&pi_slot_headers[0], pi_slot_buffers[0]);
graph_pi_free(&pi_slot_headers[1], pi_slot_buffers[1]);
graph_pi_free(&pi_slot_headers[2], pi_slot_buffers[2]);
palette_black_out(1);
}