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

213 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
*/
#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;
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);
}