Genesis VPD vs Saturn VDP

[maiki]

First of all, I am not a coder or anything like that. I just own a Mega Drive and would like to investigate some things here about its VDP compared to Saturn.

All I know is that Mega Drive VDP is unfortunately limited to sprites. I do mind it, because many great games like Gunstar Heroes have problems in 2-player modes.

On the other hand, Mega Drive VDP is really powerfull - it is extraordinarily complex as for the priorities and collisions of background and sprites. A real arcade adventure here.

My question is:

I know there are many gurus on this forum, and I would like to ask them if the Saturn VDP is similar to that in the Mega Drive as for the complexity and capability to handle backgrounds and sprites - I mean NOT display them but actually calculate their collisions in particular and (priorities as well, but I guess priorities is not that a problem).

so, who is the real winner?

Mega Drive with a complex 2D VDp but limited sprites (sadly) or Saturn???

 

[fonzievoltonov]

Yo,

"All I know is that Mega Drive VDP is unfortunately limited to sprites."

I don't understand what you mean by "limited to sprites"...

You speak about sprite limit (80total, 20perline/320px per line)?

"but actually calculate their collisions"

There is no colision calculation with genesis vdp...

The vdp just indicates that two (or more) sprites collided during the drawing (it doesnt output a collide table)...

 

[Borisz]

He probably means that the Saturn VDP (the VDP2 actually) can handle pictures in a whole.

 

[maiki]

Originally posted by Borisz@Mon, 2005-07-04 @ 07:34 AM

He probably means that the Saturn VDP (the VDP2 actually) can handle pictures in a whole.

[post=136264]Quoted post[/post]​

What does that mean? There is no sprite field on Saturn???

As for the Mega Drive - it is a pity they did not elaborated a more powerfull sprite capabilities, at least as Neo Geo, it would be cool to handle around 1000 sprites at once...

 

[fonzievoltonov]

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]

Originally posted by maiki@Sat, 2005-07-09 @ 05:06 AM

What does that mean? There is no sprite field on Saturn???

As for the Mega Drive - it is a pity they did not elaborated a more powerfull sprite capabilities, at least as Neo Geo, it would be cool to handle around 1000 sprites at once...

[post=136506]Quoted post[/post]​

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]

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]

Originally posted by Piratero+Mon, 2005-07-11 @ 08:22 AM--><div class='quotetop'>QUOTE(Piratero @ Mon, 2005-07-11 @ 08:22 AM)</div><div class='quotemain'>there are many many reasons for using tile rather than bitmap, one of them is being able to use multiple layers.[/b]

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

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]

Originally posted by fonzievoltonov@Sun, 2005-07-03 @ 01:14 PM



"but actually calculate their collisions"

There is no colision calculation with genesis vdp...

The vdp just indicates that two (or more) sprites collided during the drawing (it doesnt output a collide table)...

[post=136217]Quoted post[/post]​

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]

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

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]

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