How to hide vertical scrolling updates with no status bar?

[Bregalad]

I found a different solution: to completely hide scrolling glitches, I needed to blank 16 scanlines. Due to the difficulty of dividing that amount between the top and the bottom of the screen, I decided to hide them all at the top (looks pretty good on my TV, at least).

I'd just add this is the only way to have 8x16 sprites cleanly getting in and off the screen on the top border. Since sprite's coordinate can't be signed (anything from $f0 to $ff is considered a disabled sprite), it is impossible to have a sprite partially in the screen, and having the sprites "pop-up" can be noticeable, especially with 8x16 sprites. This can be even more annoying than attribute clashes.

So in order to have 100% clean scrolling for both BG and sprites it is required to :
- Enable the left border clipping
- Find some way to disable graphics on the top 16 pixels by one of the ways mentioned in this thread (or top 8 if 8x8 sprites are used)

And this no matter what mirroring is used.

[MottZilla]

You could actually have a memory mapper high the top and bottom lines for you automatically by having it pay attention to the PPU bus like the MMC5 does. That would be kind of cool. Though I think an IRQ is the best way to go, combined with setting the graphics banks to all blank tiles. But if you can make it work with less, go for it as long as it works well. It's amazing what RARE did with discrete mappers and CHR-RAM.

[tokumaru]

Though I think an IRQ is the best way to go, combined with setting the graphics banks to all blank tiles.

Jurassic Park does this. It's a very clean solution if you have a scanline/cycle counter available. You can still use this easily at the top of the screen without an scanline counter if you have a way to count cycles from the top of the screen (VBlank is constant timed or you detect the start of the frame waiting for the overflow or sprite 0 hit flags to clear).

It's amazing what RARE did with discrete mappers and CHR-RAM.

They didn't care about the alternate dot crawl pattern, though. I think it looks OK for static images, but scrolling left and right produce different effects that bother me a bit.

[Dwedit]

What do you need the blank tiles for, when you can simply disable rendering backgrounds, but keep rendering sprites?

Anyway, the king of status bars on discrete hardware is Fire Hawk, which is driven entirely by DMC IRQs once it uses sprite 0 to synchonize them properly. But honorable mention also goes to Time Lord and Wizards and Warriors III. Wizards and Warriors III makes a copy of one of the tiles to add a dot to that tile, then makes sprite 0 (another dot) hit that tile. Time Lord does that, and also uses DMC IRQs to ensure that the code to wait for the sprite 0 hit is called.

[Bregalad]

What do you need the blank tiles for, when you can simply disable rendering backgrounds, but keep rendering sprites?

This. Since sprites can be hidden with 8 high priority sprites, it's perfectly possible to hide both BG and sprites without disabling graphics and without wasting a CHR-ROM page with blank patterns.

[GradualGames]

-Upload all solid tiles in one of those banks

A pattern table filled with solid tiles will result in attribute glitches, because each palette uses different solid colors. Unless you decide to make one of the colors always the same, which is a huge waste IMO, since they all share color 0 already. Two unique colors per palette is a pretty serious restriction if you ask me.

Dangit, I didn't think of this. It's starting to look like my only option given my setup may be cycle timed code. Which, I don't think will be that bad. And, I thought more on it and I think as you may have already pointed out, the 9 sprite trick may be useful for graceful sprite clipping, too (in other words, if I'm not using it for sprite 0 hit, I can still use it just for sprite clipping and nothing else). Thanks.

*edit* At one point, I was feeling hopeful that the palette itself could be bankswitched out using bankswitchable CHR-RAM. But, I believe the palette maps to registers in the ppu itself, you can't have a CHR-ROM palette for example?

And, part of me is tempted to just simply never bother and rely on NTSC overscan. Problem is, I've already seen this not work as well as one might like on some TVs.

[tepples]

HDTVs hide the top 8 and bottom 8 lines; SDTVs tend to hide about the top 12 and bottom 4.

But there's one way to stop attribute glitches cold: a row of blank tiles at the scroll seam. This row can sit well within the NTSC overscan.

[GradualGames]

They didn't care about the alternate dot crawl pattern, though. I think it looks OK for static images, but scrolling left and right produce different effects that bother me a bit.

Is this only noticeable on an actual TV? I hadn't noticed anything odd using cycle timed code to black out graphics for the top 16 or so scanlines within an emulator. I must have something else wrong though because on FCEUX, some actual previously uploaded CHR data seemed to get corrupted---but it was fine on Nestopia and Nintendulator (granted, my very quick try has not been smoothed out yet.)

Is dot crawl a fairly subtle effect? From a little bit of reading, it sounds like that subtle jagged edge effect one can see in a composite signal. If it just juggles that pattern a bit, I can't imagine finding this too bothersome.

*edit* also, how bad would it look to actually upload a black palette before end of vblank, and then upload the correct palette (after waiting with cycle timed code)? If it just produces a one pixel wide glitchy looking line, I might actually be ok with this. Or is there another gotcha there? Hmm, if that can work, maybe hide the glitchy line with 9 sprites? (assuming the glitchy part of the line is short enough to be covered by all of these) This could eliminate dot-crawl problem by leaving graphics on but also help with sprite clipping at same time perhaps?

[Bregalad]

Is this only noticeable on an actual TV?

Yes, if at the end of the VBlank the graphics are disabled the dot who is skipped every other frame is never skipped. Then it makes the image looks as crappy as Sega consoles

[GradualGames]

Is this only noticeable on an actual TV?

Yes, if at the end of the VBlank the graphics are disabled the dot who is skipped every other frame is never skipped. Then it makes the image looks as crappy as Sega consoles

