How to hide vertical scrolling updates with no status bar?

[GradualGames]

I just got another idea, what do you guys think of this:

-Use bankswitchable CHR-RAM
-Upload all solid tiles in one of those banks, which select colors with matching luminosity in all four, four color palettes
-Be switched to the all solid bank at end of vblank, and set the monochrome bit
-Run sound engine code (but be sure that worst case, all music and effects won't take a very long time)
-Wait for sprite 0 hit at 16th scanline (or maybe later, to account for worst case sound engine updates)
-Switch to whatever should be the active CHR-RAM bank for normal graphics (still lets me use 3 frames of animation for background, should be fine)
-Clear the monochrome bit.

If one could somehow guarantee that the luminosity is the same for say the third color of every four color sub palette, it seems like using the monochrome bit would get rid of the attribute glitches tokumaru mentioned. I certainly don't care what the color of the "hiding bar" is, just that it works and looks stable! *edit* The primary disadvantage of course would be having to make sure your palettes always work with this scheme. It might not be as bad as ensuring that one color of every four color sub-palette would have to match luminosity, because I think setting the monochrome bit does not get you 4 luminosities of gray, I recall at least two of them always collapsing together and showing the same gray.

[tokumaru]

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

Two reasons:
1 - keeping the background enabled will allow you to use a sprite 0 hit to sync with the PPU (i.e. no constant-timed VBlank);
2 - after the sprite hit, sprites can be masked without fully disabling rendering or needing dummy high priority sprites;

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.

That's pretty extreme, but much better looking than the solid tile in Big Nose Freaks Out.

[tokumaru]

SDTVs tend to hide about the top 12 and bottom 4.

I observed something like this in My TVs as well, which is why it doesn't bother me to hide a significant amount of scanlines at the top only, instead of hiding scanlines at the bottom too.

Is this only noticeable on an actual TV?

On actual TVs or emulators that use blargg's NTSC filter.

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?

The alternate dot crawl will only happen if both background and sprites are disabled (the PPU only "shuts down" if both are disabled, otherwise it functions as normal and just doesn't display the layer that's turned off). If you're keeping sprites enabled you don't have to worry about it. Disabling the PPU for good (both sprites and BG) has the annoying side effect of corrupting OAM (this was discovered by tepples a while ago) unless you obey some mystical conditions (like the exact point in the scanline where you do it or which sprites are visible in that scanline).

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?

To update the palette you have to fully disable rendering, so you run into that OAM corruption issue again. Also, you'll have to reset the scroll with $2005/6 magic after changing the palette.

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

Without an scanline counter, the most common way to sync with the PPU is with sprite 0 hits: the PPU sets a bit when a solid pixel in sprite 0 overlaps a solid pixel in the background. If the game scroll horizontally and vertically, it gets hard to guarantee that there will be a solid background pixel where the sprite is unless you intentionally put a solid tile there. This is what this game does, and it ends up looking like an annoying glitch.

and set the monochrome bit

Now there's a good idea! Having to use a constant luminosity at a certain palette slot is not such a bad limitation. Sounds to me like a great solution.

[tepples]

Disabling the PPU for good (both sprites and BG) has the annoying side effect of corrupting OAM (this was discovered by tepples a while ago) unless you obey some mystical conditions (like the exact point in the scanline where you do it or which sprites are visible in that scanline).

Mystical nothing. It takes 64 dots to start the sprite evaluator each line, 128 to check whether all are in range, and 6 more for each that is in range. If all 8 are in range, that's 240 dots, so if you can turn it off between 240 and 255 you're golden.

[Bananmos]

Mystical nothing. It takes 64 dots to start the sprite evaluator each line, 128 to check whether all are in range, and 6 more for each that is in range. If all 8 are in range, that's 240 dots, so if you can turn it off between 240 and 255 you're golden.

Have you confirmed that turning it off between dot 240-255 actually prevents all glitches? That range does seem a lot more forgiving to time to than the current dot 330 I've been using...

[MottZilla]

I think you should just leave the "glitches" because commercial games have them but generally they are so on the edge you don't see them plus if the screen is moving it distracts the players from the glitches if they are appearing on the opposite side of travel, so if you are going up the glitches should show on the bottom and vice versa.

I don't think it is worth an overly complex solution to hide minor graphics glitches.

Also wouldn't just wiring up a SRAM for 4 screen mirroring solve the issue too? Seems that either of those are preferable to trying to rig up a complex routine to hide it.

[3gengames]

The first page, they said $1 was not worth fixing it. Heh. But yeah, SMB3 has huge scrolling glitches on the side, I always noticed....boo.

[Sik]

SMB3 doesn't seem to put any serious effort on hiding those glitches though, if at all. It just waits for the 16 pixel column to be fully visible and then sets the palette - blatantly noticeable. At least it disables the leftmost 8 pixels column so the glitches are only in the palette and not in the tiles (also it's doing horizontal mirroring, here we're looking for vertical mirroring).

[tokumaru]

I think you should just leave the "glitches" because commercial games have them but generally they are so on the edge you don't see them

I ALWAYS see them, it's like they're screaming at me.

plus if the screen is moving it distracts the players from the glitches if they are appearing on the opposite side of travel

To me it's the exact opposite, the glitches distract me from the game action. Humans can only focus on small spots, and we use our blurry peripheral vision to detect movement, and when that happens we move our eyes to focus on the area where the movement occurred. When I'm playing and some blocks suddenly change color at the edge of the screen, my brain thinks something is happening over there, so I look at the glitches. My peripheral vision keeps noticing them, and they keep distracting me... I actually have to force myself to ignore the popping colors in order to play games like SMB3 and Kirby's Adventure (which I love, despite this problem). I don't know if this is just me, but it's enough for me to not want this in my own games.

I don't think it is worth an overly complex solution to hide minor graphics glitches.

Vertical glitches are minor only in NTSC I think, I remember people saying that they are very noticeable on PAL.

Also wouldn't just wiring up a SRAM for 4 screen mirroring solve the issue too? Seems that either of those are preferable to trying to rig up a complex routine to hide it.

If you're using CHR-RAM and can use the same chip for name tables then I agree. But if you use CHR-ROM and need to hack another chip in, a software solution would be better.

SMB3 doesn't seem to put any serious effort on hiding those glitches though, if at all. It just waits for the 16 pixel column to be fully visible and then sets the palette - blatantly noticeable.

It really bothers a lot that some high profile games such as SMB3 (widely considered the best NES game ever) and Kirby's Adventure settled for this.

[GradualGames]

4-screen mirroring would definitely be ideal. So far, I have relied on retrousb for production of cartridges and will probably continue to. If it is as cheap as you guys have mentioned here in this thread, I'll proably go that route. I have a vague memory though of being told that could be more expensive than 1$, but I'll have to look into it again.

If that doesn't work though, yes, I am tempted to just leave it as-is and rely on NTSC overscan. I have one crt tv which just barely shows the top of the updated row at the bottom of the screen. It's not even as bad as SMB3 or Kirby, so I'll probably be happy with this if none of these other solutions pan out. I definitely am enjoying learning how to make this work should I choose to stick with it, though.

Tokumaru, why are you not happy with NTSC overscan the way Super Bat Puncher does? Just that some tvs might show a little of the updates?

[Bregalad]

4-screen mirroring can't hide the sprites-pop up glitches at the left nor at the top of the screen.

As I said the only way to get 100% clean scrolling is to hide the leftmost and top most 8 pixels. Then, if vertical mirroring or 8x16 sprites are used (or both), the top 16 pixels should be hidden, otherwise, if horizontal mirroring is used there should instead hide the right most 8 pixels too with sprites.

Therefore, the only purpose of 4-screen mirroring is that you could hide only the left 8 and top 8 pixels if you use 8x8 sprites, and if you use 8x16, there is no difference whenever you use 4-screen or vertical mirroring (since you should hide the top 16 scanlines anyways).

Now whenever you actually want 100% clean scrolling is another story.

[GradualGames]

For the sake of simplicity, I had meant to constrain this thread to just background scrolling. I don't care as much about sprite popping because that's so brief and near the edge of the screen. But if the whole updated row of a nametable is visible you have a veritable light show on your hands. So, if I end up perfecting any of those issues, it will be scrolling.

[Bregalad]

I don't understand why people would be bothered by glitches on the background, but not on the sprites.

Attributes clashes on a scrolling BG are also "so brief" and "near the edge of the screen", yet people seems to find them unacceptable.

That being said I perfectly respect that you'd make such a choice, I was just pointing out that if you aim for perfect scrolling, sprites should be taken into consideration, too, because yes, this is noticeable, and probably moreso than 3 pixel attributes clashes on a horizontal scrolling BG using horizontal mirroring such as in my demo.

[tokumaru]

4-screen mirroring would definitely be ideal. So far, I have relied on retrousb for production of cartridges and will probably continue to. If it is as cheap as you guys have mentioned here in this thread, I'll proably go that route.

I believe that if you use CHR-RAM (and the CHR-RAM chip is at least 16KB - most are I think, 8KB RAMs are pretty rare nowadays), it's just a matter of keeping the CHR chip always enabled and the internal CIRAM always disabled, you just need to change 1 or 2 connections, so AFAIK the cost is $0. CHR-ROM makes things more complicated, because you have to add an extra chip and select between it and the CHR-ROM.

Tokumaru, why are you not happy with NTSC overscan the way Super Bat Puncher does? Just that some tvs might show a little of the updates?

Things don't look so bad in Super Bat Puncher, because it has very dark backgrounds. Most of my projects have pretty sunny levels, which makes the glitches more noticeable. Also, from what I've heard, PAL consoles/TVs don't crop any of the picture at the top and bottom, so all glitches are fully visible.

[3gengames]

[Off topic post.] Sprites 1. Show up 100% and correctly. 2. Aren't clearly visible for lots of frames. 3. Can be eliminated by game design ad not having enemies come from the top?

But still, if you use CHR-RAM for the 4 screen, you'll be giving up lots of space in the RAM. But it's not too bad. Stick a 16KB RAM on there and have at it, I guess?

But still, IMO, software patching and making the screen off-center just to fix it are worse design choices than giving up a tiny bit of your profit. If you're not using custom boards, then software is the best way. But if you can develop a PCB, then just stick a 4KB RAM in a devtendo and start going at it.