Fx3 wrote:
One CPU cycle means 1 PPU pixel. Is incorrect to assume ppupixel = cpucycle % 342, plus its 'connection' with the scroll registers on line rendering?
You have it a little wrong. 1 pixel is rendered on each PPU cycle.... not each CPU cycle. So the current pixel being rendered is equal to the current PPU cycle of the scanline. 3 pixels are rendered for every 1 CPU cycle on an NTSC system.
Overview:
1 pixel rendered = 1 PPU cycle
3 PPU cycles = 1 CPU cycle (NTSC only)
341 PPU cycles = 1 scanline
113.666667 (341 / 3) CPU cycles = 1 scanline (NTSC only)
For PAL emulation, I believe it's actually 3.2 PPU cycles to every 1 CPU cycle... so 1 scanline is 106.5625 CPU cycles (341 / 3.2)
Fx3 wrote:
I mean, should I *really* increase the loopy's x_offset instead of taking cpucycle % 342?
Well... I doubt it will
really make any difference in most games... however it really isn't difficult to update the scroll values on their proper cycles... and it likely will make a difference in games which do timing tricks.