dougeff wrote:
What if you were using a mapper without scanline counter, and you were using the sprite zero hit elsewhere, and you couldn't be certain of exactly where the hblank was...
But if you were this lost, you'd need a lot of sprites to be absolute sure the glitch would be covered, wouldn't you?
Quote:
The main thing I'm testing here is..."CAN you cover a glitch with sprites?" And the anwer is yes.
Well, yeah... but is it practical? If the area affected by the glitch isn't just a flat color, you'll still be losing details by covering it with a flat line. You also have to make sure that you have the necessary color available somewhere in your sprite palettes. Also, depending on how large the area affected by the glitch is, the sprites you use could greatly increase sprite flickering near the split.
Quote:
I feel like this is also a good test of emulators of PPU behavior, since half of the emulators I tested didn't look the same as real NES.
Yeah, every time I tried to align things to hblank, emulators would disagree. Nestopia used to give me the most consistent results compared to the real hardware, but it's been a while since I needed this kind of precise timing.
Quote:
I might try again, see if I can hide it in the hblank (again, without a MMC3 scanline counter). I haven't had great success with that, yet.
Make sure to do most of the work beforehand, and have the values for the last 2 writes ready and loaded into different registers so that the last 2 writes can be performed as quickly as possible. Then you just move the whole code using NOPs until there are no more glitches. I used
this code in the past, and once it was properly aligned to hblank there were no glitches at all.
Quote:
The idea is that, in a game, you should be able to do logic before and after the split, so, perfectly timed code only helps in a demo like this.
Again, if you're that lost, it's not a few sprites that will give you a steady split. If your timing is really off you can even end up with the part after the split jumping up and down, in case you can't guarantee that the split happens always before or always after the PPU automatically increments the vertical scroll.
If you don't have mapper IRQs, there are 3 basic ways to time raster effects: sprite 0 hits, sprite overflow, and timed code. There's also the DMC IRQ, but that's a totally different beast. Anyway, none of these 3 synchronization techniques introduces enough jitter to make landing a 5-cycle sequence in a 19-cycle window impossible. They can add a delay of 7 or 8 cycles, which still leaves you with 6 or 7 cycles of padding.
What other synchronization techniques are you thinking of that are not precise enough to allow syncing with hblank but will still result in a predictable amount of glitches that can be covered with sprites?