PS3 vs. Xbox 360 before that was a thing.
Since Lazy Devs exist, hardware has to account for them. Imagine a car with terrible acceleration but a top speed of 1000mph/kph while being stuck in rush hour traffic.
Questions about Sega Saturn
- Thread starter Liandry
- Start date
PS3 vs. Xbox 360 before that was a thing.
Since Lazy Devs exist, hardware has to account for them. Imagine a car with terrible acceleration but a top speed of 1000mph/kph while being stuck in rush hour traffic.
When was it ready then?
We barely saw better performance or anything beyond what PS1 could do even during its last days.
If it was indeed more powerful and could bring significantly better results and what we got is this, then thats a shame.
But can someone who has actually worked with the hardware comment on this for confirmation? Capcom wasnt particularly impressed with its 3D capabilities either
Fan pages tend to have some significant bias most of the time
Im not a programmer, but from all the interviews, Saturn it actually more powerful (raw) than the PS1.
But:
Poorly designed CPU cache and RAM access, makes it hard to properly take advantage from the dual-cpu. As for the DSP, its even harder to syncronize with the dual SH-2's, and needs to be coded using Assembler..
VDP2 is very powerful, but almost useless for 3d games.
VDP1 is very awkard. Its basically a 2d scaler chip, with some tweeks to make it work for 3d. There are problems with cliping, overdraw and transparencies. Lot's of raw power, but useless for 3d.
This article has some inaccuracies/misleading statements.
VDP2 displays a whopping 2 quads without shading, not exactly a tangible T&L load. And I think you actually do have to do a lot of setup to apply perspective correction.
PS1's GPU is nominally 2 cycles per pixel without shading or texturing and 1 cycle per pixel with, while VDP1 is simply 1 cycle per pixel (and PS1 GPU is clocked higher).
Let's calculate it. VDP2 can draw 6 layers at up to 352x240, 60Hz (there's a higher resolution mode but it cuts down on the number of layers, also this is assuming NTSC). Or about 30.4 MPixel/s.
PS1 GPU can draw 2 pixels/cycle with non-transformed sprites or flat shaded pixels, or up to ~67MPixel/s. With texturing (sprites) it'll almost always be lower because of contention with the VRAM/SGRAM for cache fills, unless you have a very bland workload that runs purely from the texture cache. Still, it's probably pretty realistic to exceed 30.4 MPixel/s. But this is just a raw fillrate comparison and says nothing about the features behind that fillrate.
On that note, the VDP2 fillrate values they give for that table make no sense.
So long as the plane is not tilted on the Z axis, and the game calculates the different perspective ratios for each scanline. It's the same as SNES's mode 7 in this regard; the perspective is fixed per-scanline.
Not a form of perspective correction at all.
PS1 and Saturn have exactly the same "polygon accuracy"; vertexes are submitted as integer screen coordinates.
As far as any of the comments about using the DSP for any kind of 3D goes, I don't know of any example of a developer that did so definitively. I'd be happy to see some source that shows this, via actual analysis of game behavior and not comments in an article which can often be inaccurate (I see no way that anyone could have used it for "transparencies" for instance...)
That's not entirely true, eg PS1 GPU has subtractive blending and VDP2 doesn't.
This is just totally wrong.
No way is this true, it didn't use some kind of magic SDRAM that defied all limits of the technology to make it as fast as a small on-chip SRAM, in fact it used an off the shelf SDRAM part. I'm sure VDP1 fetches multiple 16-bit texture words in advance to hide latency (one reason why they used forward rendering...) and I'm sure that there were circumstances where VDP1 stalled waiting for textures. Maybe on those small polygons that they claimed Saturn is better at without reference.
Almost half the "access speed"? They mean bandwidth? Odd how that works when Saturn uses 16-bit SDRAMs at a lower clock than PS1's 32-bit VRAM/SGRAM.
Ah, here's where their confusion comes from. They're grossly misinterpreting the VDP2 documentation. "Cycle" in the linked terminology has nothing to do with CPU (or SDRAM) clock cycle, it refers to a loop of memory accesses performed by the VDP2. These accesses are also heavily pipelined (overlapping with each other to hide latency), which the documentation also describes although in super confusing terms and diagrams.
Nit-picking, but the improved gouraud shading has nothing to do with the SGRAM, it was an update to the GPU itself.
On that point, I had no idea the original GPU only shaded with 5-bits, all my tests were with newer PS1s. I'll have to amend my previous shading explanation to include this...
Okay this is just too much. They're using per-channel bit counts for PS1 vs entire color (three-channel) bit counts for Saturn. Saturn has 5-bit Gouraud shading, like the original PS1.
I'm not going to get into that comparison table just yet, it's just full of things that make no sense to me. Part of the problem seems to stem from the faulty claim that VDP2 runs at twice the clock speed as VDP1 and the SH2s...
Last edited by a moderator:
That sounds like a logic error, not a rendering one.
I'd like to know of games that definitively used SCU DSP for T&L.
Thanks for the link. I've looked at this thread a few times over the years and this is what first made it seem pretty apparent to me that the SCU DSP was very underutilized.
No doubt there are some games that used it for something, but I don't think there's anything there that suggests definitively that it's being used for T&L. A lot of the games on the list aren't even 3D. I think to really get an idea of what it's being used for you'd have to look at a game in an emulator and see how much of the DSP's time is spent being used and what the program looks like. Also, if available, the amount of DMA traffic going into its data RAM.
Not that a game couldn't use it for T&L if it wanted to, it's entirely possible, but it just seems like an inefficient way to do things because it can't really do divisions for perspective reciprocal calculation. The best place to perform this calculation is probably on the SH2-DIVU, where you can run it in parallel with something else. It makes a lot of sense for that "something else" to be the rest of the T&L.
I think I remember hearing about a game that used it to generate maps for water or something, maybe it was earlier in this thread?
Interesting! And if those results are meaningful, it indicates that Tomb Raider didn't much use the second CPU. In addition to it not being able to use VDP2. Given that it was only using about half of the Saturn I think it held up fairly well to the PS version!
Amazed to see that Powerslave didn't use the second CPU at all. Considering how impressive the game was at the time, that's quite something.
I could be hugely off with this distant recollection ... but I seem to recall something about how VDP1 could only do one of its transparency modes using RGB (not CLUT) texture data, and only with some kind of setup data that could be provided in the correct format by the SCU. I think I read this in relation to the Sonic R emerald level that was fully transparent.
I would not bet a remotely significant amount of money on anything I've just said though ...
You seem to have a lot of knowledge about the Saturn, what games did you programmed?
I think I recall Exophase saying he didn't work on any Saturn games, he's just read through the documentation in detail. And unlike most of us, he seems to understand it.
You seem to have a lot of knowledge about the Saturn, what games did you programmed?
I haven't programmed anything for Saturn, I was only 12 when it was released...
Everything I know about it comes from reading SEGA's documentation and talking to Mednafen's author (Mednafen recently added Saturn emulation, probably the most accurate available). This is partly due to general interest but also because I'd like to write optimized VDP1 and VDP2 emulation code at some point, especially for ARM platforms. The weird forward rendering design of the VDP1 and the sheer complexity of the VDP2 makes this a pretty challenging undertaking.
For PS1 I have written optimized (and reasonably accurate) GPU emulation and tested it against captures from games.
I think what you're thinking of is that stipulation that VDP1 blending and gouraud shading don't really work in the non-RGB framebuffer modes. I think they actually do technically work but don't give the expected results, which makes sense considering that those operations involve modifying colors directly.
That's also why all those high resolution Saturn games don't have shading, since they needed to use 8-bit paletted framebuffers.
But for VDP1 blending there isn't any setup involved, it's enabled by flipping a bit in one of the the primitive command words. All you get is 50% blending with the background.
Maybe you mean the VDP1 gouraud shading function? For that you have to store 4x16-bit values in a separate table for each primitive, where the values are packed 15bpp RGB colors for each vertex. Neither the SCU DSP or the SH2s have barrel shifters so I guess you'd probably want to pack them using MACs. Neither has an advantage that I can think of when it comes to dealing with color component values.
The Sonic R Radiant Emerald level is probably just VDP2 blending. Note that the effect meant they had to disable the depth-queuing/fog effect, making the pop-up more obvious on that level.
Last edited:
Are you insinuating that I am blaming Sony here? How the hell? Oh wait you're talking about alcohol...
When you say "Sega did/didn't" you should be a little more specific as to "which" Sega...apparently during the run of around 1992-1994 and 1995... Sega of America was making suggestions and requests for chips in next-generation hardware.
After 1996 this is a very different Sega of Japan and Sega of America...yet it was Sega of America that initiated the push for next console generation hardware in the mess of losses that became Dreamcast development.
Apparently the "subsidiary branch" was dictating or attempting to run the "parent company" in Japan...and had some influence in Project Saturn...and requested the creation of what became 32X...that SH-3/Nv2 project Eclipse and the poop storm of Developing Dreamcast...creating loses before the hardware ever launched (settlement out to over-hyped 3DFX)
Tuna...Saturn had three years...1994 to November 1995 is one year, Nov 1996 is two... and before we get to November 1997 you had the "subsidiary branch of America" which was creating more loses, make idiots out of third-party support...and word traveled to Japan fast...
As for Sonic on Sega Saturn...why don't you ask SoA's then chief about that? He pulled a game being made initially for Saturn over to the 32X...Knuckles Chaotix could've sure used the boost...also that Star Wars Arcade...
The fact was that there are three Sonic titles on Saturn...and Sonic the Fighters has been reliably rumored to have been canned due to some chief in North America who felt Sonic in a fighting game was gonna promote violence or hurt the image...
Then there's X-Treme...did you see footage...it's utter shit in 96 and still is...it's a non-creative developmed attempt at cashing in on the franchise...and worse look at the development...innocent little Sega of America was pulling devs from games they were supposed to work on...like sports...to squander on shit software with Sonic slapped on it and a PC version...just counting the ammount of teams is expensive...that's more loss...
There were games deliberately not localized which were retail in Japan...and Europe gets more credit for actually localizing SNK's King of Fighters 95 with ROM Cart and they were working on deals to localize the 4MB Ram Cartridge and X-Men vs Street Fighter...opening the gates for revisions of 1MB games and more 4MB Ram games...but more importantly SoA made that harder...but them writters have you all believing devs ran to PS1 cause it's easier...not because of SoA marketing failure going as far back as 1993 and swallowing the Dreamcast.
Famitsu makes your recollection a lie...
Sega's internal dev teams mostly mainly used assembler code...
AM2 has gone on record stating how they cracked open the CPU in Sega Model 2 being that it was so new at the time...
They also stated how the SH-2 CPU was much faster than the Sega Model 1 CPU and how Saturn had TWO of them.
CS Team which coded Virtua Racing Deluxe in 1994, went pure assembler when coding Sega Rally Championship 1995 Saturn.
Before making a mockery of Sega's devs it should be noted that again SoA's 32X was dividing resources...programming actual games or ports takes finances and time...add multiple platforms and it's no surprise that Sony has a focused advantage...add marketing incompetence and sabotage at the American branch in 1995 alone and...get the point.
Sega of America blew ten million USD marketing the Sega 32X fiasco in 1994 alone. I recall how boxes of 32X were stacked on shelves in 94 and early 95...and when put on clearance for $20.00 they made those walmart bargain bin DVDs look like taking less space.
There were British devs that same year releasing and talking about how they coded pure 100% assembler code in their PC 3d racing game...apparently they weren't the only ones and this predates 3d cards and Microsoft APIs.
There should be a modicum of respect at game development from scratch back then...it is definitely still an actual video and not some "emulator to eun on a smartphone for twelve year olds"
Last edited:
Link?
Nobody mocked the devs. The poor guys had to make games for hardware that was a bitch to get good results.
Do you have evidence that ports like Sega Rally from Arcade to Saturn (or any other game) was experiencing any lack of focus due to 32X? Or that it was the same people doing multiple ports simultaneously? 32X barely got anything and if Sega wanted a game on the Saturn, I am pretty sure they focused to make a good game primarily on that platform.
Your claim that Saturn games were affected by the 3SX sounds more like a mere assumption.
Sega, as a whole, really lost from the split of focus due to the 32X. If the resources spent on 32X, both developer and marketing, had been spent on Saturn and Mega Drive Sega would have had a much better chance of launching a successful Saturn.
Of course they lost but I was talking about the quality of the games. The way I understood it is that Akumajou suggests that Saturn wasn't getting the expected quality results from its games or that ports werent as good as they should due to making games on multiple platforms and because resources werent fully allocated.
Although I understand that better marketing and a few more games might have been released on the Saturn if they could focus only on one console, I doubt games released were visually compromised more because of that instead of the hardware peculiarities.
I am pretty sure games like Sega Rally, Virtua Cop, Virtua Fighter 2 etc looked as good as they could for their time considering the hardware.
On a related note, me and a friend are running a small game store and we got an old TV monitor for the sake of retro gaming. Today we connected it with a Saturn and tried some Sega Rally.
The memories.
My friend modded his Saturn to include a fan, a LED screen for monitoring temperature, the ability to play games from all regions, and the ability to make the console run games at either 60z or 50hz.
I find this quite interesting as AFAIK the PS1 games were running at either 50 or 60hz by default depending if the game was PAL or NTSC, whereas the Saturn was hardware forced to be limited to 50hz or 60hz depending if the console was sold to EU or Japan/US.
i.e a chipped PS1 run 60hz if the game was 60hz, and 50hz if the game was 50hz. You cant force the console to run at 50hz if the game is 60hz or vise versa. On the other hand a Saturn that was modded to play all regions also had to be modded to include a switch that changed the hz it was running at. Games were affected by both 50hz and 60hz modes regardless of PAL or NTSC region
The memories.
My friend modded his Saturn to include a fan, a LED screen for monitoring temperature, the ability to play games from all regions, and the ability to make the console run games at either 60z or 50hz.
I find this quite interesting as AFAIK the PS1 games were running at either 50 or 60hz by default depending if the game was PAL or NTSC, whereas the Saturn was hardware forced to be limited to 50hz or 60hz depending if the console was sold to EU or Japan/US.
i.e a chipped PS1 run 60hz if the game was 60hz, and 50hz if the game was 50hz. You cant force the console to run at 50hz if the game is 60hz or vise versa. On the other hand a Saturn that was modded to play all regions also had to be modded to include a switch that changed the hz it was running at. Games were affected by both 50hz and 60hz modes regardless of PAL or NTSC region
Last edited:
