Parse video memory into background map comprised of tile numbers
Parse video memory into window layer built up of tile numbers
Parse the sprite OAM
Layer the background, window, and sprites correctly in order to produce a grid of pixel colors (take various layer enable/disable flags and priorities into account, e.g. sprites can be either above or below the window layer)
Take scroll registers into account in order to clip the 32x32 tiles (256x256 pixels) of background into the viewable 160x144 pixels of screen output
This 160x144 pixels of 4-color data should be the output that is consumed by the emulator host (e.g. MonoGame). This will leave the PPU ignorant of renderer details and make it easier to test + support multiple renderers.
What is the window layer?
Maybe add a example ROM to https://github.com/taylus/gameboy-dev that uses the window layer? I'm not that familiar w/ it since I haven't used it before, but it's an obvious choice for things like a game UI that needs to draw on top of everything (Pokemon's start menu, etc).
According to pandocs it sounds like it's just another background layer that can't be scrolled (just moved via a register that sets its upper left corner's position) and is assigned to the other background map in VRAM (whichever isn't being used by the background layer).
FF4B - WX - Window X Position minus 7 (R/W)
Specifies the upper/left positions of the Window area. (The window is an alternate background area which can be displayed above of the normal background. OBJs (sprites) may be still displayed above or behinf the window, just as for normal BG.)
The window becomes visible (if enabled) when positions are set in range WX=0..166, WY=0..143. A postion of WX=7, WY=0 locates the window at upper left, it is then completly covering normal background.
The PPU should:
Overall reference:
References on how to parse video memory:
Video memory-mapped I/O registers:
What is the window layer? Maybe add a example ROM to https://github.com/taylus/gameboy-dev that uses the window layer? I'm not that familiar w/ it since I haven't used it before, but it's an obvious choice for things like a game UI that needs to draw on top of everything (Pokemon's start menu, etc).
According to pandocs it sounds like it's just another background layer that can't be scrolled (just moved via a register that sets its upper left corner's position) and is assigned to the other background map in VRAM (whichever isn't being used by the background layer).
See: http://bgb.bircd.org/pandocs.htm#lcdpositionandscrolling