Did SNES games really need the black borders....

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

Did SNES games really need the black borders....

Post by iNCEPTIONAL »

https://youtu.be/ArNmpDVo9_c?t=224 (footage of Fatal Fury 2 on both SNES and Genesis)

I know those big black borders on the SNES version are caused by forced v-blank, but can someone explain to me why this is needed on the SNES version and not the Genesis version (in layman's terms)?

Because this is something I see in a lot of SNES fighting games, not so much on Genesis, and in quite a lot of in other SNES games too.

Just want to make sure I understand why, so I can avoid it at all costs.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Did SNES games really need the black borders....

Post by tepples »

On both platforms, video memory can be written during vertical or forced blanking. Games use this time to blast new animation frames into VRAM at about 160 bytes per line.

The significant differences:
  1. On Genesis only, video memory can be also written during the active picture, although more slowly (about 16 bytes per line). This is convenient for games that use compressed tile data.
  2. Genesis may use all 64 KiB of video memory for sprites if the background is simplified, whereas Super NES may use only 16 KiB. This means that in some cases, a Super NES program must spend more time shuffling cels in and out of video memory.
  3. Super NES has less flexible sprite sizes than Genesis. Thus games may need to include more blank space within a sprite cel, which increases the data size of each cel, and thus more vblank time to transfer the cels to video memory.
Without access to the program code of this particular game, I speculate that B and C affect beat-em-ups and one-on-one fighting games. I doubt A is part of it.
iNCEPTIONAL

Re: Did SNES games really need the black borders....

Post by iNCEPTIONAL »

tepples wrote: Sat Mar 12, 2022 8:10 pm On both platforms, video memory can be written during vertical or forced blanking. Games use this time to blast new animation frames into VRAM at about 160 bytes per line.

The significant differences:
  1. On Genesis only, video memory can be also written during the active picture, although more slowly (about 16 bytes per line). This is convenient for games that use compressed tile data.
  2. Genesis may use all 64 KiB of video memory for sprites if the background is simplified, whereas Super NES may use only 16 KiB. This means that in some cases, a Super NES program must spend more time shuffling cels in and out of video memory.
  3. Super NES has less flexible sprite sizes than Genesis. Thus games may need to include more blank space within a sprite cel, which increases the data size of each cel, and thus more vblank time to transfer the cels to video memory.
Without access to the program code of this particular game, I speculate that B and C affect beat-em-ups and one-on-one fighting games. I doubt A is part of it.
Interesting. Doesn't sound great on the SNES' part there. So I guess the way to avoid this is to make sprites that are not too complex, not huge, have as little wasted blank space as possible, and don't have too many animation frames--ideally keeping everything within the one sprite sheet so no extra sprite cels need to be loaded in--correct?

Q. Does Genesis have to basically share the 64 KiB between the sprites and backgrounds then (so, in reality it couldn't actually use all 64 KiB for sprites in most use-cases)? And how does that work on SNES (is it 16KiB specifically for sprites and then a separate additional amount for backgrounds, and if so, how much for the backgrounds)?
Last edited by iNCEPTIONAL on Sat Mar 12, 2022 9:43 pm, edited 2 times in total.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Did SNES games really need the black borders....

Post by dougeff »

I'm not very knowledgeable on Genesis, so I'll leave that for someone else.

The issue with SNES sprites is that they wrap vertically. So if you have overscan in 239 lines mode, you have to limit sprite size to 16x16 max, or else a sprite scrolling off the bottom will also show up at the top.

But, in 224 mode, you can have sprites up to 32x32 that have no problems moving off the top or bottom.

The VRAM on the SNES is flexible, and you can change how much is for BG tiles and how much for Sprite tiles.

Many games even DMA in new tiles all the time, for example a fighting game with tons of Sprite animations for each fighter, you would only load the tiles needed for the next frame.
nesdoug.com -- blog/tutorial on programming for the NES
iNCEPTIONAL

Re: Did SNES games really need the black borders....

Post by iNCEPTIONAL »

dougeff wrote: Sat Mar 12, 2022 9:37 pm I'm not very knowledgeable on Genesis, so I'll leave that for someone else.

The issue with SNES sprites is that they wrap vertically. So if you have overscan in 239 lines mode, you have to limit sprite size to 16x16 max, or else a sprite scrolling off the bottom will also show up at the top.

But, in 224 mode, you can have sprites up to 32x32 that have no problems moving off the top or bottom.

The VRAM on the SNES is flexible, and you can change how much is for BG tiles and how much for Sprite tiles.

Many games even DMA in new tiles all the time, for example a fighting game with tons of Sprite animations for each fighter, you would only load the tiles needed for the next frame.
So, how much total VRAM does the SNES have?
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Did SNES games really need the black borders....

Post by lidnariq »

Same as the Genesis and TurboGrafx - 64KiB.
iNCEPTIONAL

Re: Did SNES games really need the black borders....

Post by iNCEPTIONAL »

lidnariq wrote: Sat Mar 12, 2022 10:35 pm Same as the Genesis and TurboGrafx - 64KiB.
Well, I'm confused.

If they all have the same VRAM, and one person said "Genesis may use all 64 KiB of video memory for sprites if the background is simplified, whereas Super NES may use only 16 KiB.", but another said "The VRAM on the SNES is flexible, and you can change how much is for BG tiles and how much for Sprite tiles" (and I interpret this as basically meaning the same as what the Genesis can do. Presumably it's just a slightly more complicated, not well known and less-used method).

So, does that mean that in terms of purely how much VRAM each machine has available for graphics and how much of it can ultimately be assigned to and split between the backgrounds and sprites, they are basically the same then (at least the Genesis and SNES)?

Note: I know the Genesis has a couple other things it can do around how it uses sprites and stuff too, as mentioned in one of the responses above, so I know it ultimately still has an advantage here.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Did SNES games really need the black borders....

Post by Oziphantom »

you can put the 16K of sprites in RAM where you want ( there are alignment restrictions ) and you can "switch the upper 8K bank" through VRAM as well as you want. So its in the sense that there is not a fixed 16K Sprite Tile RAM area. You could have 2 16K banks that you switch between while you double buffer animations over multiple frames for example.
iNCEPTIONAL

Re: Did SNES games really need the black borders....

Post by iNCEPTIONAL »

Oziphantom wrote: Sat Mar 12, 2022 11:29 pm you can put the 16K of sprites in RAM where you want ( there are alignment restrictions ) and you can "switch the upper 8K bank" through VRAM as well as you want. So its in the sense that there is not a fixed 16K Sprite Tile RAM area. You could have 2 16K banks that you switch between while you double buffer animations over multiple frames for example.
But can you use any of the other RAM that isn't specifically assigned to sprites for sprites on SNES, or is it always that 16K you're having to work with and around in one way or another?

And, does that mean the remaining 48K is fully for backgrounds on SNES?

Also, even though the Genesis can use however much of its 64K for sprites the developer/coder sees fit, as I understand it, does it share the full 64K between the sprites and backgrounds regardless, so, other than swapping in new tiles/sprites via whatever method, it's still just 64K it has to play with for both sprites and backgrounds, and unless the backgrounds are really basic or literally non-existent, it technically can't actually ever assign that full 64K to sprites only?
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Did SNES games really need the black borders....

Post by psycopathicteen »

Alisha's Adventure gets around the DMA v-blank limitations by:

1) Only DMAing when animation frames change
2) Delaying an animation by a frame if too many objects are animated at once
3) Duplicate sprite checking

