nesdev.com

Hello, this ain't so newbie of a question, but I am.
Anyway, I was working on a game three weeks ago and something bugged me.
I had split the screen after 64 scanlines when sprite0 hit. At the split I enable scrolling, wait 64 more scanlines, and there I have the screen scrolling the opposite way by decrimenting xscroll. That lasts 64 more scanlines, then I turn off scoll for the rest of the screen. But the weird thing was that the wait amount for the first and the second scrolling area was not the same. And when I added the second nametable of background graphics, then the two wait times were the same.
So I guess if the second table is empy, somehow the ppu takes less time to get down?
I can post the source if this is confusing. I suspect it's well known, like for title screens that scroll on from both sides, maybe. Not using scanline irq counters.
No excuse for not searching this one. I'm sorry.
Tyler

_________________
Hello

How did you wait 64 scanlines after the sprite-0 hit?

The PPU always takes the same amount of time, otherwise it would not be able to keep up and create a valid video signal.

Make sure the loops in your 64-scanline delay code are not crossing a page boundary.

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

I agree with Quietust.

Probably, the one version of code aligned so it had no page-crossings and the second version, managed to have a page-crossing, thus making it take just a little bit more, and screwing up your timing.

Branching and addressing with X or Y take just a little longer if they cross past the low byte, and the upper byte needs to be increased.

2fe 2ff (boundary) 300 301

_________________
nesdoug.com -- blog/tutorial on programming for the NES