This proves that when programmed properly the Sega Saturn...

Status
Not open for further replies.
see colon said:
the saturn can display sprites with up to 64 colors while the psx can handle a mere 16 colors/sprite (just like the snes). this, combined with the saturns dual VDP solution (one for backgrounds and one for sprites) and extra overal memory gave the saturn a nice advantage in 2d.
The PSX could use any of its texture formats for its sprite mode. We definately supported 256 colour CLUTs and I think true colour (sure we had a true colour static background). PSX had 66 MPixel fill rate in sprite mode. Thats was enough for a fair few background layers.

The biggest limitation was the 512K VRAM, you could upload from main RAM in the OT but it was tricky and fairly slow. Still it was handy for backgrounds.
 
I like hearing info on all the old systems, so feel free to keep it up. ^_^ Just "consider the source" on the more trollish comments and keep the structured informational flow the way it should be. :)
 
Lobotomy's three FPS games for Saturn really show off how much VDP1 can render - look at Quake, it's more or less an exact conversion of the PC game.
Coincidentally, the main programmer from Lobotomy claims that their games ran much faster on PS1 then they did on Saturn :p

http://www.beyond3d.com/forum/viewtopic.php?t=14992

Ezra: The most striking thing about the PSX port was how much faster the graphics hardware was than the Saturn. The initial scene after you just start the game is pretty complex. I think it ran 20 fps on the Saturn version. On the PSX it ran 30,but the actual rendering part could have been going 60 if the CPU calculations weren't holding it up. I don't know if it would have ever been possible to get it to really run 60, but at least there was the potential.

Other than that, it would have looked identical to the Saturn version. Except for some reason the PSX video output has better color than the Saturn's.

So I know something about the PSX. And really, if you couldn't tell from the games, the PSX is way better than the Saturn. It's way simpler and way faster. There are a lot of things about the Saturn that are totally dumb. Chief among these is that you can't draw triangles, only quadrilaterals.
 
mkillio said:
Sorry to go a little off topic but I didn't think that it was worthy of its own thread.

Which was more technically powerful Genesis or SNES and how? I have friends that say Genesis and I totally disagree but I have no facts to back my self up.

I say SNES. Multiplatform games always looked best on SNES, SNES could actually compete graphically with the Sega CD and Sega 32x, and the best SNES games look better than the best Genesis games. Vectorman is no match for Donkey Kong Country, and I think the SNES 3d games looked better too.

I've heard people say the Genesis has a more powerful cpu, but the only evidence I've ever seen for this is mhz. Assuming that's true then you could say the SNES would be like a 486 with a voodoo compared to a pentium with software rendering.

BTW, did Genesis even have stereo sound? I don't recall any of my genesis having an option for it in the menu, while many of my snes games did. Not to mention I don't ever recall anything on the genesis sounding as good as what squaresoft did on the snes, and the mario games sounded better than the sonic games by far.

N64 has stock 4MB unified, and can be expanded to 8MB. Saturn can be expanded to 8.5MB with a 4MB RAM card.

Did the saturn have more texture ram?

IIRC, while N64 does have a functional 2D ucode available, not one single game actually used it, favouring 'faked' 2D using textures on screen-aligned polygons.

Not even the 2d puzzle games like Pokemon whatever and Dr. Mario? Puyo Puyo Sun? Star Soldier(the crappy early 2d shooter on the n64)? The New Tetris? Worms Armageddon? 64 Wars(come on, this one had to have)? The emulated Pokemon games in Pokemon Stadium?

And on that note I dunno why PS1 is dubbed to be weak in 2d either, absurdly enough, sometimes even compared to older machines.

Does it lack some hardware effects like sprite scaling and rotation, mode 7, etc? Powerful but not well featured, sort of like the genesis?

VDP1 has enough sprite-generation power to fake full, damn good looking 3D worlds on its own (Shining Force III, Burning Rangers, Panzer Dragoon II and Saga, QUAKE/Duke3D/PowerSlave(Exhumed in Europe), and of course the unreleased Shenmue appears to be doing next to nothing on VDP2 as usual). Lobotomy's three FPS games for Saturn really show off how much VDP1 can render - look at Quake, it's more or less an exact conversion of the PC game.

So what was the point of having the VDP2 if it wasn't used? Why wasn't it used?
 
Fox5 said:
I've heard people say the Genesis has a more powerful cpu, but the only evidence I've ever seen for this is mhz. Assuming that's true then you could say the SNES would be like a 486 with a voodoo compared to a pentium with software rendering.
The Megadrive has a 8Mhz Motorola 68000, the 68000 was a stunning processor for its age. Internally 32 bit, it had a 16 bit bus so considered 16 bit. 8 general purpose data registers, 8 address registers. A nice CISC instruction set, it was great little processor (I learnt how to program on it).

An Atari ST or early Apple Mac were basically just this processor on its own. The CBM Amiga, SEGA Megadrive and X68000 were this processor with extra custom chips. It was a close to being in the IBM PC as well.

