Comparative sprite capacity of 3rd and 4th gen consoles

Comparative sprite capacity of 3rd and 4th gen consoles
by tepples on 2017-05-24 (#196494)

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.

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by Oziphantom on 2017-05-24 (#196503)

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.

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by TOUKO on 2017-05-24 (#196505)

You can maybe add the Supergrafx ??

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by TmEE on 2017-05-24 (#196510)

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

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by Myask on 2017-05-24 (#196511)

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?

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by tepples on 2017-05-24 (#196512)

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

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by zzo38 on 2017-05-24 (#196515)

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.

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by lidnariq on 2017-05-24 (#196518)

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.

Quote:

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%)

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by tokumaru on 2017-05-24 (#196523)

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%;

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by Nicole on 2017-05-24 (#196524)

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.

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by psycopathicteen on 2017-05-24 (#196525)

It's the same sprite limits for every mode.

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by Nicole on 2017-05-24 (#196526)

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.

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by TmEE on 2017-05-24 (#196527)

VRAM bandwidth for MD :

Code:

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:

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.

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by mikejmoffitt on 2017-05-24 (#196535)

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.

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by LocalH on 2017-05-24 (#196537)

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)

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by TmEE on 2017-05-24 (#196538)

mikejmoffitt wrote:

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.

That is more or less what I did, I made DACs always output a signal and fed data to FIX inputs that should have made whatever is underlying active but there was never more than black output. Only ever 304 pixels of active video, rest being blanking and porches.

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by tepples on 2017-05-24 (#196541)

Nicole wrote:

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.

Common configurations. Modes other than 1 ("normal"), 2 (column scrolling), 3 (title screens), and 7 (texture mapped floor) don't see a lot of use.

TmEE: "Passive" means vertical blank period, right? If so, the DMA bandwidth to the Genesis VDP in H256 mode appears almost identical to that to the S-PPU after deducting time to copy the sprite attribute table and a row or column of background map. The advantage of "Blast Processing" over DMA to the S-PPU is really just the ability to decompress tiles (Nemesis, Kosinski, etc.) directly to VRAM without using any vblank time.

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by ccovell on 2017-05-24 (#196543)

TmEE wrote:

mikejmoffitt wrote:

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.

That is more or less what I did, I made DACs always output a signal and fed data to FIX inputs that should have made whatever is underlying active but there was never more than black output. Only ever 304 pixels of active video, rest being blanking and porches.

Run Blue's Journey on any Neo-Geo and double-check that the borders around text during the introduction or in-game are all visible. That's 320 pixels.

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by Oziphantom on 2017-05-24 (#196571)

lidnariq wrote:

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.

Quote:

Amiga

OCS or AGA?

That is OCS , although the bolting might be ECS

AGA has 32 or 64 wide sprites ( all must be the same width), hires or superhires resolutions ( as sprite resolution and colours are independent of "window" resolution ), you can have 2 palletes were odd sprites are one and even is another.
You can have Vertical doubling ( each line is repeated twice, useful for interlace modes)
You can reuse the same sprite again on the same X line ( you can do it on ECS, but on AGA it is without cleaver timings, tricks etc )

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by TmEE on 2017-05-25 (#196589)

tepples wrote:

TmEE: "Passive" means vertical blank period, right? If so, the DMA bandwidth to the Genesis VDP in H256 mode appears almost identical to that to the S-PPU after deducting time to copy the sprite attribute table and a row or column of background map. The advantage of "Blast Processing" over DMA to the S-PPU is really just the ability to decompress tiles (Nemesis, Kosinski, etc.) directly to VRAM without using any vblank time.

Yes, it means vertical blanking period. I don't think there are many games that touch VRAM from active display. You still get 16 or 18 bytes per line and could use that to transfer some/all of the sprite list during a statusbar etc.

ccovell wrote:

Blue's Journey on any Neo-Geo and double-check that the borders around text during the introduction or in-game are all visible. That's 320 pixels.

Unfortunately I don't have that game (and it seems way out my budget too), I only have the Metal Slugs, Neo Turf Masters and Riding Hero and none of those do more than 304 no matter what I tried. My TV shows almost all the image from sync to sync with only few pixels worth clipped off on left side in the porch so it isn't a matter of me not seeing the pixels if they were there, plus I had scope running simultaneously and it never showed any activity at the edges of regular active display area when I was testing around.
EDIT: When I looked through my chat log with Furrtek I saw that I did manage to get some noise show up in the sides of screen when I toyed around with some control signals but there was never any actual graphics there.
I'll remain unconvinced about the 320 pixels until I see them myself. I don't plan to take up NG programming yet and I'm not very familiar with the machine to write a small test ROM anyway that would set up things so that in theory there will be stuff visible at the sides. I could swap out the 68K program ROM in one of my carts for sake of testing.

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by mikejmoffitt on 2017-05-25 (#196619)

Real Bout Fatal Fury Special uses 320 pixels as well. I suppose I'll have to go home and take some pictures of it to convince you.

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by Drew Sebastino on 2017-05-25 (#196622)

Yeah, I thought it was well known the Neo Geo outputs 320 pixels horizontally, but that 8 pixels on either side are commonly blackened out by plain black tiles in the fix layer? It'd be no different than putting a plain black window on both sides of the screen on the SNES or any other thing to block part of the screen in software (Not natively supporting reducing the rendering area, like on the NES).

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by psycopathicteen on 2017-05-25 (#196634)

I think most of the later games used the smaller resolution for some reason.

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by tepples on 2017-05-25 (#196635)

Perhaps the smaller res (304x224) was more compatible with marginal monitors, particularly aging MVS monitors and the TVs used with the AES.

If you compare the AES's output timing to that of a standard TV, you find that only 315x240 pixels are in the 4:3 frame, the rest in what Rec. 601 calls the "nominal analog blanking" area. (The AES pixel aspect ratio is 65:64.) Assuming 3.5% overscan on all sides, you end up with close to 64/65*.93*320 by .93*240 = 293x223 visible.

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by TmEE on 2017-05-25 (#196650)

Arcade cab monitors tend to have bunch of manual controls in them so you can set the screen size and other parameters to suit the particular board you have installed, there was no need for any tight timings or signal levels and everything used the most convenient timebases and resistor values for their video output frequencies and levels.
AES uses a different master clock just so that the video output would play nicer with TVs which are supposed to follow some particular standards.

All places cite 320 pixels but it seemed that everything was using no more than 304 and only 320 shots I saw were from emulators so that's where the curiosity began and after a bunch of experiments I could never get more than 304 pixels to show up on my MV1 (with LSPC-A0) board. I have a MV1-FZ (with LSPC2-A2) that is yet to be tested in any meaningful way (will get a chance to look at it again once I am back from Norway, which happens next month).

mikejmoffitt wrote:

Real Bout Fatal Fury Special uses 320 pixels as well. I suppose I'll have to go home and take some pictures of it to convince you.

Yes please if it isn't too much trouble ~

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by tepples on 2017-05-31 (#197025)

True, but as a monitor ages, those controls become less effective at hiding the signs of aging.

You might be able to count pixels by replacing a game's fix ROM with direct wires from low address lines to the data lines.

Is it still spelled "coverage", or is it officially "covfefe" now?

Re: Comparative sprite capacity of 3rd and 4th gen consoles
by mikejmoffitt on 2017-05-31 (#197028)

TmEE wrote:

Arcade cab monitors tend to have bunch of manual controls in them so you can set the screen size and other parameters to suit the particular board you have installed, there was no need for any tight timings or signal levels and everything used the most convenient timebases and resistor values for their video output frequencies and levels.
AES uses a different master clock just so that the video output would play nicer with TVs which are supposed to follow some particular standards.

All places cite 320 pixels but it seemed that everything was using no more than 304 and only 320 shots I saw were from emulators so that's where the curiosity began and after a bunch of experiments I could never get more than 304 pixels to show up on my MV1 (with LSPC-A0) board. I have a MV1-FZ (with LSPC2-A2) that is yet to be tested in any meaningful way (will get a chance to look at it again once I am back from Norway, which happens next month).

mikejmoffitt wrote:

Real Bout Fatal Fury Special uses 320 pixels as well. I suppose I'll have to go home and take some pictures of it to convince you.

Yes please if it isn't too much trouble ~

Here's an emulator screenshot first:

Pay careful attention to the distance between the "Credits" stuff and the edges.

Now this is captured off of the MVS pixel bus with an FPGA as part of my line doubler:

This is how it would look if it was cropped to 304: