Comparative sprite capacity of 3rd and 4th gen consoles

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

Comparative sprite capacity of 3rd and 4th gen consoles

Post by tepples »

A recent discussion about abundance of platformers on the NES led to discussion about feasibility of other related genres, such as platform fighting, platform beat-em-up, and run-and-gun, on the NES and other consoles from around the same time. One objection was the sprite capability, which led to a huge digression about the comparative sprite coverage capabilities of third- and fourth-generation consoles.

Let me try to summarize:
  • Commodore 64
    24 slivers (60%) of 8 sprites, plus 1 background
    Unified memory architecture limits sprites to 1bpp, needing tradeoff among color depth, resolution, and coverage: hires, multicolor, or multicolor with hires outline overlay
    More than 8 sprites requires raster-triggered software search
  • NES
    8 slivers (25%) of frontmost 8 sprites, plus 1 background
    Typical CHR ROM mapper's window configuration: 2 background windows (128 tiles each) and 4 sprite windows (64 tiles each)
    Nominal CHR RAM bandwidth: 8 tiles/frame
  • Game Boy
    10 slivers (50%) of leftmost 10 leftmost sprites, plus 1 background with split window
  • TurboGrafx-16
    32 slivers (100%) of frontmost 16 sprites, plus 1 background
  • Genesis (256px mode)
    Frontmost 32 slivers (100%) of frontmost 16 sprites, plus 2 backgrounds with split window
  • Genesis (320px mode)
    Frontmost 40 slivers (100%) of frontmost 20 sprites, plus 2 backgrounds with split window
  • Super NES
    Rearmost 34 slivers (106%) of frontmost 32 sprites, plus 2-3 backgrounds
    Nominal CHR RAM bandwidth: 168 tiles/frame
  • Neo Geo
    192 slivers (480%) of frontmost 96 sprites
    Backgrounds other than the fixed HUD are made of sprites; expect backgrounds to use about half the sprite coverage
    Hardware supports sprite shrinking
    Existing MVS and AES cart boards use CHR ROM, rendering software compositing impossible
    Sprite tile index is 20 bits, allowing 1.048 million distinct 16x16 units
    Because its 320px picture continues past overscan into nominal analog blanking, many games use fix to pillarbox the display to 304px wide, giving 505% coverage
A "sliver" is 8x1 pixels.
Nominal CHR RAM bandwidths exclude the sprite display list and one row or column of background tile map.

Correct me if I'm wrong or help fill in missing info.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Comparative sprite capacity of 3rd and 4th gen consoles

Post by Oziphantom »

The C64 also has Sprite Expansion so you can get a hires sprite with 2x Wide pixels ( thus 48 pixels(err slivers) ) that gets you 8*48=384 pixels across or if you use multicolour you get 4 pixels wide but still 384 "pixels" of coverage. Typically when making a sprite "plane" you use 7 to get a screen full ( screen being 320) and then you have 1 sprite for something hires, or use 8 to make a rolling background.
Also has Y expansion for 42 high sprites. Expansion doesn't incur any sprite based costs. ie you can have all 8 expanded X and Y.
User avatar
TOUKO
Posts: 306
Joined: Mon Mar 30, 2015 10:14 am
Location: FRANCE

Re: Comparative sprite capacity of 3rd and 4th gen consoles

Post by TOUKO »

You can maybe add the Supergrafx ??
User avatar
TmEE
Posts: 960
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Re: Comparative sprite capacity of 3rd and 4th gen consoles

Post by TmEE »

I wouldn't really call the "window layer" on MD a 3rd one, it is W or A, but not both in same space so you only ever get 2 layers. It is more like Fix layer on NeoGeo, fixed in size, cannot be scrolled (but can grow from any side of the screen, but will not be useful when it grows from left side and you use scrolling on A, there will be some graphical glitches then).
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: Comparative sprite capacity of 3rd and 4th gen consoles

Post by Myask »

I'd've sworn you had an overdraw thread already.

