ReC98/th01/hardware/egc.h

#include "defconv.h"

// Blits the rectangle from (⌊x/16⌋*16, y) to (⌈((x + w)/16)*16⌉, (y + h))
// from VRAM page 1 to the same position on VRAM page 0.
void DEFCONV egc_copy_rect_1_to_0(int x, int y, int w, int h);
[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			`#include "defconv.h"`

[Reverse-engineering] [th04/th05] EGC-powered page 1→0 region copies 2019-12-07 07:37:29 +00:00			`// Blits the rectangle from (⌊x/16⌋16, y) to (⌈((x + w)/16)16⌉, (y + h))`
			`// from VRAM page 1 to the same position on VRAM page 0.`
[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			`void DEFCONV egc_copy_rect_1_to_0(int x, int y, int w, int h);`