| Home | Forums | What's new | Resources | |
| Genesis VPD vs Saturn VDP |
| maiki - Jul 3, 2005 |
 |
Borisz | Jul 3, 2005 | |
| He probably means that the Saturn VDP (the VDP2 actually) can handle pictures in a whole. | |||
 |
fonzievoltonov | Jul 9, 2005 | |
| Certainely cause the genesis vdp can't handle more than 20+2 redraw per pixel on screen without loosing timings... (if you put 20 sprites on the same area, this makes one draw per sprite plus layer A and B...). Someone here can confirm? Maybe the neo geo has some additional VDP thing that can optimise drawings... | |||
 |
ExCyber | Jul 9, 2005 | ||
I think Borisz may have meant that Genesis is limited to tiles, i.e. Saturn's VDP2 can handle a direct bitmapped display (although I don't think VDP2 itself has any blitter capabilities, and AFAIK VDP1 renders only into its own buffer so you're bound by the CPU unless you could maybe rig up something with the "DMA through SCU DSP" widget), while the Genesis VDP can only display tilemaps. I think the main reason that the bitmap capability exists on Saturn is for ease of displaying FMV and title (and similar e.g. game over, level completed et. al.) screens, for which tilemapping is basically a hindrance as it saves no memory/bandwidth on these types of scenes and serves only to complicate the task. As for Neo-Geo, I'm not 100% sure but I think its rendering engine is actually three rather fast sprite engines running in parallel, and their performance almost certainly depends on having a dedicated sprite pattern bus with a large RAM/ROM hooked up to it (Neo carts basically have a dedicated ROM bank and bus for every major component, which is why they have two large circuit boards and are/were inordinately expensive). | ||||
 |
mrkotfw | Jul 10, 2005 | |
| using tile does indeed save some memory. what if it's a patterned background? you can probably display that background in 2-3 tiles min. as for the map data, it can probably be easily compressed. it does complicate things a lot. the programmer should also have no problem doing any of this anyways! there are many many reasons for using tile rather than bitmap, one of them is being able to use multiple layers. as for the 1,000 sprites, i don't think that would be possible because where would you store all the tiles? you can't possibly use the space that is used for the backgrounds! there are tricks to allow more than the allowed sprites, using a horizontal blank effect. i don't know how it works exactly, but i know some people need it to display a lot of sprites. | |||
 |
Mask of Destiny | Jul 10, 2005 | ||
There is no reason you couldn't implement multiple layers with a bitmapped display. The reason for using tiles is strictly for saving space and saving memory bus bandwidth. Even with DMA, there isn't enough bandwidth on the main memory bus to draw to every pixel on the screen; however, it takes relatively little bandwidth to rewrite the name table to say which tiles are used where. <!--QuoteBegin-P iratero as for the 1,000 sprites, i don't think that would be possible because where would you store all the tiles? you can't possibly use the space that is used for the backgrounds! there are tricks to allow more than the allowed sprites, using a horizontal blank effect. i don't know how it works exactly, but i know some people need it to display a lot of sprites. [/quote] You wouldn't necessarily need to display 1000 different sprites, you could duplicate certain ones (which is the case in a shooter with a ridiculous number of bullets). The Trick to get more sprites on the Genesis involves having multiple sprite lists and then changing the VDP Reg that points to the list during HBlank. You're still limited to 20(I think) sprites per line though as the VDP can't draw any more than that. | ||||
|
maiki | Sep 2, 2005 | ||
Read the documents about Genesis first, please. Genesis VDP offers the complete priorities strategy, not only as for the sprites but for the scrolling planes including window! It takes several full pages in the Genesis technical info fromSega to describe this complex priority system in Genesis VDP. Genesis is not an Amiga, it is the real gaming machine, you know! | ||||
|
fonzievoltonov | Sep 3, 2005 | |
| "Read the documents about Genesis first," haha, funny  You were speaking about "collision" between sprites... Here you're speaking about pixel priorities (i was probably confused by the first message )  " then changing the VDP Reg that points to the list during HBlank." I understand the trick BUT, i don't know why sega didn't allowed more than 80 by default... | |||
|
Mask of Destiny | Sep 4, 2005 | |
| The VDP renders a line at a time while the raster beam is moving across the screen so it only has a full line worth of cycles to render a line. For each line it has to be able to read through the entire sprite list looking for sprites that fall on that line. The longer the list, the more cycles needed to read it. Sega decided on 80 sprites because that's what fit inside their cycle budget. The only way to increase it is to either increase the speed of the VDP or sacrifice capability somewhere else to give more cycles to the sprite routine. | |||
|
fonzievoltonov | Sep 4, 2005 | |
| "creen so it only has a full line worth of cycles to render a line. For each line it has to be able to read through the entire sprite list looking for sprites that fall on that line." Are you 100% sure of that? I vaguely remember that the vdp rank the sprites (by Y coordinates) a bit before the 1st line is traced... Umm, but in this case, there is some space in vdp or vram to store the rank... I thought it was using the "unused" 4bits of sprite size to store this in vram (the ranking) :/ But you are probably right, with your "way of drawing", the trick of multiple scroll table possible. | |||