It is currently Mon Aug 20, 2018 2:02 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 27 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Sprites: SNES vs Genesis
PostPosted: Sun Jul 29, 2018 1:11 am 
Offline
User avatar

Joined: Fri Sep 11, 2015 10:39 am
Posts: 124
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!


Top
 Profile  
 
PostPosted: Sun Jul 29, 2018 2:35 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7473
Location: Chexbres, VD, Switzerland
Quote:
Having 80 32x32 sprites on the screen does sound impressive,

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.


Top
 Profile  
 
PostPosted: Sun Jul 29, 2018 6:18 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20421
Location: NE Indiana, USA (NTSC)
Marscaleb wrote:
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.)

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.

Marscaleb wrote:
Having 80 32x32 sprites on the screen does sound impressive, (though I don't know if the system would get slow-down before then,)

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.

Marscaleb wrote:
What kind of palettes do these sprites have access to? (What size and how many?)

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

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

Marscaleb wrote:
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?)

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.

Marscaleb wrote:
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!

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.


Top
 Profile  
 
PostPosted: Sun Jul 29, 2018 1:11 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2731
Small sprites: SNES wins
Medium sprites: Genesis wins
Large sprites: tie


Top
 Profile  
 
PostPosted: Sun Jul 29, 2018 2:06 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10716
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Sun Jul 29, 2018 3:37 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 960
tokumaru wrote:
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.


Last edited by 93143 on Sun Jul 29, 2018 9:02 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sun Jul 29, 2018 7:11 pm 
Offline
User avatar

Joined: Fri Sep 11, 2015 10:39 am
Posts: 124
tepples wrote:
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


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?


Top
 Profile  
 
PostPosted: Sun Jul 29, 2018 8:04 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 960
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.


Top
 Profile  
 
PostPosted: Mon Jul 30, 2018 4:57 am 
Offline
User avatar

Joined: Wed Feb 13, 2008 9:10 am
Posts: 655
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
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.

_________________
http://www.tmeeco.eu


Top
 Profile  
 
PostPosted: Mon Jul 30, 2018 6:47 pm 
Offline

Joined: Sun Mar 19, 2006 9:44 pm
Posts: 957
Location: Japan
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.

_________________
http://www.chrismcovell.com


Top
 Profile  
 
PostPosted: Mon Jul 30, 2018 9:19 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10716
Location: Rio de Janeiro - Brazil
ccovell wrote:
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.


Top
 Profile  
 
PostPosted: Mon Jul 30, 2018 11:20 pm 
Offline

Joined: Sun Mar 19, 2006 9:44 pm
Posts: 957
Location: Japan
tokumaru wrote:
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.

_________________
http://www.chrismcovell.com


Top
 Profile  
 
PostPosted: Mon Jul 30, 2018 11:24 pm 
Offline
User avatar

Joined: Sun Dec 12, 2010 10:27 pm
Posts: 321
Location: Hong Kong
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.


Top
 Profile  
 
PostPosted: Tue Jul 31, 2018 3:19 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7473
Location: Chexbres, VD, Switzerland
Code:
Main problem with SNES is the X coordinate being split up, that's an aspect you have to actively fight.

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.


Top
 Profile  
 
PostPosted: Tue Aug 07, 2018 1:35 pm 
Offline
User avatar

Joined: Fri Sep 11, 2015 10:39 am
Posts: 124
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?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 27 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group