DKC series use the first 2 tricks.
User avatar
Nikku4211
Posts: 569
Joined: Sun Dec 15, 2019 1:28 pm
Location: Florida
Contact:

Re: Did SNES games really need the black borders....

Post by Nikku4211 »

Oziphantom wrote: Sat Mar 12, 2022 11:29 pm you can put the 16K of sprites in RAM where you want ( there are alignment restrictions ) and you can "switch the upper 8K bank" through VRAM as well as you want. So its in the sense that there is not a fixed 16K Sprite Tile RAM area. You could have 2 16K banks that you switch between while you double buffer animations over multiple frames for example.
So is it possible to use, say, an IRQ to switch the upper 8kiB sprite bank mid-frame?
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Did SNES games really need the black borders....

Post by 93143 »

Nikku4211 wrote: Sun Mar 13, 2022 10:54 amSo is it possible to use, say, an IRQ to switch the upper 8kiB sprite bank mid-frame?
You can move one or both sprite banks mid-frame, by rewriting OBSEL ($2101). I do this in my shmup port, because with a Mode 7 backdrop I need sprites for the Super FX layer, and the size of the playfield means I exceed 16 KB when everything else that needs to be sprites is added in.

Just be sure to write to OBSEL during the active line, and not during HBlank, because HBlank is when the sprite graphics are actually being loaded, and if you interrupt that process you will get visible glitching. First Try by Magical did this wrong, and as a result the mountain sequence shows some glitching halfway down the screen on the right-hand side. Changing the name select and namebase bits in OBSEL during OAM scan (the active display area) is safe.

