Was already planning on eventually doing something like this for the CHR viewer (to allow it to display PRG ROM as tiles), makes sense to have something similar for the sprite viewer, too.
So, here you go! (next appveyor build will have it)
Thanks a lot! Just used this new feature to easily track down an annoying bug triggering when trying to use a metasprites with all 64 sprites.
I did run into a few minor issues however:
* The feature that makes the sprite viewer automatically show the pattern table for sprites as set by $2000 is generally convenient. But as my sprite table is at $1000 and I often find myself setting breakpoints in code where $2000 has been temporarily set to zero to disable NMIs, and with no way to override this setting I am left with the wrong tiles showing until I make the debugger stop somewhere else in my code.
* The 2x setting in the PPU viewer looks pretty useful as a means to zoom. But for all the views that stack two pixel images, it ends up being too tall for a 1080p display. OTOH, the widget that end up on the sides are unaffected by the scaling. Have you considered re-arranging the UI to stack the pixel images horizontally and have the widgets on the bottom? It would solve this problem with 1080p screens for everything but the 4x nametable viewer (but with vertical mirroring as I'm using, the lower one is redundant to me anyway and would best be removed completely in 2x mode)
* Sometimes, I accidentally open a new PPU Viewer window despite already having one open, and this appears to cause Mesen to hang and requiring a force kill with the Windows task manager.
None of these features are deal-breaker by any means - just figured I would mention them
And this is unrelated to the PPU Viewer, but despite having set the .dbg files to auto-import, Mesen doesn't seem to actually do this. I have to re-load the .dbg file manually every time I do a new build and fire up Mesen.
Do you know what's going wrong here?
The ability to show CHR from PRG-ROM sounds neat feature! Ideally, the format would be semi-configurable, as CHR data in PRG-ROM data often tends to be stored differently to the native format to make unrolled loops more efficient. For example, a common pattern is to have each row / plane in a separate array, to avoid having to increment / decrement the index registers for every byte copied:
WriteScrambledTile:
lda tileDataP0R0,x
sta $2007
[...]
lda tileDataP0R7,x
sta $2007
lda tileDataP1R0,x
sta $2007
[...]
lda tileDataP0R7,x
sta $2007
rts
But I realise this configurability might be difficult to achieve in practice... and could probably only work if the separated arrays are 256-byte-aligned.
Finally, I noticed you just added support for OAM corruption in Mesen. I know it's still a beta feature, but that's really useful! I spent quite a bit of time tweaking my NMI code to stay within the safe hblank region, and have been careful not to touch it since. The event viewer already helps a lot with this, but having the OAM corruption emulated is great to see the effect of it. As expected, the latest forced blanking code I'm prototyping right now causes a flickerfest when turning the feature on... which is a good reminder to myself why it's still prototype code...