This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

4-way scroll without glitches nor raster effects

4-way scroll without glitches nor raster effects
by on (#38015)
I guess I have an idea to do multi-directionnal scrolling wihtout any glitches horizontally nor vertically, without using 4-screen mirroring and without wasting any CPU time during the frame (no raster effects).

However that requires mapper 118 (TLSROM or anything close to it), or mapper 5 (EXRAM not needed) or any mapper that can allow mapping of name tables individually.
Instead of doing the traditionnal "vertical" or "horizontal" screen arrangement, do a "chessboard" arrangement of them. So that screens are arranged as 0, 1, 1, 0.
Or in other words CIRAM A10 = PPUA10 COR PPUA11.

That way data can be drawn on the right of the screen without being imediately seen at the left (and vice-versa), and the same applies for top bottom. This works in theory when scrolling to any direction, but I don't know how well it works for scrolling diagonally (I guess it would have glitches in the border too). This could still be good for any game that scroll in 4 way but only 1 direction at the same time (RPGs for instance, using TKSROM this could be great).

by on (#38016)
It's a wonder more developers did not embrace the potential of 4-screen by simply adding external name table space. :-)

by on (#38017)
Actually, this is the reason I use vertical mirroring. Since I'm working with NTSC, the top and bottom rows of tiles won't be visible. This allows me to hide attribute glitches and whatnot, but I'm sure it'd be better to find an alternative if the top and bottom will be visible.

by on (#38020)
I hardly feel that rare mappers are a good solution, while you could go with the much more common MMC3 and use interrupts to help you hide possible glitches.

I also think that you shouldn't count on the fact the TVs will hide anything, because I have a couple of old TVs that make the glitches very visible. One shows too much of the top while the other shows too much of the bottom. As long as the NES is rendering the glitches, they'll be seen in a monitor or another. The only way to be 100% safe is to prevent the glitches from happening.

On the other hand, glitches have been visible in some of the most successful games (say, SMB3, with it's horizontal scrolling color glitches and glitchy status bar), so they couldn't have bothered many.

by on (#38025)
I actually like the glitches, they give the games distinguishable NES character.

by on (#38028)
I pretty much prevent my glitches from happening as much as I can. With both Vertical and Horizontal mirroring, visible attribute updates are inevitable. The only hope you have of hiding the updates is to use vertical mirroring and update when half of the attribute is in the bottom row, and the other half is in the top. I do think even if you have visible updates with Vertical Mirroring, it's MUCH better than having it with Horizontal. The player isn't paying as much attention to the top and bottom rows as they are columns, I think. I seem to recall seeing some glitches in CV2 when scrolling vertically, but it never bothered me as much as SMB3's scrolling.

by on (#38030)
Couldn't you also just do the checkerboard arrangements with raster effects in MMC3 via vertical mirroring?

by on (#38031)
Quote:
Actually, this is the reason I use vertical mirroring. Since I'm working with NTSC, the top and bottom rows of tiles won't be visible. This allows me to hide attribute glitches and whatnot, but I'm sure it'd be better to find an alternative if the top and bottom will be visible.

On my PAL TV, not only the top and bottom row are visible, but even with them the screen is taller than the image.
On the other side I belive the leftmost and possibly rightmost 4 pixels are hidden. It looks like vertical glitches are preferable for NTSC, but horizontal glitches for PAL.

Quote:
The only hope you have of hiding the updates is to use vertical mirroring and update when half of the attribute is in the bottom row, and the other half is in the top.

Final Fantasy and Dragon Warrior games do that. You so obviously didn't play the game with a screen that actually show the glitches. On my PAL monitor, Final Fantasy 2 and 3 are really looking bad when scrolling vertically. The glitches are very distracting when they are in the direction you are scrolling to. They are much less distracting if they are in the direction you are scrolling from, because you simply aren't likely to look here when playing.

Quote:
I hardly feel that rare mappers are a good solution, while you could go with the much more common MMC3 and use interrupts to help you hide possible glitches.

While commercial games using mapper 118 aren't common, you only need to change a signle wire from any MMC3 game to transfom it from mapper 4 to mapper 118. Since you need to change 6 wires anyway to do PRG and CHR rewiring, I bet it really doesn't change much. You could even place a switch that selects mapper 4 or mapper 118. So it's not really what I'd call a rare mapper.

Quote:
Couldn't you also just do the checkerboard arrangements with raster effects in MMC3 via vertical mirroring?

Definitely, by placing an IRQ on the exact same point than where the screen warps arround, and toggling $2000.0
But this is annoying to do when this point is near the top or bottom of the screen. Doing it on T*SROM would 100% free the CPU to do whathever it wants.
As tokumaru said, you can always trick to hide glitches with rasters, but this is somewhat annoying to do. Doing it that way would typically needs to hide BG (and possibly sprites) from the first 8 scanlines. You can't rely on the MMC3's counter to do that, and doing that with timed code will steal a lot of time that would otherwise be dedicated to game logic (especially on PAL where the VBlank is really long).[/quote]

PS : The status bar doesn't look glitched on my NES. I guess this is NTSC only. However what really looks terrible is that big blue bar on the left. This really look terrible. I guess when you enable clipping on the left, you should force BG color to black no matter what.

by on (#38034)
Why would MMC3 irqs be unreliable for the first 8 scanlines? The pre-render scanline does the same memory fetches as any other scanline.

Unless of course you're intentionally blanking them out to get more draw time...

by on (#38037)
I've seen Final Fantasy displayed as 32x28 tiles and as 32x30. The scrolling updates weren't that distracting. I agree that when glitches are in the direction that you're scrolling to, it's distracting compared to when they're in the direction you're scrolling from. With Horizontal mirroring vs. Vertical, there's a good chance you won't show glitches with vertical while with Horizontal it's almost inevitable to see glitches, especially with attributes. It would be nice if there was a clipping feature for both sides of the screen!

For SMB3, the worst attribute update glitch is when you go down the warp zone in level 1 world 1, and the blue blocks appear black and white.

by on (#38040)
Celius wrote:
With Horizontal mirroring vs. Vertical, there's a good chance you won't show glitches with vertical while with Horizontal it's almost inevitable to see glitches, especially with attributes.

No in fact it changes absolutely nothing. In both cases the screen size is exactly the size of a nametable both horizontally and vertically, so in both cases you see at best a 8-pixel nametable glitch and a 16-pixel attribute glitch.
However, with horizontal mirroring you can hide the 8-pixel nametable glitch and 8 of 16-pixel attribute glitch, so that only 8-pixel attribute glitches remain. With vertical mirroring, you'd have to rely on timed code to do the same.
I always design my palette so that it's colors : Black, dark, medium, light, and many games (not SMB3) does that. In that case the luminosity is the same even if the color is different, so glitches are less visible. Place them in the border the screen is scrolling from and they're almost invisible.

If that's not enough then you'd have to do what I describe above with TLSROM or simply use only one palette in your backgrounds (like W&W2), or rely on timed code/IRQs to hide glitches.

by on (#38042)
Bregalad wrote:
Final Fantasy 2 and 3 are really looking bad when scrolling vertically. The glitches are very distracting when they are in the direction you are scrolling to. They are much less distracting if they are in the direction you are scrolling from, because you simply aren't likely to look here when playing.

Which is why Kirby's Adventure made a point of keeping the glitches on the trailing edge, where SMB3 had them fixed to the right side.

by on (#38049)
Bregalad wrote:
As tokumaru said, you can always trick to hide glitches with rasters, but this is somewhat annoying to do. Doing it that way would typically needs to hide BG (and possibly sprites) from the first 8 scanlines. You can't rely on the MMC3's counter to do that, and doing that with timed code will steal a lot of time that would otherwise be dedicated to game logic (especially on PAL where the VBlank is really long).

This is not true. You don't have to disable rendering for the first 8 scanlines, you just have to use transparent patterns. I learned the trick from Jurassic Park, and "borrowed" it for my game. The PPU will be working as usual, everything will be rendered and the scanline counter will work perfectly, but since the patterns are transparent all you'll see is color 0, as if rendering was disabled. When the NMI fires you switch in the sctual patterns for the frame. This only costs you 2KB of 0's in your CHR-ROM. Of course this trick is impossible with CHR-RAM.

Jurassic Park doesn't actually use transparent tiles, it uses black tiles, because it has black at a fixed position in all palettes, but since I don't I went with the transparent version of the trick.

Quote:
PS : The status bar doesn't look glitched on my NES. I guess this is NTSC only.

The status bar itself isn't glitchy, but the top of it has a flickering scanline, like if they are messing with PPU stuff in the visible part of the scanline. Kirby also has a similar glitch. Play the NTSC versions in Nestopia and you'll see.

I just checked the PAL SMB3 and I saw the glitches, but they were on the right side of the screen and were much less intense than the ones in the NTSC version. Kirby's glitches seem to be just as bad in both versions.

I guess I can understand that developers back then couldn't test new builds as often as we can today with emulators, but it wouldn't have killed them to use the opportunities they had to fix the timing of the splits as well as testing other things.

Dwedit wrote:
Why would MMC3 irqs be unreliable for the first 8 scanlines?

He probably meant if rendering was disabled for those scanlines. Not for draw time, just for hiding glitches.