The SNES has a 3.58Mhz 65812, is the 16 bit version of the venerable 6502. It really isn't in the same class as the 68000, the main reason it was used was for backwards compibility with the NES (yes it was always the intention to ship with NES compatibiltiy). It has 16 bit registers, 3 of them! The accumalator and the X and Y registers (actually it has 2 memory segment registers to allow it to address up 24 bit addresses).

Megadrive wins hands down on the CPU stakes.
 
DeanoC said:
Fox5 said:
I've heard people say the Genesis has a more powerful cpu, but the only evidence I've ever seen for this is mhz. Assuming that's true then you could say the SNES would be like a 486 with a voodoo compared to a pentium with software rendering.
The Megadrive has a 8Mhz Motorola 68000, the 68000 was a stunning processor for its age. Internally 32 bit, it had a 16 bit bus so considered 16 bit. 8 general purpose data registers, 8 address registers. A nice CISC instruction set, it was great little processor (I learnt how to program on it).

An Atari ST or early Apple Mac were basically just this processor on its own. The CBM Amiga, SEGA Megadrive and X68000 were this processor with extra custom chips. It was a close to being in the IBM PC as well.

The SNES has a 3.58Mhz 65812, is the 16 bit version of the venerable 6502. It really isn't in the same class as the 68000, the main reason it was used was for backwards compibility with the NES (yes it was always the intention to ship with NES compatibiltiy). It has 16 bit registers, 3 of them! The accumalator and the X and Y registers (actually it has 2 memory segment registers to allow it to address up 24 bit addresses).

Megadrive wins hands down on the CPU stakes.

What happened to NES compatibility? Genesis had Master System compatibility.

BTW, I thought the SNES had a sony cpu. Ok, so the genesis does have a much faster cpu, but it still doesn't have the graphics abilities of the snes.
 
You have to realize though, the Genny was released in Q4 1988, whilst the snes was released in Q4 1990.

Thats a 2 year technological gap.

Yet the Genny still had a radically superior CPU.

If it was released alongside the snes, then it would've had radically superior graphics hardware aswell.

Sega System 32 level.

It would've been no contest.
 
Yes, and had it been launched last year it could have had Radeon 9800 level graphics. That system would have really smoked Super Nintendo's worthless backside good and hard. What's your point? It launched in 1988, not 1990 or 1888 or 2088.

Dean:

Do you know why Famicom/NES compatibility was not included on the SFC/SNES? Did the fact that the 6502 had some illegal opcodes that returned meaningful results (which were later mapped into legitimate [albeit different] instructions on the 65816) play any part?
 
SegaR&D said:
You have to realize though, the Genny was released in Q4 1988, whilst the snes was released in Q4 1990.

Thats a 2 year technological gap.

Yet the Genny still had a radically superior CPU.

If it was released alongside the snes, then it would've had radically superior graphics hardware aswell.

Sega System 32 level.

It would've been no contest.

What did the System 32 do? Sega had addons for the genesis which weren't huge leaps in 2d graphics over the snes, and could system 32 outperform the snes in fake 3d? Perhaps snes would have had tons of mode 7 games or fx chip games if sega had a more powerful system.

BTW, was the faster cpu of the genesis the reason why I the sonic games had non flat terrain and loops and bridges that moved when sonic ran on them while I don't think the mario games(and maybe not even any snes games) had anything like that? I don't think any snes games matched the speed of the sonic games either.

Also, there's...
yoshis-island-super-mario-world-2-3.jpg


Sonic%20and%20Knuckles.jpg


A noticable difference in quality between super mario world 2 and sonic and knuckles. Super Mario World 2 has better special effects(like transparencies), and higher resolution, but sonic and knuckles looks better overall and has a better looking background, though that may be largely due to art design which sonic team was always great at.

Super Metroid would probably be a better indication of the pinnacle of non prerendered snes 2d though, or were the sprites in it(and the sonic games as well) prerendered while mario was handdrawn?
 
akira888 said:
Do you know why Famicom/NES compatibility was not included on the SFC/SNES? Did the fact that the 6502 had some illegal opcodes that returned meaningful results (which were later mapped into legitimate [albeit different] instructions on the 65816) play any part?

I'm not sure anybody knows outside Nintendo why they shelved it (as such an obviously late date) but the urban legend has always been that it would cost a few cents more...
 
DeanoC said:
akira888 said:
Do you know why Famicom/NES compatibility was not included on the SFC/SNES? Did the fact that the 6502 had some illegal opcodes that returned meaningful results (which were later mapped into legitimate [albeit different] instructions on the 65816) play any part?

I'm not sure anybody knows outside Nintendo why they shelved it (as such an obviously late date) but the urban legend has always been that it would cost a few cents more...

I believe the quote was, out of the box it would've cost Nintendo $75 more per unit, thanks to cartridge slot differences, additional hardware such as sound, fixing the 'fixed broken opcodes' issue, etc.

Chief among these is that you can't draw triangles, only quadrilaterals.

