Games with black bars on top and bottom

You can talk about almost anything that you want to on this board.

Moderator: Moderators

User avatar
DRW
Posts: 2225
Joined: Sat Sep 07, 2013 2:59 pm

Games with black bars on top and bottom

Post by DRW »

I'm playing with the thought of doing this for my game, so I'd like to know:

Are there any commercial NES games that used the MMC3 IRQ during vertical scrolling to disable rendering in the first and last few rows?
The reason to do this: Due to TV overscan, it might be problematic to allow a character to move completely to the top or to the bottom of the screen since he might not be visible anymore. But if you set a hard line that the character cannot cross, then it might feel unnatural that you see a gap between a wall and the screen bottom, but the character cannot move between it, even though he would usually fit.

So, to overcome this, you could simply disable rendering for the first and last 16-24 pixel rows and make this the playfield border. This way, the character is never blocked from moving to visible parts of the screen, but he's not in danger of moving to the offscreen area either.

Of course, if you have a status bar, this is a non-issue, at least for one side of the screen. But did any games that didn't have a status bar ever reduce the visible screen by adding black bars?
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Games with black bars on top and bottom

Post by tokumaru »

The only game I can mention off the top of my head is Jurassic Park. This is probably related to scrolling artifacts though, and has nothing to do with gameplay. Overscan is not a problem for most games, which have a moving camera and will usually keep players mostly centered unless they're near the edges of the level.
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: Games with black bars on top and bottom

Post by Fiskbit »

There are risks to doing this, as turning rendering off mid-screen will typically corrupt 1 row of OAM (2 sprites) when rendering starts again. There is a safe window for it, but it's about the same size as the amount of jitter you'll have from your IRQ. Turning rendering on mid-screen rather than during vblank can make the problem even worse, as there's a large region in the visible portion of the scanline that is safe for turning off rendering if you turn rendering back on at the start of a dot (which reliably happens when vblank ends), but which causes other sprite problems if rendering is turned back on mid-dot on some alignments.

Isolated Warrior and Recca are examples of games that turn rendering off early and have OAM row corruption as a result.
User avatar
DRW
Posts: 2225
Joined: Sat Sep 07, 2013 2:59 pm

Re: Games with black bars on top and bottom

Post by DRW »

tokumaru wrote: Sat Jul 09, 2022 6:33 am Overscan is not a problem for most games, which have a moving camera and will usually keep players mostly centered unless they're near the edges of the level.
I'm talking about games that have no back-scrolling: If the character can move to the screen border, he may disappear into the overscan area of the TV. But if you stop his track at an arbitrary point, it might feel unnatural that he cannot move further down, even though it looks like there's still room.

Fiskbit wrote: Sat Jul 09, 2022 11:34 pm There are risks to doing this, as turning rendering off mid-screen will typically corrupt 1 row of OAM (2 sprites) when rendering starts again.
Good to know.

My current solution is this. Are there any potential problems with it or is it safe:

I prepare an IRQ for a scanline somewhere at the bottom of the screen. There, I disable the background rendering, but not the sprites. This way, I have a black border where I can place sprites to serve as a simple-looking status bar.
(In case of a lag, the NMI takes care of correctly resetting the PPUMASK value.)
Since characters move into the "status bar", I simply put eight invisible sprites there, so that any other characters aren't rendered.


Here's another question: Is it safe to set the PPUMASK valuemid-frame if I don't actually change the values? So, if PPUMASK is set with the value $00011110 and in the middle of gameplay, I write:

Code: Select all

LDA #$00011110
STA $2001
is this alright or can there be any glitches as well?
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Games with black bars on top and bottom

Post by tokumaru »

If you're worried about OAM corruption, dot crawling or other hardware quirks, you can still pull off the effect of disabling rendering without actually doing it - just use CHR bank switching to map blank tiles across the whole pattern table. This is what Jurassic Park does (at least at the top, I don't remember about the bottom). If you're only interested in the effect, not the extra VRAM bandwidth that comes with forced blanking, this is probably the safest option.

The tricky part is that you need 6 MMC3 commands to switch all the patterns, and you can't do all of that in hblank. One option is to use $2001 to blank only the layer that requires more MMC3 writes (the one that uses 1KB windows) so you only actually need to switch 2 banks, in addition to enabling/disabling that other layer.
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: Games with black bars on top and bottom

Post by Fiskbit »

As long as you don't disable both backgrounds and sprites, you're good except on the very earliest PPUs, which are uncommon. On the RP2C02A (and presumably RP2C02), any write to $2001 causes rendering to briefly disable before the written rendering values take effect. Pre-E PPUs have one benefit in the safe area for avoiding OAM corruption when turning off rendering is much larger, but since most PPUs are E or later (there are only about 2 million D and earlier NTSC PPUs, and about 200k A's). Basically, I'd keep in mind that writes to $2001 mid-screen can cause problems on rev A and work around it if it's not too hard, but wouldn't lose sleep over it not working perfectly there.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Games with black bars on top and bottom

Post by lidnariq »

Fiskbit wrote: Sun Jul 10, 2022 3:21 pm As long as you don't disable both backgrounds and sprites, you're good except on the very earliest PPUs, which are uncommon. On the RP2C02A (and presumably RP2C02), any write to $2001 causes rendering to briefly disable before the written rendering values take effect.
... could you test to see if writing to $3F01 fixes that?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Games with black bars on top and bottom

Post by tokumaru »

Man, these early PPUs are a pain! Many of the games I personally debugged don't seem to care about these obscure bugs at all, so I'm okay with not worrying about them either.
Drag
Posts: 1615
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: Games with black bars on top and bottom

Post by Drag »

If you're willing to implement the screen-splitting logic for a status bar (even if you don't actually make it function as one), you can simply keep two blank rows in your "status bar" region and use $2006 writes to blank the top and bottom of the screen.

