Question about black bars, again. . . .
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
Question about black bars, again. . . .
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/
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.
Re: Question about black bars, again. . . .
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.
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.
Re: Question about black bars, again. . . .
Thanks.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.
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.
Re: Question about black bars, again. . . .
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.
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
-
- Posts: 92
- Joined: Fri Mar 08, 2013 5:56 pm
Re: Question about black bars, again. . . .
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.
Re: Question about black bars, again. . . .
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.
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!
Re: Question about black bars, again. . . .
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.
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.
Re: Question about black bars, again. . . .
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
.
.
.
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
.
.
.
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.
Re: Question about black bars, again. . . .
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.
Re: Question about black bars, again. . . .
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.
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.
Re: Question about black bars, again. . . .
OK, good to know.
What's your SNES project?
What's your SNES project?
Re: Question about black bars, again. . . .
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!
Edit: Ninja'd!
Re: Question about black bars, again. . . .
You've seen it before: viewtopic.php?t=20531
My newer project that I was hinting at a while back isn't happening.
Re: Question about black bars, again. . . .
Ah, yeah. Cool cool. And a very impressive feat it is.Myself086 wrote: ↑Sat Aug 13, 2022 4:24 pmYou've seen it before: viewtopic.php?t=20531
My newer project that I was hinting at a while back isn't happening.
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?