Issue with windows
Issue with windows
I'm having an issue with part of a window appearing on screen when it shouldn't be and I'm somewhat confused as to why it is happening. I'm thinking this is controlled by an I/O register, but I don't really know a whole lot how screens get pieced together other than their positioning on screen with Window X and Y, which I'm pretty sure isn't related to this issue.
Just for an extra bit of context, this is what the screen looks like in VRAM.
What am I missing here? Thanks.
Re: Issue with windows
Are you making an emulator or is this a game you are making?
Re: Issue with windows
I'm hacking a game.
Re: Issue with windows
Looking at the screenshot, the window layer may be reenabled too soon. There probably is a scanline interrupt being used to disable the Window Layer for a number of lines, but it looks like it's being reenabled too soon. I guess this is a translation hack right?
Re: Issue with windows
Yeah, translating.
I'm still not entirely clear on what I'm looking for. Since the God window is variable in height depending on the number of gods available and the issue doesn't happen with one god, it'll probably be easier to focus on that part. What is the process of getting from VRAM to the screen on the GB? Are VRAM transfers handled with DMA?
I'm still not entirely clear on what I'm looking for. Since the God window is variable in height depending on the number of gods available and the issue doesn't happen with one god, it'll probably be easier to focus on that part. What is the process of getting from VRAM to the screen on the GB? Are VRAM transfers handled with DMA?
Re: Issue with windows
DMA to VRAM (aka "Blast Processing") works on Game Boy Color, not original Game Boy. Original Game Boy has to copy data the hard way, by using instructions to load data from ROM and write it to VRAM.
The principle of rendering on the Game Boy is essentially the same as that on the NES, modulo some timing differences (NES's pixel output is fixed rate while GB's is variable). While rendering is turned on, the system will use the nametables and pattern tables in VRAM to determine what pixels to output.
The principle of rendering on the Game Boy is essentially the same as that on the NES, modulo some timing differences (NES's pixel output is fixed rate while GB's is variable). While rendering is turned on, the system will use the nametables and pattern tables in VRAM to determine what pixels to output.
Re: Issue with windows
Could you tell us which game this is, or maybe even give us your current work progress on the ROM?
Are you sure the game is even using the window for this? It could actually be changing the tile map source and SCX/SCY values midscreen on the right scanline, for example using the LCD interrupt.
Are you sure the game is even using the window for this? It could actually be changing the tile map source and SCX/SCY values midscreen on the right scanline, for example using the LCD interrupt.
Re: Issue with windows
I found the problem which was apparently caused by my accidental changing of 1 byte that was used for the FF45 register, LYC.
Re: Issue with windows
You changed when the scanline interrupt was firing then. It does explain how it ended up looking then.