Document more of the Window's behaviour #626
Conversation
|  | ||
| - If `WX` is equal to 0, the Window is switched to before the initial “fine scroll” adjustment, causing it to be shifted left by <math><mi>SCX</mi> <mo>%</mo> <mn>8</mn></math> pixels. | ||
| - On monochrome systems, `WX` = 166 (which would normally show a single Window pixel, along the right edge of the screen) exhibits a bug: the Window spans the entire screen, but offset vertically by one scanline. | ||
| - On monochrome systems, if the Window is disabled via `LCDC`, but the other conditions are met *and* it would have started rendering exactly on a BG tile boundary, then where it would have started rendering, a single pixel with ID 0 (i.e. drawn as the first entry in [the BG palette]) is inserted; this offsets the remainder of the scanline.[^star_trek] |
There was a problem hiding this comment.
then where it would have started rendering sounds a bit convoluted here
There was a problem hiding this comment.
Describing this accurately is really difficult, so if you can think of a better way..?
There was a problem hiding this comment.
| - On monochrome systems, if the Window is disabled via `LCDC`, but the other conditions are met *and* it would have started rendering exactly on a BG tile boundary, then where it would have started rendering, a single pixel with ID 0 (i.e. drawn as the first entry in [the BG palette]) is inserted; this offsets the remainder of the scanline.[^star_trek] | |
| - On monochrome systems, if the Window is disabled via `LCDC` but the other conditions are met, and rendering would have begun exactly on a BG tile boundary, then a single pixel with ID 0 (i.e. the first entry in [the BG palette]) is inserted at that point; this offsets the remainder of the scanline.[^star_trek] |
There was a problem hiding this comment.
No, this can occur anywhere within the scanline, not just at pixel 0. Perhaps “its rendering would have begun”? But that sounds even more confusing than my original phrasing...
There was a problem hiding this comment.
@ISSOtm where did I imply it's "at pixel 0"? The phrasing says A single pixel with ID 0 is inserted at that point (where "that point" is where rendering would have begun.
There was a problem hiding this comment.
I interpreted “rendering would have begun” to mean the scanline's overall rendering, since it's unqualified.
|
|
||
| If the WY condition has already been triggered and at the start of a row the window enable bit was set, | ||
| then resetting that bit before the WX condition gets triggered on that row yields a nice window glitch pixel where the window would have been activated. | ||
| The scroll registers are re-read on each [tile fetch](<#Get Tile>), except for the low 3 bits of `SCX`, which are only read at the beginning of the scanline (for the initial shifting of pixels). |
There was a problem hiding this comment.
You'd think the low bits of SCX would only be read once per line, because that's the logical way to do so, but unfortunately this isn't true. The fetched tile's X position is calculated (roughly) by adding SCX to LX and taking the 5 topmost bits, rather than adding the 5 topmost bits of SCX and LX.
There was a problem hiding this comment.
I see. Do you know of a test ROM that checks this?
Also, it seems like it'd be a better fit for a separate PR, so I'll open one when I have some info to pen down.
Co-authored-by: Antonio Vivace <avivace4@gmail.com>
Co-authored-by: Antonio Vivace <avivace4@gmail.com>
Fixes #376.
cc @LIJI32 for review
In particular, I have a TODO for linking to a test ROM, as I believe mealybug-tearoom has one for the “trigger Window multiple times in a single scanline” behaviour, but I couldn't figure out which one.