Automate PPU testing
taylus opened this issue · 12 comments
Related: #1
Do something like have the PPU generate a byte array of pixel palette color values (0-3) and then compare this to expected .png file images generated from other sources (bgb, gb-rom-viewer?)
Not strictly unit tests since they're loading files, but VRAM is 8K which would be too unwieldy to store as literal bytes in the source code. This automates the manual testing I've been doing so far, loading the byte arrays of pixels into monogameboy and inspecting them visually (it's less error prone, too).
Palettes will have to match obviously for the colors to match. Maybe don't compare on RGB colors, but instead sort the colors in the "expected" image and compare them that way?
Approach described above seems to be working well (have PPU generate byte array of pixel color values 0-3, compare to expected png). I've also been manually inspecting results (visually) by having GBDotNet.Console output that byte array as a .bin file and having monogameboy load + display it. This makes for a good "first pass" of testing, then automating it later makes it easier to reproduce + prevent regressions w/o all this manual work.
Behold, the Tetris title screen! (rendered from a fixed VRAM dump, but still!)
Rendering Pokemon background map and sprites from Red's room found some issues to fix:
-
Need to consider LCDC flags when rendering the background (e.g. which bg map is in use, where the tiles start, are tile numbers signed)
The PPU is rendering a background that looks like this (center) when it should look like the output in bgb:
Setting the LCDC from $a3 -> $b3 in bgb kinda reproduces the problem:
Doing so flips bit 4, the BG and window tileset start address + signed-ness flag. The PPU needs to handle this in order to render this background properly!
-
And then also, the reason I did this in the first place, the PPU needs to render sprites horizontally-flipped if that attribute bit in their last OAM byte is set:
Actual:
Expected: (all of those sprites flipped horizontally so that Red is one connected metasprite facing to the right)
Rendering this early scene from Link's Awakening found some more things to fix/implement:
- Need to implement 8x16 sprite mode (LCDC bit 2):
- Need to implement window layer:
677f84f fixes an issue determining which window pixels to render to the screen, and tests it by rendering the pause screen from Super Mario Land 1 (the ❤️PAUSE❤️ part is the window layer):
Something doesn't look right w/ Donkey Kong Land 2:
The background color palette isn't loading correctly, but also what is with the garbled looking tiles on the left? Is the scroll X register not working/implemented? The background map looks more correct in monogameboy (assuming the scroll registers aren't (0, 0))
re: scroll X above, it looks like DKL2 has some code that modifies the scroll registers right before drawing the screen (to keep it off the edge of a level?) and the memory dump I originally captured was from before or after(?) that code ran, so the scroll registers were zero at the time. It even looks weird in BGB's background map viewer depending on at when you pause things.
So it's not a PPU problem, just something unexpected re: when the memory dump was taken.