I wonder if I could use the 9 sprite trick tokumaru mentioned to detect the beginning of a frame, and THEN turn off graphics, then wait with cycle timed code, then turn them back on. Is that another possible way to eliminate dot crawl as well? Or is that exactly the trick tokumaru mentioned and I'm now understanding all of the edge cases it addresses?

[Bananmos]

I wonder if I could use the 9 sprite trick tokumaru mentioned to detect the beginning of a frame, and THEN turn off graphics, then wait with cycle timed code, then turn them back on. Is that another possible way to eliminate dot crawl as well? Or is that exactly the trick tokumaru mentioned and I'm now understanding all of the edge cases it addresses?

That's pretty much what I've done for my own game recently - you can find some interesting points about how I solved it at the end of this thread.

As the topic suggests, disabling rendering triggers a nasty bug on NTSC NESes which causes corruption of sprites the next time you enable it. But if you turn off rendering around dot 330 then AFAICT this will always affect sprites 2 and 3 only, so you can avoid the sprite corruption by just starting your sprite page write pointer at a higher offset. But I cannot stress enough that if you write code where timing is this important to avoid a hardware quirk you should in no way rely on emulators for testing its correctness.

Also, if you have a sprite#0 hit that gets triggered in every frame then you don't need those 9 blank sprites you mentioned since you can wait for the start of vblank just by waiting for this flag to get cleared again.

[GradualGames]

I wonder if I could use the 9 sprite trick tokumaru mentioned to detect the beginning of a frame, and THEN turn off graphics, then wait with cycle timed code, then turn them back on. Is that another possible way to eliminate dot crawl as well? Or is that exactly the trick tokumaru mentioned and I'm now understanding all of the edge cases it addresses?

That's pretty much what I've done for my own game recently - you can find some interesting points about how I solved it at the end of this thread.

As the topic suggests, disabling rendering triggers a nasty bug on NTSC NESes which causes corruption of sprites the next time you enable it. But if you turn off rendering around dot 330 then AFAICT this will always affect sprites 2 and 3 only, so you can avoid the sprite corruption by just starting your sprite page write pointer at a higher offset. But I cannot stress enough that if you write code where timing is this important to avoid a hardware quirk you should in no way rely on emulators for testing its correctness.

Also, if you have a sprite#0 hit that gets triggered in every frame then you don't need those 9 blank sprites you mentioned since you can wait for the start of vblank just by waiting for this flag to get cleared again.

What if we never disable rendering, upload a black palette by the end of vblank, then wait for enough cycles to black out the top 16 scanlines, and then upload the correct palette? I would expect some part of a scanline at the bottom of the blacked out 16 pixel wide bar to show the palette gradually come in and this line might look odd. But, I was thinking, maybe sprites could be used to hide this. I wonder how well this would work? Has anyone tried this?

[Bananmos]

What if we never disable rendering, upload a black palette by the end of vblank, then wait for enough cycles to black out the top 16 scanlines, and then upload the correct palette?

Yeah, I guess that would work. Though you would miss the opportunity to use the black area for PPU updates. And you'd still need to disable rendering when uploading the "real" palette, so the hardware quirk would still have to be handled.

I would expect some part of a scanline at the bottom of the blacked out 16 pixel wide bar to show the palette gradually come in and this line might look odd. But, I was thinking, maybe sprites could be used to hide this. I wonder how well this would work? Has anyone tried this?

Not doable, simply because updating the palette requires you to turn off rendering in the first place.
(in addition, turning rendering off will make sprites invalid for the next scanline)

[GradualGames]

What if we never disable rendering, upload a black palette by the end of vblank, then wait for enough cycles to black out the top 16 scanlines, and then upload the correct palette?

Yeah, I guess that would work. Though you would miss the opportunity to use the black area for PPU updates. And you'd still need to disable rendering when uploading the "real" palette, so the hardware quirk would still have to be handled.

I would expect some part of a scanline at the bottom of the blacked out 16 pixel wide bar to show the palette gradually come in and this line might look odd. But, I was thinking, maybe sprites could be used to hide this. I wonder how well this would work? Has anyone tried this?

Not doable, simply because updating the palette requires you to turn off rendering in the first place.
(in addition, turning rendering off will make sprites invalid for the next scanline)

I can't believe how deep the rabbit hole goes with this stuff, it is pretty staggering. Maybe I should just throw in the towel and make my game single-screen only, LOL. I'm tempted to just leave it as using NTSC overscan straddling the row update between the top and bottom 8 pixels. It'll look 99% ok on most TV's. I'm pretty sure Mega Man 1 uses the straddle technique when scrolling vertically. And I know Super Bat Puncher does, and it looks great.

I forget why you must have rendering off to upload the palette. I know I ran into this before and found I must always upload the palette either inside vblank or with rendering off, does it cause tearing in places other than the scanline currently being rendered? I can't remember.

[Sik]

Yeah, that's the problem. Have you ever played Big Nose Freaks Out? Watch the video and you'll see it keeps a solid tile at the bottom right corner at all times. The problem with this approach is that the tile itself ends up looking like a glitch, which doesn't make much sense considering that our purpose is to -hide- glitches (Big Nose probably does it for the extra VBlank time though).

What is the logic behind that tile? It seems to constantly move around o_O;

Jurassic Park does this.

Except it uses all-black tiles instead of blank tiles, which are very noticeable because they don't match the background color (which is used for the border!).

Since sprites can be hidden with 8 high priority sprites, it's perfectly possible to hide both BG and sprites without disabling graphics and without wasting a CHR-ROM page with blank patterns.

If you have the mapper do the hiding for you then you don't even need dedicated CHR-ROM tiles for that, just make the mapper return all zeroes... (of course this is starts making the circuit a bit more complex than what is already being discussed)