Bregalad wrote:
The NES can't do something like FLI, Memblers tried doing something similar called FAU, but I think it didn't work (at leat not well).
Yeah, I ended up losing I think 64 pixels on right border of the screen due to the forced hblank. These were some extreme measures just to write one byte to VRAM, heheh.
It also made an interesting comb pattern artifact on the border that didn't show up on any emulators when I checked (not even Nintendulator). It only timed properly on certain resets, though I bet that defect could be worked around. Since then, didn't blargg come up with a way to normalize the timing between resets? I hadn't tried it, and don't remember what it did exactly.
I think a 4-screen VRAM mode would work well for a background image. You would have the same nametable data in all screens, but you could set the attributes individually and have 16x4 pixel attribute size. All you have to do then is write to $2000 every hblank, that's easy. 4-screen mode is a good option if you're using CHR-RAM. That could work for some types of games, if the background updating is slow enough where the workload can be safely doubled to provide a 16x8 attribute size. This would be like simulating H or V mirroring in software, but being allowed to use an extra attribute table, see what I mean?