Sprites: SNES vs Genesis

I was thinking about 16-bit systems lately, which mostly comes down to the SNES versus the Sega Genesis/Mega Drive.
And today, actually I was just thinking about rendering sprites. Wasn't that one of the categories where Sega beat Nintendo hands down? Or was it not so hands-down, or am I mistaken entirely?
I definitely notice that Genesis games frequently made use of having creations built out of many sprites, (eg Vectorman) and I was under the impression that this was something the Genesis did better than the SNES, that the Genesis could render more sprites on the screen than the SNES could.

Well I was trying to look up some technical data, but I couldn't find much that was presented in a way that was easy to understand.
I did gather that the Genesis could draw 80 sprites on the screen with up to 20 on a scanline, (some oddly non-power-of-2 numbers,) and sprites could be drawn in any multiple-of-eight size up to 32x32. (More correctly, any size of 1 to 4 tiles per dimension, and tiles are stored as 8x8.)
Having 80 32x32 sprites on the screen does sound impressive, (though I don't know if the system would get slow-down before then,) but it doesn't give me much more information. What kind of palettes do these sprites have access to? (What size and how many?) And how much memory does the system have that can be used for sprites; how many tiles could be used for sprite data?

And then for the SNES, well honestly I can't find anything about what the SNES could do. I'm getting conflicting data about what size tiles it even stores in its memory. (16x16 or the standard 8x8?)

But I figure if any place on the internet knows what these systems can do, it's this site. I'm sure someone here knows.

Also since we're on the subject, what about other systems from the era? If anyone here knows about the capabilities of other 16-bit systems, I'm interested in hearing about them too. I love this stuff and never get tired of it!

SNES can do this as well, actually it can fit the entiere screen with sprites, (however trying to overlap yet extra sprites on top of that will fail, see below)

A good reference on what the SNES can do is here http://problemkaputt.de/fullsnes.htm#snesppuspritesobjs
I also have the so called "SNES-dev started kit" with lots of documentation, which I'll also use as reference.

SNES can have 128 sprites, and two sizes between 8x8, 16x16, 32x32 and 64x64. Only two sizes can be picked for a particular screen, and each individual sprite can be individually set to either "large" or "small".

SNES can draw 32 sprites per line, and up to 34 sprites converted down to 8x8 sprites, per scanline. Having more will result in lower priority sprites disapearing. This is visible in Secret of Mana for example where it's common to see sprites disappear that way, especially if you use the whip weapon horizontally.

So for example if you increase the sprite size it only increase the number of sprites that the screen can show in total, but it does only barely increase what can be shown on a scanline.

Many games simulates a simple background using sprites when using mode 7, because the only background has to be used for the rotating and scaling object. Any game with a mode-7 boss is almost required to have this, Super Mario World, Super Castlevania IV (fighting stone golem) and Secret of Mana (slime fight) comes to mind.

Secret of Mana is especially impressive as they even made the menu text window being a sprite for this particular boss fight, this is alas hitting the sprite limit and when the boss attacks you with it's rain attack the window start disappearing.

It's non-power-of-2 because sprite evaluation is interleaved with screen rendering, whose width is also allowed to be not a power of 2. That's 1 OAM entry per 4 screen pixels and 1 sprite per 16 screen pixels. You get fewer in 256px mode than in 320px mode.


Slowdown is largely a function of 1. calculating the positions of sprites before drawing them to OAM (which depends on the CPU) and 2. uploading their cels to VRAM (which depends on video memory bandwidth). For many kinds of computations used in video games, the 65816 and 68000 are on par when used by competent programmers. But with 65816 only really ever used in the Super NES and Apple IIGS, there wasn't a huge pool of competent programmers to hire from, so you ended up getting inefficient code out of many of them. And in multiplication- and division-heavy loads, such as anything with 3D rotation, the 68000 wins. See for example Ballz, whose Super NES port needs a DSP-1 coprocessor; a Super NES version of Vectorman would probably have needed a DSP-1 or CX4 as well.

In addition, though DMA to VRAM is similar in speed on the Genesis and Super NES, it's also possible to upload tiles to VRAM during rendering on Genesis because of a write queue in the VDP. This is noticeably slower than DMA but convenient for tile decompression. The Super NES has no such write queue; all uploads to video memory must happen during vertical blanking. Though Nintendo could have implemented a write queue, such as by reserving specific background tile numbers as having no picture or by using otherwise unused rendering time on scanlines with few sprites, the engineers probably didn't see it as that important.


Genesis: Four 15-color palettes, shared with background
Super NES: Eight dedicated 15-color palettes, not shared with background except in 256-color modes (3, 4, and 7)
Neo Geo: More 15-color palettes than you know what to do with


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
Neo Geo: Direct access to a CHR ROM that can be tens of megabytes. Most "VRAM" in the system is really OAM, storing the list of tile numbers that make up each sprite.


Tiles on Super NES are always 8x8 pixels, and sprites are always square and a power of two pixels on a side. Two sprite sizes can be used at once, and most games set them to either A. 8x8 and 16x16 or B. 16x16 and 32x32. Up to 32 sprites on a line, up to 272 sprite pixels (34 8x1-pixel slivers) on a line.


Neo Geo: Sprites 16 pixels wide and as tall as the screen, with each stored as a column of tile numbers. Sprites may be linked horizontally for quick position updates of multiple columns at once. Sprites may be drawn smaller but not larger than they are stored, using a set of sliver-scaling lookup tables inside the video chip.[1] Up to 380 sprites per scene and 96 per scanline. But in practice, that's not quite as much because sprites are also needed to simulate a background map, as the only tilemap on the Neo Geo is a fixed, always-on-top layer mostly used for score display and safe area framing.


[1] It's also practical to implement this LUT-driven scaling method in software on NES, Sega Master System, TurboGrafx-16, Game Boy, Super NES, or any other system with CHR RAM and 8x8-pixel planar tiles.

Small sprites: SNES wins
Medium sprites: Genesis wins
Large sprites: tie

I'm under the impression that the main advantage the Genesis has, regarding sprites, are the configurable dimensions per sprite, which meant less space wasted on transparent pixels.

There were also situations (mostly beat-em-ups) where the SNES' 16 KB sprite data limit was relevant. Switching data areas partway down the screen is possible, but mostly useful for faking background layers with sprites because it's extremely difficult to apply to moving objects without blowing up your VRAM usage and DMA bandwidth. On the Mega Drive you could use the whole 64 KB for sprite data if you wanted to.

And of course in H40 mode the Mega Drive could have more 8x8 sprites on a line without dropout (40 vs. 34), which might be useful in a bullet-heavy game. EDIT: Wow, I wasn't paying attention. 20 sprites per scanline. The SNES trounces that; you can do 32. In terms of overdraw ratio, the SNES wins (slightly), because it can cover a whole scanline with sprites with 16 pixels left over, whereas if you fill a scanline on the Mega Drive it has nothing left over in either H32 mode (32 tiles) or H40 mode (40 tiles). The Mega Drive maintains its overdraw ratio because it upclocks the VDP for H40 mode, which among other things results in more sprites (80 vs. 64) at a slightly higher resolution. The S-PPU is fixed-speed and achieves hi-res mode by abusing parts of the colour blending hardware (namely the fact that it was already handling two pixels per pixel anyway), which doesn't improve VRAM bandwidth, so the SNES maintains its overdraw ratio by simply not upgrading sprites to hi-res.

The SNES had a fiddly sprite attribute table format that tended to cost CPU time, especially with naïve or unoptimized sprite routines; I believe one game actually included a special chip to help build the OAM data.

The VRAM data format for sprites on SNES is a bit unintuitive for some. Each 8 KB table is a square grid 16 tiles on a side, so you can plan out your sprite VRAM with graph paper (a holdover from the NES). This means that individual sprites 16x16 and larger cannot be loaded in one DMA transfer, because the tiles aren't all in a row. This can be very aggravating and may require special handling to maximize bandwidth. On the Mega Drive, you can just DMA all the tiles for a sprite at once because they're all in a row regardless of the size of the sprite.


Basically, the SNES sprite system was more powerful on paper (128 sprites, max size 64x64 as opposed to 80 sprites, max size 32x32), but in practice it had enough restrictions and oddities that which system held an advantage depended on what you were trying to do.

That sounds needlessly complicated without offering any real advantages. If the SNES can just operate with 64 KiB shared with the background, why would you want to have 26 KiB dedicated to the sprites? I mean, it's pulling out of the same pool of 64 KiB anyway, right? Why would you hardware-dedicate a portion of the memory to the sprites when you could just freely use the memory as you see fit?
Or is there some other advantage to using 16 KiB for sprites that I am unaware of?

The sprite attribute table specifies a top-left tile for the sprite. It's 8-bit. There's also a nametable bit that selects which array of 256 tiles to pick the sprite from. You'd need two more bits to span all of VRAM, and that would have expanded OAM from 544 bytes to 576 bytes.

I'm sure I don't need to elaborate on the economic catastrophe the addition of that extra 32 bytes of memory would have wreaked on all of Japan, not to mention the world. And adding even more memory to permit per-sprite per-axis size selection is just unthinkable.

...I don't know; maybe there's something about the S-PPU design that made it necessary to impose these restrictions. I don't know if the fact that the undocumented sprite size settings give you non-square sprites proves they could have done it, or if the fact that the non-square sprites don't flip properly proves they couldn't...

...

Note that I said a wrong thing in my post above, because I forgot (if I ever knew) that the Mega Drive sprite limit per scanline is dramatically lower than its tile limit. (Also, I wasn't thinking and confused the SNES tile and sprite limits.) SNES crushes the Mega Drive when using 8x8 sprites, apparently.

There's 16 or 20 sprites processed per line, and up to 256 or 320 pixels rendered, depending on if you're in H256 or H320. Half the sprite list is cached (vertical coordinate and size+link) while attributes and horizontal coord are read out of VRAM during BG rendering process. At end of active line the cached data is went through and 16/20 visible sprites are extracted to an intermediate list, when active line starts again those 16/20 entries have their corresponding X and attribs fetched out of VRAM, then the new data is used to actually render the whole line to be shown when the active line ends again. Search and rendering happen at the same time, while X+attr fetches coexist with BG rendering and rendered sprite line display. VDP always renders 256 or 320 sprite pixels, even if it didn't find enough sprites, if it didn't do that you could get bunch of extra DMA bandwidth during horizontal blanking when there's time left over from sprite rendering.

Each sprite can be from 8x8 to 32x32, use any part of the 64KB of VRAM (in 128KB mode only half is usable) and there's the linked list aspect that IMO gets in the way as it is one extra parameter to write and more often than not you have a sequence without any gaps or other irregularities.

Main problem with SNES is the X coordinate being split up, that's an aspect you have to actively fight. Two sprite sizes per frame is mainly an inconvenience. Some of the larger sprites are pretty much waste of VRAM though, different size selections would have made more sense with emphasis on smaller non square sizes.

I'll chime in with the Turbografx / PC-Engine, just because. It has one or two advantages over the Genesis, and... 1 over the SNES.

TG/PCE can have 64 sprites, and each of them can be any size between 16x16, 16x32, 16x64, 32x16, 32x32 and 32x64. Sprite tiles can use 64K of VRAM.

TG/PCE can draw 16 sprites per line at most, each scanline having a maximum of 256 pixels of sprite data. Thus some games use sprites as a screen-covering pseudo-background, since the PCE has a single BG tile layer otherwise.

TG/PCE: Sixteen dedicated 15-color palettes, not shared with background.

And yet somehow, even with 2 video chips stacked together, they still couldn't afford one measly skin tone for Arthur's face in what is probably the best home port of Ghouls 'n Ghosts. Go figure.

You can blame the developer NEC Avenue for that. They tended to bring over the graphics as-is on many arcade-to-PCE ports, and obviously run simple math on the palette downconversion -- as opposed to tweaking by eye.

Honestly, being able to display so many simultaneous colours at once, the PCE missed an opportunity by not using a larger master palette, such as a 4096 one, which was used by a number of arcade boards.

As Tetgannon(the video colour encoder) is a separate chip from 7UP(the video display chip), the system could theoretically be upgraded to using another master palette.

In designing the SGX, if they didn't just double the number of video chips (and double the VRAM to a full 128kb that the original system really deserved to have, and, more system RAM), it would curb stomp the MD and SFC if they upgraded the master palette(without the transparency effects, at least; I'm not a fan of the other fancy features such as Mode 7 and screen pixellation) and could make arcade conversions look even better. This may even add up more to the cost though, and I think one main reason they abandoned the SGX was its high cost.

Still, I'm more biased towards the PCE as I am an owner and not very much a fan of the other two consoles.

Ninja'ed:
Actually Dai Makaimura was developed by Hudson itself (more accurately mostly handled by Alfa System programmers), but for some reasons published by NEC Avenue.

I could name quite a few games that do a NES-style left clip of the leftmost 8 pixels (often also rightmost, for symetry). I suspect one of the reasons they did that, when using 8x8 sprites, they don't have to worry about the MSB of X position and can just use 0-255, not touching the separate small OAM.

Final Fantasy IV only clips one pixel on each side (go figure) but still have sprites misteriously "disapear" when their position is supposed to be in the [-8...-1] range, this is quite ugly but apparently they didn't care.

So from looking at the stats, the SNES seems to beat the Genesis in terms of sprites.
But there's one thing I'm still left to wonder.

Why then, was it so much more common to see things built out several smaller sprites on the Genesis than the SNES?
Was this just a style thing? Or was there some other hardware factor that I'm missing?

Of course, lots of games on both systems had things built out of "many sprites," but on the SNES they tried to make things look like single larger sprites. Mega Man X, for example, has separate sprites for all his upgradable components, and many of the larger enemies are building out of "parts" that can move independently. But each of those sprites looks different from each other; each one is a unique "part."
But on the Genesis, so many games had characters (especially bosses) built out of repeated sprites, in a style like Vectorman. Bosses in Monster World 4, Gunstar Heroes, Castlevania Bloodlines, all the Sonic games. And yet I'm struggling to think of more than one example on the SNES.

The SNES seems more capable of handling many sprites on the screen. They both are looking at the same amount of memory for sprites, so there isn't a need to repeat objects to conserve memory. And honestly the Genesis's ability to use more sizes in sprites seems like the kind of thing that would benefit having enemies that look like single large sprites.

So where is this coming from? Is there a hardware reason or was it just a style that the Sega people leaned to more than the Nintendo people?

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

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.


...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:

If that's the case, then what stops a game from sharing data like the Genesis?

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.

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 ^^).

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.

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.

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...

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.

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.

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.

- and those skeletons are coincidentally completely recycled from Rondo on PC Engine