Admittedly it was dumb that Saturn didn't support triangle primitives at all, but this statement leads me to believe that he never looked into twisted quads... quads aren't totally idiotic - the primary issue with them is that triangles are simply more efficient in every way.
 
Tagrineth said:
Chief among these is that you can't draw triangles, only quadrilaterals.

Admittedly it was dumb that Saturn didn't support triangle primitives at all, but this statement leads me to believe that he never looked into twisted quads... quads aren't totally idiotic - the primary issue with them is that triangles are simply more efficient in every way.

It wasn't really quads that was the issue but the use of forward texture mapping rather than the much more useful backwards texture mapping.

To those who prehaps haven't heard of the issue (all hardware today uses backwards) I'll try and explain.

Backwards texture mapping.
You iterate across the triangle or quad in screen space, calculate a UV coordinate and lookup that into the texture. You hit a texel only if it appears on screen and you only hit each screen pixel once.

Forward texture mapping.
You iterate across the texture, for each texel calculate the screen position it hits and put the texel on the screen. The problem is when you minify the texture onto the screen, you hit a screen position several times. That breaks transparency and wastes fillrate. One advantage is that because you are iterating into screen space, you can produce non-linear screen segments (i.e. curves) but in practise is very hard to use as there are only a restricted set of curves surfaces you can produce.

Forward texture mapping comes from thinking about scaling and distorting sprites. 3DO and SEGA Saturn used it, just about everybody does backward texture mapping.

I may have got the forward and backwards the wrong way. Its been a long time.
 
Fox5 said:
SegaR&D said:
You have to realize though, the Genny was released in Q4 1988, whilst the snes was released in Q4 1990.

Thats a 2 year technological gap.

Yet the Genny still had a radically superior CPU.

If it was released alongside the snes, then it would've had radically superior graphics hardware aswell.

Sega System 32 level.

It would've been no contest.

What did the System 32 do? Sega had addons for the genesis which weren't huge leaps in 2d graphics over the snes, and could system 32 outperform the snes in fake 3d? Perhaps snes would have had tons of mode 7 games or fx chip games if sega had a more powerful system.

SYSTEM 32

ALIEN 3

alien3_a.gif


GOLDEN AXE

ga2_a.gif


RADMOBILE - 1990 (FIRST SYSTEM32 GAME)

radm.gif


radm_a.gif


SEGASONIC THE HEDGEHOG

segasonic_a.gif


OUTRUNNERS

outrunners.gif


outrunners_a.gif


outrunners_b.gif


outrunners_c.gif


STADIUM CROSS

scross_b.png


HARD DUNK

harddunk_a.gif


BURNING RIVAL

burnriv_a.gif


F1 EXHAUST NOTE

f1en.gif


f1en_a.gif


SPIDER-MAN

spidey_a.gif


ARABIAN FIGHT

afight_a.gif
 
Tagrineth said:
DeanoC said:
akira888 said:
Do you know why Famicom/NES compatibility was not included on the SFC/SNES? Did the fact that the 6502 had some illegal opcodes that returned meaningful results (which were later mapped into legitimate [albeit different] instructions on the 65816) play any part?

I'm not sure anybody knows outside Nintendo why they shelved it (as such an obviously late date) but the urban legend has always been that it would cost a few cents more...

I believe the quote was, out of the box it would've cost Nintendo $75 more per unit, thanks to cartridge slot differences, additional hardware such as sound, fixing the 'fixed broken opcodes' issue, etc.

Chief among these is that you can't draw triangles, only quadrilaterals.

Admittedly it was dumb that Saturn didn't support triangle primitives at all, but this statement leads me to believe that he never looked into twisted quads... quads aren't totally idiotic - the primary issue with them is that triangles are simply more efficient in every way.

Why didn't they just use the same cart slot, or how about some emulation? They had the super gameboy, how about the super....oh wait.

Hmm, system32 looks pretty well superior to the snes. But I have 2 questions...
Did it supports all the sprite scalling and rotation effects that the snes did? I always noticed that arcade games tended to lack those effects.
If it was made into a console version wouldn't it have been more expensive than the snes, had less memory than the arcade variant, and have smaller carts? If so, those could have minimized the graphical difference.(isn't the quality of sprites generally dependent on the amount of memory available?)
 
Fox5 said:
Hmm, system32 looks pretty well superior to the snes. But I have 2 questions...
Did it supports all the sprite scalling and rotation effects that the snes did? I always noticed that arcade games tended to lack those effects.
System 32 gave you a shitload (for the time) of scaled sprites, but no rotation. I believe the only Sega 2D board with rotation was the "Y Board" (Power Drift, Galaxy Force II). It only allowed for rotation as a "post-effect" on the whole screen, though. All blitting was made with scaled sprites only.

DeanoC said:
[On Saturn...]
It wasn't really quads that was the issue but the use of forward texture mapping rather than the much more useful backwards texture mapping.
Hmm, I thought the traditional forward-mapping algorithm didn't allow for enlargement of textures without gaps between texels..?
 
Status
Not open for further replies.
Back
Top