The user can press Start to restart the game. When they do, I overwrite the GAME OVER tiles with a solid tile (ie: no letter).
However, for some reason, the screen briefly displays a bunch of zeros (Tile #$00) on half the screen before looking normal again.
I'm new to NES programming (but not to programming in general).
Has anyone else seen this before?
Whenever you have to redraw large portions of the screen, an operation that takes a lot of time, you have to disable rendering so the PPU won't touch the video memory, and you have full access to it. When you're done, turn rendering back on.
Small updates can be done with rendering on, as long as they're done during vblank, a time during which the PPU doesn't touch VRAM. That's how games that scroll work, they draw only the new parts of the background right before they scroll into view.
Out of curiosity: how many background tiles can I update without having to disable rendering?
Code: Select all
lda #$00 ;2 cycles sta $2007 ;4 cycles lda #$05 sta $2007 (...)
Code: Select all
ldy Start CopyByte: lda (Pointer), y ;5 cycles sta $2007 ;4 cycles iny ;2 cycles cpy End ;3 cycles bne CopyByte ;3 cycles
Avoid single-byte loops like in example B like the plague if you're going for speed! Avoid indirect addressing (keep your update buffer under 256 bytes and use absolute/indexed addressing). If using indices/counters, count down instead of up and avoid the CPX/CPY. Unroll loops whenever possible, even if partially.
*cough cough* Final Fantasy II *cough cough*koitsu wrote:Another possibility isn't the amount of data being transferred during NMI/VBlank, but that PPU scroll aren't "reset" before the start of the next drawing cycle, e.g. lda #$00 / sta $2005 / sta $2005 may be needed at end of NMI routine to ensure "junk" isn't printed on the screen when the PPU begins drawing again