Question about black bars, again. . . .

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
iNCEPTIONAL

Question about black bars, again. . . .

Post by iNCEPTIONAL »

Can someone explain to me again, in very simple terms and plain English, why there's black bars in the game below, as in what benefit they're bringing to the table here and how they're helping the game run on SNES that just couldn't have been achieved without the bars:

https://youtu.be/5UdJwoY6Gps

Like, what would having the background full screen have actually done here that's so bad that the game had to have the black bars?

And, given it's possible to hack some SNES games with black bars to remove them and the game seems to run fine, as seen with the rom hack for Magical Quest 3 below, was this sometimes really just lazy design/programming in a lot of SNES games rather than an essential need to have the black bars in many cases?

https://www.romhacking.net/hacks/5216/
Last edited by iNCEPTIONAL on Sat Aug 13, 2022 4:12 pm, edited 4 times in total.
Myself086
Posts: 158
Joined: Sat Nov 10, 2018 2:49 pm

Re: Question about black bars, again. . . .

Post by Myself086 »

Either aesthetic or give more time during vblank so the game can upload more graphics per frame.

NES games do this sometimes too, I recently got Solstice to run on SNES and it performs a great amount of updates to its CHR RAM each frame so the sprites can be more animated than what can be held in VRAM. It's able to do this because the bottom of the screen is using the equivalent of "forced blank" of SNES. Solstice wouldn't have time to upload everything if it was full-screen.
iNCEPTIONAL

Re: Question about black bars, again. . . .

Post by iNCEPTIONAL »

Myself086 wrote: Sat Aug 13, 2022 9:03 am Either aesthetic or give more time during vblank so the game can upload more graphics per frame.

NES games do this sometimes too, I recently got Solstice to run on SNES and it performs a great amount of updates to its CHR RAM each frame so the sprites can be more animated than what can be held in VRAM. It's able to do this because the bottom of the screen is using the equivalent of "forced blank" of SNES. Solstice wouldn't have time to upload everything if it was full-screen.
Thanks.

So, is the forced blank really only required if you're switching in/out lots of graphics basically every frame on the fly then, for say detailed character animations, otherwise, there's pretty much no need for the black bars at the top and bottom of a game at all, outside of some purely [widescreen-style] aesthetic choice?

And does it make a difference if it's background or sprite tiles that are being switched in/out, given the SNES has specifically allocated amounts for each of these separately, like the sprites can only use 256 tiles normally?
Last edited by iNCEPTIONAL on Sat Aug 13, 2022 3:51 pm, edited 5 times in total.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Question about black bars, again. . . .

Post by dougeff »

I don't know what you're asking.

Every game has different needs and different troubles. There isn't a one-size-fits-all answer to these sorts of questions.

There's always a trade off, more of one thing means less of another thing.

Some of the things you notice in an emulator, and say "this looks bad" probably looked fine on a 1990s CRT that cut off several pixels on each side. The kids playing the games didn't care, and the developers didn't care.
nesdoug.com -- blog/tutorial on programming for the NES
TrekkiesUnite118
Posts: 92
Joined: Fri Mar 08, 2013 5:56 pm

Re: Question about black bars, again. . . .

Post by TrekkiesUnite118 »

I believe this is due to it being a port from Capcom's CPS1 hardware. CPS1 runs in the odd resolution of 384x224. So to preserve the aspect ratio and show as much on screen as possible on SNES's 256 wide resolution, Capcom typically letterboxed their ports on SNES. You can see this in just about all their CPS1 and CPS2 ports from Final Fight to Street Fighter Alpha 2.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Question about black bars, again. . . .

Post by tokumaru »

