Handling wrap around when scrolling past 256/240

Hello. I'm doing my screen refreshing routine, and I'm not sure of a good way to handle wrap around when scrolling. My current idea is to duplicate prerendered nametables in a layout like this:



That way, I won't have to deal with edge case when scroll x/y is bigger than 256/240. I would assume that would be more efficient as it'll remove a few ifs, the drawback of course is that'll take more memory.

Is that a good idea?

Crap, I wrote a big reply about how to go about updating the name tables in a scrolling game, and only after posting I realized this was NESemdev, not NESdev!

Since I'm here already, I'll try and give a fitting answer: basically, you should simulate the PPU's fetching pattern. For each tile rendered, the PPU reads a name table byte and an attribute table byte (plus 2 pattern table bytes, but those are not relevant to the matter). The addresses used for reading these bytes are calculated based on internal counters, which automatically wrap around. So as long as you update these counters the same way the PPU does, and make the same memory fetches as the PPU does, wrapping will work just fine.

Pre-rendering backgrounds is not a good idea, because the CPU can modify PPU registers and memory as the image is being rendered, which can affect how the image looks. This means that not always what would normally be the same background section will look the same, because a lot of things can change between both instances of the same background section (palette, color emphasis, scroll, etc).

Please refer to this wiki page to understand the order in which the PPU does things during rendering. The closest you adhere to this pattern, the more accurate your emulator will be.

Thanks for the hint.

I started doing like you suggest first, it's just that I thought that it will be horribly inefficient. So I figured that I could prerender name tables to save time and then mark an area as dirty if something changes (and even then, scrolling doesnt really change name tables per see, I just have to render part of a screen at an offset, then the other part with the updated value).

Anywho, if the consensus is that I'm painting myself into a corner I'll have a look at implementing my renderer more closely to the mechanism describe on the wiki.

A lot of games change CHR banks in mid-frame, which would require your emulator to redraw the whole background plane with the new CHR bank. This is common if there's already a split between the playfield and the status bar. It's also used often in title screens; Smash TV uses four 4K CHR banks for this. Cosmic Epsilon uses CHR banks to texture-map the ground. Some games (Marble Madness, Fire Emblem, Famicom Wars, Pirates) even change to a different bank in the middle of a scanline and change it back for the next.