Sprites: SNES vs Genesis

Discussion of development of software for any "obsolete" computer or video game system. See the WSdev wiki and ObscureDev wiki for more information on certain platforms.
adam_smasher
Posts: 271
Joined: Sun Mar 27, 2011 10:49 am
Location: Victoria, BC

Re: Sprites: SNES vs Genesis

Post by adam_smasher »

Conjecture 1: The MD CPU tends to be faster and better for mathy things that allow for smooth and flexible multijointed sprites.

Conjecture 2: The SNES' additional background layers and Mode 7 were often used for large bosses and the like; developers thought this approach looked better than multijointed sprites so went with this on the SNES instead

Conjecture 3: The SNES has more flexibility palette-wise; Genesis developers used uniform sprites with a single palette because more elaborate designs would've pushed the small number of colours available too much
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Sprites: SNES vs Genesis

Post by 93143 »

adam_smasher wrote:Conjecture 1: The MD CPU tends to be faster and better for mathy things that allow for smooth and flexible multijointed sprites.
It's generally accepted that there was indeed something of an advantage there (though not nearly as big as the MHz numbers suggest). In addition, the 68000 was more familiar to a lot of programmers, and even 65xx programmers often prefer the 68000, describing it as "like being on vacation" and such stuff.

The SNES sprite system was also more fiddly to work with, which made it take more CPU power to do the same thing, particularly if you weren't smart about it. Hence the OBC-1 chip used in Metal Combat, and the "soft OBC-1" sprite routine devised by modern homebrewers.

Your other conjectures make sense to me too. As an analogy, I've seen people claim that the Mega Drive was better at line scrolling than the SNES, even though its capabilities were just a subset of what the SNES can do with HDMA. I imagine this sort of thing may be because SNES developers tended to focus more on stuff the SNES could do but the Mega Drive couldn't, rather than just stubbornly going head to head with a better CPU. Conversely, perhaps Mega Drive programmers were attempting to make the most of their system's more limited feature set, so they'd end up doing things like that because they couldn't do stuff like Mode 7 and colour math.
Marscaleb wrote:They both are looking at the same amount of memory for sprites
...no?

The SNES can only address 16 KB of sprite tile data at a time. Mid-frame OBSEL writes are very difficult to use for anything other than faking a BG layer with sprites, because of how hard it is to make sure the data you want is available when you want it for every generic moving object on screen. So basically you've got 16 KB to work with.

The Mega Drive can put sprite data anywhere in VRAM. 64 KB. Shared with BG tiles, map data, and the sprite attribute table, of course, but it's still way more flexible if you've got a bunch of huge sprites like in a beat-em-up.
User avatar
Marscaleb
Posts: 240
Joined: Fri Sep 11, 2015 10:39 am
Contact:

Re: Sprites: SNES vs Genesis

Post by Marscaleb »

adam_smasher wrote:
Marscaleb wrote:They both are looking at the same amount of memory for sprites
...no?

The SNES can only address 16 KB of sprite tile data at a time. Mid-frame OBSEL writes are very difficult to use for anything other than faking a BG layer with sprites, because of how hard it is to make sure the data you want is available when you want it for every generic moving object on screen. So basically you've got 16 KB to work with.

The Mega Drive can put sprite data anywhere in VRAM. 64 KB. Shared with BG tiles, map data, and the sprite attribute table, of course, but it's still way more flexible if you've got a bunch of huge sprites like in a beat-em-up.
Eh? Then what's this:
tepples wrote:
Marscaleb wrote:And how much memory does the system have that can be used for sprites; how many tiles could be used for sprite data?
Genesis: 64 KiB; always shared with background
Super NES: 16 KiB out of 64 KiB; can optionally be changed mid-screen or shared with background
If that's the case, then what stops a game from sharing data like the Genesis?
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Sprites: SNES vs Genesis

Post by 93143 »

There's no function to explicitly "share" data. It's just that the data happens to be in the same format, and nothing is keeping you from specifying sprite and BG data ranges that overlap. That's all that means.

In the SNES case, the BG data for a 4bpp layer (the same format as the sprites) spans 1024 tiles, or half of VRAM. Each BG layer has a separate data range in VRAM specified by the programmer, and these data ranges can overlap (so BG layers can also share data with one another). The sprite data is in two tables, each spanning 256 tiles, and the PPU does not check to make sure you haven't put a sprite table in the middle of a BG data area. (Why would it?) So in principle the same tile can be used by both 4bpp BG layers and the sprite layer, all at the same time.

The only way to exceed 16 KB of sprite data during one frame (that I know of) is to write to OBSEL during an active line to change where the sprite data is looked for. That way, once HBlank arrives and the PPU begins to load sprite sliver data for the next line, it looks in the new location. Unfortunately this is impractical for most situations because it's too hard to figure out where to put stuff to avoid glitching, so in general you're stuck with 16 KB of sprite data, some or all of which may also be background layer data.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Sprites: SNES vs Genesis