Black/blank bars are basically the simplest thing a game can do in order to gain more time to upload graphics to VRAM (on the NES and SNES, at least). For programmers back in the day this was a no-brainer, as you couldn't even put anything important near the edges of the screen anyway because TVs would hide varying amounts of scanlines in those areas.
Myself086 wrote: Sat Aug 13, 2022 9:03 amit performs a great amount of updates to its CHR RAM each frame so the sprites can be more animated than what can be held in VRAM.
Another very important reason for Solstice using CHR-RAM is that this allows the game to clip the sprites in real time as they go behind parts of the background... that's pretty impressive for an NES game!
iNCEPTIONAL

Re: Question about black bars, again. . . .

Post by iNCEPTIONAL »

OK, so, really, as long as I can try to avoid having to switch in/out too many new background/sprite tiles every frame, there's really no need to worry about having to use forced blanking, and I can have my game full screen no problem?

Does code has some relevance here too, and, so long as the code is well programmed and properly optimized, forced blanking wouldn't be needed to give the game a little more time to run whatever code in my shumup for the player, enemies, bullets and so on, which would maybe slow down the game otherwise if the game's trying to run too much at once in the frame? Or, does bad code just cause slowdown and wouldn't necessarily be helped with some forced blanking to give the game a little more time where nothing is being drawn or processed on the screen?

Do any other things also need to be taken into account to make sure forced blanking is never necessary, like the music and sfx too for example?

Thanks all.
Last edited by iNCEPTIONAL on Sat Aug 13, 2022 3:51 pm, edited 2 times in total.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Question about black bars, again. . . .

Post by Pokun »

Code: Select all

 Period:         Work:
 
 -------------
 |           |   Logic processing
 |           |   Logic processing
 | Frame 1   |   Logic processing
 |           |   Logic processing
 |           |   Logic processing
 -------------
   VBLANK        Video updates
 -------------
 |           |   Logic processing
 |           |   Logic processing
 | Frame 2   |   Logic processing
 |           |   Logic processing
 |           |   Logic processing
 -------------
   VBLANK        Video updates
 -------------
 |           |   Logic processing
 |           |   Logic processing
 | Frame 3   |   Logic processing
 |           |   Logic processing
 |           |   Logic processing
 -------------
   VBLANK        Video updates
      .
      .
      .
This is how the model normally looks like. The video chip is what sets our timing constraints since we can only update the video during vblank, hblank (though very limited) and fblank, but let's forget about hblank for this explanation. When the scanline is within a frame we can't update the video, sprites or tiles doesn't matter, neither can be changed during the active display time, only the logic processing (which means about everything else that the program does) can be done.

Vblank time is a very short period between each frame, so say that we have a game that has a lot of video data to upload or other video-related changes to make, but is able to finish its logic processing pretty early, it would be nice if we could give some frame time to the vblank time to fit the game's needs better. In this case fblank can be used to artificially increase the blanking time and thus extend the video update possibilities. As soon as you enable fblank, the screen will be black (thus blanking) from wherever the scanline is at the moment. Super Mario Kart does so in the middle of the two screens which is the black middle bar, but it disables fblank right away which resumes drawing of the screen after that to draw the bottom screen for P2 or the map/rearview-mirror in single-player modes.
If used to extend vblank we simply turn on fblank at some point near the bottom of the frame when the logic is done this buys more time to upload more video data.

Code: Select all

 Period:         Work:
 
 -------------
 |           |   Logic processing
 |           |   Logic processing
 | Frame 1   |   Logic processing
 |           |   Logic processing
 -------------
   FBLANK ON     Video updates
   VBLANK        Video updates
   FBLANK OFF    Video updates
 -------------
 |           |   Logic processing
 | Frame 2   |   Logic processing
 |           |   Logic processing
 -------------
   FBLANK ON     Video updates
   VBLANK        Video updates
   FBLANK OFF    Video updates
 -------------
 |           |   Logic processing
 | Frame 3   |   Logic processing
 |           |   Logic processing
 -------------
   FBLANK ON     Video updates
   VBLANK        Video updates
   FBLANK OFF    Video updates
      .
      .
      .
Here we enabled fblank during the bottom part of the frame (some time before the vblank period starts) and disables it again during the top part of the next frame (some time after vblank period has already ended). So there are less screen but more combined vblank and fblank time which means more video content updates is possible.