Also, is SNES 34 slivers or 34 unique slivers, such that you can have 32 larger but non-unique sprites and not drop out?
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Comparative sprite capacity of 3rd and 4th gen consoles

Post by tepples »

It's 34 slivers. Even if the S-PPU could cache slivers already retrieved on this line, it'd still take time to draw them into the line buffer. That's why some docs refer to exceeding the sliver limit as "time over".
zzo38
Posts: 1096
Joined: Mon Feb 07, 2011 12:46 pm

Re: Comparative sprite capacity of 3rd and 4th gen consoles

Post by zzo38 »

  • PC: No sprites. One background, with ROM tiles or all-points-addressable.
  • Amiga: Eight 16 pixel wide sprites, three colours (or you can attach two sprites to make fifteen colours). One or two backgrounds, all-points-addressable. A blitter can be used to draw additional pictures ("bobs").
  • My own design supports 8 pixel wide sprites (fifteen colours), a number of sprites equal to the number of tiles per scanline (normally 40). That is equal to the number of sprites it can read; it cannot read memory for more sprites than that. One background, 8 pixel wide tiles (no limit to tile height). You can use a display list to implement split-screen as well as to change the sprite address.
(Free Hero Mesh - FOSS puzzle game engine)
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Comparative sprite capacity of 3rd and 4th gen consoles

Post by lidnariq »

zzo38 wrote:PC: One background, with ROM tiles or all-points-addressable.
That's ... misleading. PC graphics evolved from CGA/MDA/Hercules through EGA to VGA during the 3rd and 4th console generations. While none had sprites, a handful of games and tools did use RAM tiles.

edit: Actually, a large number of mid-to-late 90s commercial DOS programs started using a standardized graphical mouse cursor in text mode (e.g. Norton, Symantec utilities), which worked by reserving a small handful of characters and rendering the mouse cursor in software.

edit2: During the 5th console generation, SVGA cards actually grew support for one sprite (i.e. composited dynamically during refresh), intended for the mouse cursor.
Amiga
OCS or AGA?

  • Atari 7800: Up to ≈114 slivers (285%) of frontmost 30 sprites, no backgrounds. I think. Someone should sanity-check me.
  • CD-i: despite Wikipedia putting it in the "4th generation" bucket, it's shaped much more like "5th generation" entries: UMA, no sprites, framebuffer, blitter.
  • edit3: Intellivision: 8 slivers (40%) of 8 sprites; optionally each sprite can be made double-width (up to 80%)
Last edited by lidnariq on Wed May 24, 2017 2:18 pm, edited 3 times in total.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Comparative sprite capacity of 3rd and 4th gen consoles

Post by tokumaru »

  • Master System / Game Gear
    8 slivers (25% on SMS, 40% on GG) of frontmost 8 sprites, plus 1 background; Sprites can be globally zoomed to twice their original size, doubling the coverage.
  • Atari 2600 (a generation behind, but interesting enough to bring up I guess)
    Minimum coverage of 19 pixels (16 for 2 players, 2 for 2 missiles, 1 for the ball), or 11.875%; Players and missiles can have up to 2 additional copies spaced at predetermined intervals; Missiles and the ball can be horizontally stretched up to 8 times their size; Players can be horizontally stretched up to 4 times IF they don't have any copies; Maximum coverage of 88 pixels (players x 4, missiles and ball x 8), or 55%;
niconii
Posts: 219
Joined: Sun Mar 27, 2016 7:56 pm

Re: Comparative sprite capacity of 3rd and 4th gen consoles

Post by niconii »

tepples wrote:
  • Super NES
    Rearmost 34 slivers (106%) of frontmost 32 sprites, plus 2-3 backgrounds
    Nominal CHR RAM bandwidth: 168 tiles/frame
Are we just talking common configurations here or the full capabilities of the hardware? Mode 0 is not commonly used because of its color tradeoffs, but it did have four BGs.

