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_16(screen_x_t x, vram_y_t 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.`
[Maintenance] Declare distinct types for screen, VRAM, and TRAM coordinates Whew, time to look at every `int` variable we ever declared! The best moment to do this would have been a year ago, but well, better late than never. No need to communicate that in comments anymore. These shouldn't be used for widths, heights, or sprite-space coordinates. Maybe we'll cover that another time, this commit is already large enough. Part of P0111, funded by [Anonymous] and Blue Bolt. 2020-08-20 19:59:45 +00:00			`void DEFCONV egc_copy_rect_1_to_0_16(screen_x_t x, vram_y_t y, int w, int h);`