Video updates mainly means changing anything visually on the screen, so sprites and tiles are all included.

And yeah if you can optimize the video update code to be faster, you may be not need to do this.
iNCEPTIONAL

Re: Question about black bars, again. . . .

Post by iNCEPTIONAL »

OK, that makes sense. Thanks for that.
iNCEPTIONAL

Re: Question about black bars, again. . . .

Post by iNCEPTIONAL »

Pokun wrote: Sat Aug 13, 2022 3:44 pm Video updates mainly means changing anything visually on the screen, so sprites and tiles are all included.

And yeah if you can optimize the video update code to be faster, you may be not need to do this.
So, could one way to optimize for this, if you're trying to push a decent amount of visual stuff and switch in/out a bunch of tiles for more animation and the like without the need for forced blanking, be to only update some of the non-essential things like the enemy animations at 30fps rather than 60fps and split the amount you have to update over the two frames rather than trying to do it all in one as you normally might for something essential like the player, as an example?
Last edited by iNCEPTIONAL on Sat Aug 13, 2022 3:58 pm, edited 1 time in total.
Myself086
Posts: 158
Joined: Sat Nov 10, 2018 2:49 pm

Re: Question about black bars, again. . . .

Post by Myself086 »

Don't worry about forced blanking. Just make your assets and when it comes time to put everything into an actual SNES game, just talk with your programmer about what can be done to ensure no forced blanking.

It's possible to lower frame rate on animations as needed (game adjusts it on the fly) without slowing gameplay down and without missing a single scanline. Gameplay slowdowns are based on how many things are going on at once but it's possible to multiply everyone's movement to compensate for lack of CPU cycles, Goldeneye and Mario Kart 64 do this to some extent. Lag frames can be compensated by enabling turbo mode to catch up on lost time or even mitigate slowdowns (I do this on my SNES project).

Sound effects can be uploaded outside of vblank.
iNCEPTIONAL

Re: Question about black bars, again. . . .

Post by iNCEPTIONAL »

OK, good to know.

What's your SNES project?
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Question about black bars, again. . . .

Post by Pokun »

Sound is mostly handled by a separate processor (the S-APU, Super Audio Processing Unit) which has nothing else to worry about and runs in parallel to the CPU (this is different from most 8-bit systems like NES and Master System where the CPU has to run the whole sound engine every frame, but it's similar to Megadrive and Neo Geo which both uses a Z80 co-processor for this). The CPU needs to upload code and data to the APU's ARAM (Audio-RAM), but during the game it might only need to send commands for changing songs, playing SEs and the like (assuming all needed BGMs and SEs fits in ARAM). Some games might continuously be uploading some sound data to ARAM which would of course take more of the CPU time, but it's not something that has to be done during blanking periods like video updates are.

Edit: Ninja'd!
Myself086
Posts: 158
Joined: Sat Nov 10, 2018 2:49 pm

Re: Question about black bars, again. . . .

Post by Myself086 »

iNCEPTIONAL wrote: Sat Aug 13, 2022 3:59 pm OK, good to know.

What's your SNES project?
You've seen it before: viewtopic.php?t=20531

My newer project that I was hinting at a while back isn't happening.
iNCEPTIONAL

Re: Question about black bars, again. . . .

Post by iNCEPTIONAL »

Myself086 wrote: Sat Aug 13, 2022 4:24 pm
iNCEPTIONAL wrote: Sat Aug 13, 2022 3:59 pm OK, good to know.

What's your SNES project?
You've seen it before: viewtopic.php?t=20531

My newer project that I was hinting at a while back isn't happening.
Ah, yeah. Cool cool. And a very impressive feat it is.

Shame your newer project isn't happening. Are you able to reveal what that was now then, maybe even show off some of the work you did before stopping working on it? Or are you gonna keep it secret still just in case you pick it up again in the future?
Post Reply