Note that it is not the easiest thing in the world to use this technique effectively in an action game where any sprite can in principle be anywhere on the screen. In my case, a large fraction of the sprite memory is being used to fake a BG layer, so the screen positions of the involved sprites are fixed, making it easy to assign the data to appropriate locations in VRAM without a ton of duplication.

...

You can also change the master sprite sizes, but (a) it's better to make that change during HBlank so the OAM scan is done with a uniform parameter set, and (b) it's hard to come up with a scenario where changing sprite sizes mid-screen would be useful, since reducing sprite sizes causes big ones to be cut off or only show stubs beneath the split, while increasing them causes little ones to hang down underneath the split even if they had ended above it. I found it incredibly unintuitive when I was testing this, though that could be just me.

Perhaps a mid-screen size change could be useful when combined with a Super Mario Kart-like trick where the screen is blanked for a bit in the middle so that OAM can be rewritten. This would solve the overhang problem. (It would also remove the timing restriction on where you should write to OBSEL, since during forced blank you can change anything you want whenever you want to...)
iNCEPTIONAL

Re: Did SNES games really need the black borders....

Post by iNCEPTIONAL »

iNCEPTIONAL wrote: Sun Mar 13, 2022 7:29 am
Oziphantom wrote: Sat Mar 12, 2022 11:29 pm you can put the 16K of sprites in RAM where you want ( there are alignment restrictions ) and you can "switch the upper 8K bank" through VRAM as well as you want. So its in the sense that there is not a fixed 16K Sprite Tile RAM area. You could have 2 16K banks that you switch between while you double buffer animations over multiple frames for example.
But can you use any of the other RAM that isn't specifically assigned to sprites for sprites on SNES, or is it always that 16K you're having to work with and around in one way or another?

And, does that mean the remaining 48K is fully for backgrounds on SNES?

Also, even though the Genesis can use however much of its 64K for sprites the developer/coder sees fit, as I understand it, does it share the full 64K between the sprites and backgrounds regardless, so, other than swapping in new tiles/sprites via whatever method, it's still just 64K it has to play with for both sprites and backgrounds, and unless the backgrounds are really basic or literally non-existent, it technically can't actually ever assign that full 64K to sprites only?
Following on from my questions above: I've read the SNES has 128K of RAM vs the Genesis 64K. I hope I have that right, and if not then feel free to correct me. So, from what people are saying, the Genesis can basically just divvy the 64K between sprites and backgrounds as it sees fit, and the SNES basically has 16K assigned/fixed for sprites (and outside of some hardcore hacks, that can't really be changed)--but what's the remaining 112K of RAM used for on SNES then (how's it divvied up)?

Note: I'm probably getting all of this wrong/confused, so feel free to explain it all to me (in layman's terms).
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Did SNES games really need the black borders....

Post by lidnariq »

Video RAM ("VRAM") and system RAM ("WRAM" in the SNES) are entirely unrelated.

The Genesis has 64K+64K. The SNES has 64K+128K.
iNCEPTIONAL

Re: Did SNES games really need the black borders....

Post by iNCEPTIONAL »

lidnariq wrote: Sun Mar 13, 2022 5:16 pm Video RAM ("VRAM") and system RAM ("WRAM" in the SNES) are entirely unrelated.

The Genesis has 64K+64K. The SNES has 64K+128K.
OK, and can you [simply, and in layman's terms] breakdown how each of the RAM numbers are split across each machine for use with sprites, backgrounds, audio, whatever?

The only things I seem to get based on what others have said is that Genesis has 64K [VRAM] for both sprites and backgrounds that it can divvy up as it sees fit across the two, and the SNES has a fixed 16K [VRAM] for sprites. What about the rest, on both consoles?
Post Reply