[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
|
|
|
/* ReC98
|
|
|
|
|
* -----
|
|
|
|
|
* Code segment #13 of TH01's REIIDEN.EXE
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "th01/th01.h"
|
|
|
|
|
|
|
|
|
|
#pragma option -2
|
|
|
|
|
#pragma option -O-
|
|
|
|
|
#pragma option -Z-
|
|
|
|
|
|
|
|
|
|
#include "th01/grps2xsc.c"
|
|
|
|
|
|
|
|
|
|
void egc_copy_wave_1_to_0(int x, int y, int len, int amp, int ph, int w, int h)
|
|
|
|
|
{
|
|
|
|
|
int row;
|
|
|
|
|
int t = ph;
|
|
|
|
|
for(row = 0; row < h; row++) {
|
|
|
|
|
int x_wave = (((long)amp * Sin8(t)) / 256) + x;
|
|
|
|
|
t += 256 / len;
|
|
|
|
|
egc_copy_rect_1_to_0(x_wave, y + row, w, 1);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void graph_copy_hline_mask_1_to_0(int x, int y, char *mask, int w)
|
|
|
|
|
{
|
2020-03-06 23:25:03 +00:00
|
|
|
planar8_t px8;
|
[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
|
|
|
int col;
|
|
|
|
|
register int p = VRAM_OFFSET(x, y);
|
|
|
|
|
for(col = 0; col < w; col++, p++) {
|
|
|
|
|
if(mask[col]) {
|
2020-01-09 20:17:16 +00:00
|
|
|
graph_accesspage_func(1);
|
[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
|
|
|
px8.B = mask[col] & VRAM_PLANE_B[p];
|
|
|
|
|
px8.R = mask[col] & VRAM_PLANE_R[p];
|
|
|
|
|
px8.G = mask[col] & VRAM_PLANE_G[p];
|
|
|
|
|
px8.E = mask[col] & VRAM_PLANE_E[p];
|
2020-01-09 20:17:16 +00:00
|
|
|
graph_accesspage_func(0);
|
[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
|
|
|
grcg_setcolor_rmw(0);
|
|
|
|
|
VRAM_PLANE_B[p] = mask[col];
|
|
|
|
|
grcg_off();
|
|
|
|
|
VRAM_PLANE_B[p] |= px8.B;
|
|
|
|
|
VRAM_PLANE_R[p] |= px8.R;
|
|
|
|
|
VRAM_PLANE_G[p] |= px8.G;
|
|
|
|
|
VRAM_PLANE_E[p] |= px8.E;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|