If you make a "real" status bar, your blank rows will naturally be the top of bottom margin of it, depending on whether it's a top or a bottom status bar; you'd just also output that margin again on the opposite side of the screen.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Games with black bars on top and bottom

Post by Dwedit »

MC Kids blanks out the bottom 16 pixels to hide scrolling glitches, but does not hide the top. There are a few areas which scroll only horizontally or do not scroll at all, those do not mask the bottom.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
User avatar
DRW
Posts: 2225
Joined: Sat Sep 07, 2013 2:59 pm

Re: Games with black bars on top and bottom

Post by DRW »

tokumaru wrote: Sun Jul 10, 2022 8:08 am just use CHR bank switching to map blank tiles across the whole pattern table.
I don't think I really want to do that.

Fiskbit wrote: Sun Jul 10, 2022 3:21 pm As long as you don't disable both backgrounds and sprites, you're good except on the very earliest PPUs, which are uncommon.
From when are these PPU revisions? Are they just Japanese or also American?
And are there any commercial games that show different behavior on these PPUs?


The reason why I asked whether I can write to PPUMASK mid-frame if I simply write the same value that's already active was the following:

I have two types of mid-screen scanline split: One for dialog boxes (where I replace a graphics bank, but where rendering doesn't get disabled). And one for the black border (where background rendering gets disabled).

And I wanted to know whether I can simply do

Code: Select all

PHA

LDA MidFramePpuMaskValue
STA PPUMASK
as the first thing in my IRQ function. In the case of the dialog box, MidFramePpuMaskValue would simply include the value that's already in PPUMASK anyway. So, the write would be redundant, but it would be done anyway to save some time and to make sure that the write happens as early as possible.

But if there are revisions where any mid-frame write to PPUMASK might produce a glitch, I should probably rather do this:

Code: Select all

PHA

LDA MidFramePpuMaskValue
CMP #MidFramePpuMaskValueForBlackBorder
BNE @dialogBox

STA PPUMASK
...

@dialogBox:
; No STA PPUMASK
...
Drag wrote: Sun Jul 10, 2022 10:50 pm If you're willing to implement the screen-splitting logic for a status bar (even if you don't actually make it function as one), you can simply keep two blank rows in your "status bar" region and use $2006 writes to blank the top and bottom of the screen.
Actually, I'm doing the opposite now: I disable background rendering mid-frame and then I use that black border as a status bar where the status values themselves are all sprites.

I remember that some years ago I tried to implement a proper status bar with vertical scrolling and it was a pain in the ass. That's why I decided to do completey without any status bar for my game, only showing some rudimentary status values as free-flowing sprites, "Mega Man"-style.
But now when I thought about making a black border at the bottom of the screen to prevent the player character from walking into the overscan area, I got the idea that I could just as well use this black border as an easy to implement pseudo status bar.

Do you see anything that might speak against this idea?
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: Games with black bars on top and bottom

Post by Fiskbit »

lidnariq wrote: Sun Jul 10, 2022 3:50 pm
Fiskbit wrote: Sun Jul 10, 2022 3:21 pm As long as you don't disable both backgrounds and sprites, you're good except on the very earliest PPUs, which are uncommon. On the RP2C02A (and presumably RP2C02), any write to $2001 causes rendering to briefly disable before the written rendering values take effect.
... could you test to see if writing to $3F01 fixes that?
That's a really smart idea. I modified CutterCross' CrossPaint to write to $3E01 instead of $2001 and the rendering-disable glitches went away, so you're right. It's taking the value too early.
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: Games with black bars on top and bottom

Post by Fiskbit »

DRW wrote: Mon Jul 11, 2022 2:09 pm From when are these PPU revisions? Are they just Japanese or also American?
And are there any commercial games that show different behavior on these PPUs?
Pre-E NTSC PPUs are found almost exclusively in square-button Famicoms, which were the first 2 million units. There aren't known to be any in any model other than the RF Famicom. They're not exactly rare, but there are around 54 million NTSC consoles.

The PPUs with $2001 write issues are just the first 200,000 or so Famicoms. lidnariq just identified that there is a workaround: If you know what the values of the rendering bits are, you can OR the high byte of the PPU mask address with those bits. So, if rendering is on and you're writing to $2001, you can write to $3E01, instead, to avoid the unexpected rendering toggle.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Games with black bars on top and bottom

Post by lidnariq »

Seems likely that none of the registers are synchronized to end-of-write in the 2C02A, then.

It would be interesting to see what the other six bits do with glitchy writes (since the "blue" and "monochrome" bits are still glitchable in the 2C02G)
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Games with black bars on top and bottom

Post by Dwedit »

Final Fantasy 1 is known to use timed PPUMASK writes to do the light beam effect when you get a crystal. What would the failure condition look like on a square button Famicom? Is there no failure condition because there is no forced blanking?
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Post Reply