It is currently Fri Sep 21, 2018 10:25 am

View unanswered posts | View active topics


Board index » Other » Other Retro Dev

All times are UTC - 7 hours





Post new topic Reply to topic  Page 1 of 2
  [ 27 posts ]  Go to page 1, 2  Next
  Print view Previous topic | Next topic 
Author Message
tepples
PostPosted: Wed May 24, 2017 8:11 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20562
Location: NE Indiana, USA (NTSC)
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.
Top
 Profile  
 
Oziphantom
PostPosted: Wed May 24, 2017 8:54 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 579
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.
Top
 Profile  
 
TOUKO
PostPosted: Wed May 24, 2017 9:39 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 275
You can maybe add the Supergrafx ??
Top
 Profile  
 
TmEE
PostPosted: Wed May 24, 2017 9:45 am 
Offline
User avatar

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

_________________
http://www.tmeeco.eu
Top
 Profile  
 
Myask
PostPosted: Wed May 24, 2017 9:46 am 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 958
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?
Top
 Profile  
 
tepples
PostPosted: Wed May 24, 2017 10:00 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20562
Location: NE Indiana, USA (NTSC)
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".
Top
 Profile  
 
zzo38
PostPosted: Wed May 24, 2017 10:38 am 
Online
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 1013
  • 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.

_________________
.
Top
 Profile  
 
lidnariq
PostPosted: Wed May 24, 2017 12:29 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7535
Location: Seattle
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%)


Last edited by lidnariq on Wed May 24, 2017 2:18 pm, edited 3 times in total.

Top
 Profile  
 
tokumaru
PostPosted: Wed May 24, 2017 1:24 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10814
Location: Rio de Janeiro - Brazil
  • 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%;
Top
 Profile  
 
Nicole
PostPosted: Wed May 24, 2017 1:46 pm 
Offline

Joined: Sun Mar 27, 2016 7:56 pm
Posts: 163
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.
Top
 Profile  
 
psycopathicteen
PostPosted: Wed May 24, 2017 2:02 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2749
It's the same sprite limits for every mode.
Top
 Profile  
 
Nicole
PostPosted: Wed May 24, 2017 2:10 pm 
Offline

Joined: Sun Mar 27, 2016 7:56 pm
Posts: 163
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.
Top
 Profile  
 
TmEE
PostPosted: Wed May 24, 2017 2:21 pm 
Offline
User avatar

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

_________________
http://www.tmeeco.eu
Top
 Profile  
 
mikejmoffitt
PostPosted: Wed May 24, 2017 4:05 pm 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1334
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.
Top
 Profile  
 
LocalH
PostPosted: Wed May 24, 2017 4:16 pm 
Offline

Joined: Thu Mar 02, 2006 12:30 pm
Posts: 169
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)

_________________
Read my blog! The Incoherent Ramblings of a Lowly Geek
Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 1 of 2
  [ 27 posts ]  Go to page 1, 2  Next

Board index » Other » Other Retro Dev

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google Adsense [Bot] 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:  
Powered by phpBB® Forum Software © phpBB Group