Also, where does Mode 7 fit into this? There is EXTBG to add a second layer, but it's not independent, it simply makes colors 128-255 display as 0-127 with higher priority. Given other modes allow setting tile priorities without those being counted as additional BGs, calling it a second BG seems debatable.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Comparative sprite capacity of 3rd and 4th gen consoles

Post by psycopathicteen »

It's the same sprite limits for every mode.
niconii
Posts: 219
Joined: Sun Mar 27, 2016 7:56 pm

Re: Comparative sprite capacity of 3rd and 4th gen consoles

Post by niconii »

psycopathicteen wrote:It's the same sprite limits for every mode.
I know; it's the "plus 2-3 backgrounds" part I'm arguing with here. I believe it should read "plus 1-4 backgrounds" instead.
User avatar
TmEE
Posts: 960
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Re: Comparative sprite capacity of 3rd and 4th gen consoles

Post by TmEE »

VRAM bandwidth for MD :

Code: Select all

This table shows all the available VRAM DMA bandwidth in one frame :
+---------+-------------------------------+-------------------------------+
|         |              50Hz             |              60Hz             |
|         +---------------+---------------+---------------+---------------+
|         |     V224      |     V240      |     V224      |     V240      |
|         +-------+-------+-------+-------+-------+-------+-------+-------+
|         |  H256 |  H320 |  H256 |  H320 |  H256 |  H320 |  H256 |  H320 |
+---------+-------+-------+-------+-------+-------+-------+-------+-------+
| Active  |  3600 |  4050 |  3856 |  4338 |  3600 |  4050 |  3856 |  4338 |
| Passive | 14696 | 18040 | 12024 | 14760 |  6179 |  7585 |     0 |     0 |
| A + P   | 18296 | 22090 | 15880 | 19098 |  9779 | 11635 |  3856 |  4338 |
| Blanked | 52271 | 64165 | 52271 | 64165 | 43754 | 53710 | 40080 | 49200 |
+---------+-------+-------+-------+-------+-------+-------+-------+-------+
Number of tiles that can be transferred per frame :
+---------+---------------------------+---------------------------+
|         |            50Hz           |            60Hz           |
|         +-------------+-------------+-------------+-------------+
|         |    V224     |    V240     |    V224     |    V240     |
|         +------+------+------+------+------+------+------+------+
|         | H256 | H320 | H256 | H320 | H256 | H320 | H256 | H320 |
+---------+------+------+------+------+------+------+------+------+
| Active  |  112 |  126 |  120 |  135 |  112 |  126 |  120 |  135 |
| Passive |  459 |  563 |  375 |  461 |  193 |  237 |    0 |    0 |
| A + P   |  571 |  690 |  496 |  596 |  305 |  363 |  120 |  135 |
| Blanked | 1633 | 2005 | 1633 | 2005 | 1367 | 1678 | 1252 | 1537 |
+---------+------+------+------+------+------+------+------+------+
VRAM bandwidth for SMS :

Code: Select all

Maximum bandwidth for one frame :
+---------+-----------------------+-----------------------+
|         |          50Hz         |          60Hz         |
|         +-------+-------+-------+-------+-------+-------+
|         |  V192 |  V224 |  V240 |  V192 |  V224 |  V240 |
+---------+-------+-------+-------+-------+-------+-------+
| Active  |  3667 |  4275 |  4579 |  3667 |  4275 |  4560 |
| Passive | 12720 |  9328 |  7632 |  7314 |  3922 |     0 |
| A + P   | 16387 | 13603 | 12211 | 10981 |  8197 |  4560 |
| Blanked | 33178 | 33178 | 33178 | 27772 | 27772 | 25440 |
+---------+-------+-------+-------+-------+-------+-------+

SMS VRAM bus is 16 bit but CPU interface is 8 bit so half the bandwidth is
lost due to that. In addition to that, Z80 is too slow to exhaust available
bandwidth during forced blanking and passive scan but it can write data too
fast during active scan causing missed writes and data corruption to happen.

Ideal case access figures for Z80 using OUTI instruction :
+---------+-----------------------+-----------------------+
|         |          50Hz         |          60Hz         |
|         +-------+-------+-------+-------+-------+-------+
|         |  V192 |  V224 |  V240 |  V192 |  V224 |  V240 |
+---------+-------+-------+-------+-------+-------+-------+
| Active  |  2123 |  2475 |  2651 |  2123 |  2475 |  2640 |
| Passive |  1710 |  1254 |  1026 |   983 |   527 |     0 |
| A + P   |  3833 |  3729 |  3677 |  3106 |  3002 |  2640 |
| Blanked |  4460 |  4460 |  4460 |  3733 |  3733 |  3420 |
+---------+-------+-------+-------+-------+-------+-------+
Number of tiles that can be transferred per frame :
+---------+--------------------+--------------------+
|         |        50Hz        |        60Hz        |
|         +------+------+------+------+------+------+
|         | V192 | V224 | V240 | V192 | V224 | V240 |
+---------+------+------+------+------+------+------+
| Active  |   66 |   77 |   82 |   66 |   77 |   82 |
| Passive |   53 |   39 |   32 |   30 |   16 |    0 |
| A + P   |  119 |  116 |  114 |   97 |   93 |   82 |
| Blanked |  139 |  139 |  139 |  116 |  116 |  106 |
+---------+------+------+------+------+------+------+
EDIT:
MVS/AES with LSPC-1 does not output more than 304 pixels horizontally, I disabled display blanking and did other modifications on hardware level and there never is more data coming out the chip. LSPC-2 I have not yet managed to test, but I doubt it behaves different from the first version.
User avatar
mikejmoffitt
Posts: 1353
Joined: Sun May 27, 2012 8:43 pm

Re: Comparative sprite capacity of 3rd and 4th gen consoles

Post by mikejmoffitt »

TmEE wrote:MVS/AES with LSPC-1 does not output more than 304 pixels horizontally, I disabled display blanking and did other modifications on hardware level and there never is more data coming out the chip. LSPC-2 I have not yet managed to test, but I doubt it behaves different from the first version.
I can confirm that every Neo-Geo video system (LSPC-1, LSPC-2, NEO-GRZ) outputs 320 active pixels. 304 pixel width is done by blanking on the FIX layer on the left/right columns. 384 pixels constitutes one line, including blanking. I have not done it, but if you were to write a FIX layer rom that is entirely transparent pixels, you might be able to visually confirm this.

The blanking input on the 74245s on the DAC are active during VBlank on LSPC-based systems, while on the GRZ-based systems it is active during both HBlank and VBlank.
LocalH
Posts: 186
Joined: Thu Mar 02, 2006 12:30 pm

Re: Comparative sprite capacity of 3rd and 4th gen consoles

Post by LocalH »

Oziphantom wrote:The C64 also has Sprite Expansion so you can get a hires sprite with 2x Wide pixels ( thus 48 pixels(err slivers) ) that gets you 8*48=384 pixels across or if you use multicolour you get 4 pixels wide but still 384 "pixels" of coverage. Typically when making a sprite "plane" you use 7 to get a screen full ( screen being 320) and then you have 1 sprite for something hires, or use 8 to make a rolling background.
Also has Y expansion for 42 high sprites. Expansion doesn't incur any sprite based costs. ie you can have all 8 expanded X and Y.
Not the mention the vertical reuse of sprites after their last scanline is displayed. This can allow for 100% vertical coverage with a minimal overhead (especially if creating a large single object with multiple sprites), if you want truly independent sprite positioning then you'll need a sorting algorithm and sprite multiplexer routine.

There is also a way to stretch sprites that was discovered in the 80s and requires very specific timing, and a few years back it was also discovered that it's possible to "crunch" sprites by basically tricking the chip into altering the normal sprite fetching process. C64 is still the king of post-2600 video chip abuse (and until recently with TiTAN's amazing work, I don't personally feel any other platform other than the Amiga even came close, but I'm biased as a childhood Commodore fan)
Post Reply