All info here is what I gathered from BT's ppu doc.
laughy wrote:
In other words, if sprite 0 is at ppu cycle say 25, will the bit for a sprite 0 hit not happen at this time, but at:
25 + (16 - CURRENT_HORIZONTAL_SCROLL_VALUE)
If Sprite 0 hits on the 16th pixel into the screen... then the sprite zero hit flag is set on the 16th cycle of the screen. No further math is needed. 16th pixel = 16th cycle.
Quote:
Is this true for ANY ppu register? (Once the ppu hits vblank, it doesn't set vblank until (16 - X cycles have passed)
As far as I know... all flags are adjusted immediately without any delay whatsoever. This goes for register writes, too (for example, in a game like Final Fantasy, the game switches between monochrome/color mode mid-scanline.. the visual effect takes effect immediatly without any delay)
The word "delay" is very very very misleading... since there is no real delay. What happens is... tiles are loaded a bit before they're displayed. Tile graphics data is loaded 16 cycles ahead of time and stored (presumably in some sort of PPU cache or something) until it's actually output to the screen. The only time I can see this having an effect is if the game swaps CHR banks (or changes CHR in some other manner) mid scanline. For example... the images for the first 2 tiles are already loaded on scanline cycle 0... so if the game swaps CHR on scanline cyc 0, the old data will still be output for 16 pixels (since it's already loaded). The actual pixels are rendered on the proper cycle without delay, though (pixel 0 -- cycle 0)
Quote:
:?: I'm at PPU cycle 15. Am I drawing the 15th pixel on the screen :?:
Yes
I tried going with the queue method of emulation a while back. It's easy to log all register writes and draw the full frame at once... but getting the register -reads- is what's hard. Remember that the game can read from $2007 (and other PPU regs) mid-frame / mid-scanline, and it could have an effect on PPU drawing (likewise, PPU drawing could affect what's returned back from the register read).