Post by Bregalad »

Sprites can be shared with background but only in some modes where the backgrounds are 4BP, in practice that means background 1 and 2 of mode 1 and mode 2, as well as background 2 of the rarely used mode 3. (Mode 5 also uses a 4BP background but it's hi-res so re-using the same data as sprites won't look the same, harldy useful at all). Also, tile sharing will not work for all combinations of BG's tile size and sprites' size. I'm not knownledgealbe enough about SNES to give all details but you can look it up yourself.

The only reason this wasn't used much is that this was hardly ever needed. Sprites are displaying moving objects, background non-moving objects. On the older consoles like the NES sharing sprites and background tiles make sense because there's so few sprites : When an object is moving only rarely, it makes sense to draw it as background, and sprites only when it's actually moving. On the SNES there's enough sprites, so they can just use sprites even for objects which are rarely moving.

One example for such is units in Fire Emblem. On the NES version and the first SNES game, they are drawn with background, except the moving units which are then drawn with sprites. On the last 2 SNES games, as well as the GBA games, the units are just sprites, no matter whether they're moving or not; this probably greatly simplifies programming. I have no idea why they stuck to the BG/sprites changes hassle in the first SNES game, you should analyze it to see whether they re-use sprites as BG or if it's another VRAM page.

Another example is the falling blocks in Castlevania games. In Castlevania III, they are displayed as background, and when you step on them for a short time, they start to fall off, blank tiles are written to the background and the falling blocks turn into sprites so they can physically move. In Super Castlevania IV, the exact same falling blocks are simply displayed as sprites all the time, even before they start falling (to be verified, I'm only 95% sure of that ^^).
User avatar
Marscaleb
Posts: 240
Joined: Fri Sep 11, 2015 10:39 am
Contact:

Re: Sprites: SNES vs Genesis

Post by Marscaleb »

Ahh, I see my mistake now.
Although it can share data with the background, there is still only 16K that can be used as sprites.

Wait, does that really come out to only two banks of 256 tiles? That's only double what the NES can store; that's outrageous. How did even half the games I've played even function with such a small selection of sprites?
Right off the cuff I'm guessing you can change where in the memory those two banks are, so between frames you could swap out for another set of tiles. That would be great for something like a fighting game, but anything else will leave you pressed to have the tiles you need.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Sprites: SNES vs Genesis

Post by tokumaru »

I think both the Genesis and the SNES make heavy use of DMA to stream new patterns as needed. On the NES you had to do it manually byte by byte, so that's why CHR-RAM animations weren't so common, but when you have DMA functionality at your disposal? Run the games in emulators with VRAM viewers and you'll see how much the tiles change over time.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Sprites: SNES vs Genesis

Post by 93143 »

Yes, you can change where the sprite data banks are in VRAM. This might be useful for double buffering or very rapid scene changes.

In fact you can do it mid-frame to bust the 16 KB limit, but as I said it's hard to use this trick for anything other than a fake BG layer made out of sprites, so it's extremely rare.

Perhaps one of the bigger differences is that you can replace several KB of sprite data per frame with DMA. This isn't NROM, where the whole game uses one sprite table...
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Sprites: SNES vs Genesis

Post by psycopathicteen »

Marscaleb wrote:Ahh, I see my mistake now.
Although it can share data with the background, there is still only 16K that can be used as sprites.

Wait, does that really come out to only two banks of 256 tiles? That's only double what the NES can store; that's outrageous. How did even half the games I've played even function with such a small selection of sprites?
Right off the cuff I'm guessing you can change where in the memory those two banks are, so between frames you could swap out for another set of tiles. That would be great for something like a fighting game, but anything else will leave you pressed to have the tiles you need.
Donkey Kong Country had 3 types of animated sprites (normal, bananas/HUD, and bosses). Normal sized sprites can take up to 1kB at maximum, and there can be up to 14 of them onscreen at once. Bananas and HUD take 2kB all together and they are statically located. Bosses animate similar to normal sized sprites, but they take up 2 normal sized enemy slots instead of one. During game logic, it predicts when DMA overflow happens, so instead of DMA causing black bar glitches it delays the animation instead. If you're playing in slow motion, you can sometimes see Donkey Kong or Diddy Kong float for a frame before their jumping animation begins.

Dracula X is pretty interesting. The main player animates with DMA like Donkey Kong Country does, but the enemies don't use DMA except when changing rooms. Rooms can't have too many distinct enemy types or else they won't fit in VRAM. Weapons get DMA'ed during weapon changes. The interesting thing about this game is that the enemies are actually a combination of traditional frame by frame animation and multijointed sprites.
User avatar
Sumez
Posts: 919
Joined: Thu Sep 15, 2016 6:29 am
Location: Denmark (PAL)

Re: Sprites: SNES vs Genesis

Post by Sumez »

SNES Dracula XX is re-using a ton of graphics from the PC Engine Dracula X game (which is an entirely different game aside from that). I'm pretty sure all the multijointed enemies in the game are carried over directly from the earlier game, so it made sense to do it the same way.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Sprites: SNES vs Genesis

Post by psycopathicteen »

https://www.youtube.com/watch?v=jlkzy9cIB5o

The first skeletons you come accross recycle the same body parts between frames, but changes the location of the body parts relative to eachother.
User avatar
Sumez
Posts: 919
Joined: Thu Sep 15, 2016 6:29 am
Location: Denmark (PAL)

Re: Sprites: SNES vs Genesis

Post by Sumez »

- and those skeletons are coincidentally completely recycled from Rondo on PC Engine ;)
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

