Is it possible to change a palette color mid-screen (timed with a sprite zero hit...the sprite zero Y position being variable).
Would I have to reset the screen scroll position afterwards?
With just a sprite 0 hit, you could get it if you're willing to accept one disabled/glitchy scanline where the change happens.
You need something better—at least an IRQ, and maybe something even more special—to be able to get things to the point where only a small part of a scanline is wrong.
I thought of something better...
Two identical nametables, except...
One nametable filled with attribute table for 1 palette...
2nd nametable filled with attribute table for another palette.
Sprite zero times switch nametables midscreen.
Is that better?
That's pretty much how linescrolling works.
We've had at least 2 lengthy discussions about mid-screen palette changes recently, going through all the different techniques and their downsides. I'm not gonna search for them because I'm on my phone, but you should try looking for them.
If the name table switching you described solves your problem, then definitely go with that, as that's infinitely simpler than changing the palette itself. That solution obviously won't buy you more than 25 colors on screen though, it will simply allow you to have attribute regions finer than 16x16 pixels.
Oh, I see a duplicate thread...
viewtopic.php?f=2&t=13778
I did a bunch of tests, and checked it on a real NES.
Changing color emphasis (or gray scale bit) midframe, works great, no problems.
Changing Nametables midframe, no problems.
Changing a color midframe (with no sprites on screen) is glitchy as hell, and very hard to time.
Needs to be done either with rendering off, change color, 2006,2005,2005,2006 , screen on... which takes most of a scanline to do /// or exactly on a multiple of 8 (y position), screen off, change color, 2006, 2006, screen on...which takes about 1/8 of a scanline to do.
Changing a color midframe (WITH sprites) does all sorts of weird things to the sprites...they seem to have wrong tiles and incorrect positions... randomly.
dougeff wrote:
Changing a color midframe (WITH sprites) does all sorts of weird things to the sprites...they seem to have wrong tiles and incorrect positions... randomly.
Timing requirements on when you can turn off rendering is a little tricky, otherwise it'll corrupt OAM.
Any *useful* mid-screen palette changes will need 1 or more blank scanlines to be completely glitch-free, but even then it's still a little tricky.