Re: Sprites: SNES vs Genesis

Post by turboxray »

Genesis has the SNES beat in the sprites department overall.

Flexibility of sprites in ram vs the snes bank layout really comes into play when you need more unique detail on screen via sprites (instead of just the same reference). It allows better option for more frames in vram without always uploading frames to vram. It allows more flexibility for double buffer large sprites (Neo Geo fighters) - only 16k for sprites hurts.

The limit of two sprite sizes really dampers the SNES, especially considering they're power of 2 sizes. Genesis flexibility to have 8, 16, 24, 32 in either row/col setup allows a game to maximize for sprite realstate without sprite drop out/flicker. It really allows you to drill down and optimize for scanline limit (Streets of Rage 2 and 3 are damn impressive in this respect).

Snes' 34/272 pixel limit looks great on paper, but limited to two choice sprite size really makes it less optimal than it appears. That's not to say it doesn't have edge cases which it is optimal, but it's an outer edge case compared to general case. Give the OAM is 128 entries, 8x8 and 16x16 is the most optimal choice, then there's the snes' slower cpu and oam format overhead. From what I've seen, 16x16 paired with 32x32 is pretty common on the snes - which puts it pretty much on par with the PCE (but lacks the vram flexbility of the PCE for sprites, and PCE also has additional 16x32, 16x64, and 32x16 sizes.. so even the PCE edges it out in general case ). 16x16/32x32 is also wasteful on vram too if you have 8x8 areas inside those sprites that have all transparent pixels (24x24 sprite using 32x32 format).

I have a trick on the PCE (VDC reg settings) that makes it show sprites at half vertical res (it skips every other line of the sprite), allowing 16x8, etc. Basically it skips every other line. So, bit #0 if the Y position because kind of a bank select per sprite (which interleaved set of lines to show for that specific sprite). You lose the XX by 64 height, but it's not generally useful size.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Sprites: SNES vs Genesis

Post by psycopathicteen »

I'm guessing a good rule of thumb is, if you're using a lot of sprites onscreen in an SNES, avoid making the main character or 'regular' sized enemies more than 32 pixels wide, per line, unless the enemy is supposed to be intimidatingly huge or if you absolutely need to.
SNES AYE
Posts: 201
Joined: Mon Nov 07, 2022 11:28 am

Re: Sprites: SNES vs Genesis

Post by SNES AYE »

Bregalad wrote: Wed Aug 08, 2018 1:41 am Sprites can be shared with background but only in some modes where the backgrounds are 4BP, in practice that means background 1 and 2 of mode 1 and mode 2, as well as background 2 of the rarely used mode 3. (Mode 5 also uses a 4BP background but it's hi-res so re-using the same data as sprites won't look the same, harldy useful at all). Also, tile sharing will not work for all combinations of BG's tile size and sprites' size. I'm not knownledgealbe enough about SNES to give all details but you can look it up yourself.

The only reason this wasn't used much is that this was hardly ever needed. Sprites are displaying moving objects, background non-moving objects. On the older consoles like the NES sharing sprites and background tiles make sense because there's so few sprites : When an object is moving only rarely, it makes sense to draw it as background, and sprites only when it's actually moving. On the SNES there's enough sprites, so they can just use sprites even for objects which are rarely moving.

One example for such is units in Fire Emblem. On the NES version and the first SNES game, they are drawn with background, except the moving units which are then drawn with sprites. On the last 2 SNES games, as well as the GBA games, the units are just sprites, no matter whether they're moving or not; this probably greatly simplifies programming. I have no idea why they stuck to the BG/sprites changes hassle in the first SNES game, you should analyze it to see whether they re-use sprites as BG or if it's another VRAM page.

Another example is the falling blocks in Castlevania games. In Castlevania III, they are displayed as background, and when you step on them for a short time, they start to fall off, blank tiles are written to the background and the falling blocks turn into sprites so they can physically move. In Super Castlevania IV, the exact same falling blocks are simply displayed as sprites all the time, even before they start falling (to be verified, I'm only 95% sure of that ^^).
So, could you place the HUD graphics for a game onto some free space in the 4bpp background layer's tileset and then use sprites with those background tile graphics for the actual in-game HUD, thereby still allowing the HUD that's made of sprites to appear over all the normal background layers while saving a little of the limited VRAM normally allocated to sprite tiles?
Post Reply