Support NeoGAF

[RetroGamingUK]

Did Sega 32x also use rectangular polygons? I see no warping textures on the walls. Only when they are close to sides of the display.

32X only has one single VDP chip

The MegaDrive/Genesis is responsible for background layers while the 32X renders the sprites in 2D games and the quads in 3D games.

Worth noting the MegaDrive couldn’t do Mode7, so in the care of MetalHead it appears that 32X is rendering everything you see.

 

[nkarafo]

Did Sega 32x also use rectangular polygons? I see no warping textures on the walls. Only when they are close to sides of the display.

Maybe i'm wrong but aren't all 3D games for 32X software rendered? Like it doesn't have dedicated 3D hardware, which is usually the cause of such artifacts if the hardware doesn't support perspective correction. Software rendering is slower but cleaner. That's why DOOM on the Saturn doesn't have any warping at all because it's software, it's also one of the reasons why it runs like ass.

 

[PaintTinJr]

RoboFu I have a question for you, as you seem to be the most knowledgeable around here about Saturn dev.

I have read the entire dev documentation back then about VDP1 and VDP2 and how graphics were built on the console. My understanding is that VDP2 receives anything generated by VDP1 as a single layer, and can then prioritize this layer against the several other layers it manages directly. Another thing I understand is that pixels coming from VDP1 can be set to either display other VDP1 pixels behind, either VDP2 pixels. But not both. This limits transparency use-cases.

What I currently don't really understand is how Team Andromeda achieved full transparency from a VDP2 layer that cuts 3D models in half. Example here :

You can clearly see the rocks, in 3D, being cut at their base by the transparent VDP2 water layer, and the rocks below being shown through the transparent water. They did it too in Panzer Zwei (underground boss). Obviously something is happening here, and it is in no way the cheap trick they did in the first level of Panzer 1.

Any chance you can link those, just in case there's competing document versions?
edit:
Never mind so, the link to all of them in the thread.

 

[polybius80]

I have placed a dozen of comparisons side-by-side.

Show them to any random person and ask: what is he/she seeing there?
Deformed roads on Saturn? No.
Deformed everything on PSX? Yes.

saturn have a problem in deforming roads in games more or less depending how the game is made you have been shown that happens, there is even a video that was just released comparing many games and you can clearly see one were the whole scene collapses when closes to the camera, the idea that nobody notices is a logical fallacy and saying that 99% of games doesn't have that is also a fallacy, I don't know how you come to a forum dedicated to gaming were there are people that played the system at the time there are devs even explaining how the graphics worked, were peole make 400% zoom in games to compare details and expect people to believe such thing, specially when the most impressive games of the system show the graphical problems what happens there? every famous games is art of that 1% of games witth graphical glitches and the rest not? the famous saturn games are made by less capable enginers?, one thing is to point to games with minimum warping like alien trilogy but trying to pretend is the norm is a straight up lie, as I said saturn has other problems too

 

[Lysandros]

Saturn had much more horsepower technically, but it's multi co-processor setup, use of quads instead of triangles, and lack of hardware features like transparency really hurt it.

What a wild phantasy. We have hefty amounts of informed posts in this very thread explaining the realities why that is not even remotely true though. It suffice to read.

 

[s_mirage]

Oh you mean from here?

Saturn official documentation - Sega Retro

segaretro.org

lol well yeah where do you think I am getting the technical information to program for the Saturn? Sega of America themselves ?

No. As far as I can tell, the language you used (bilinear approximation, medium polygon accuracy, for example) comes from Segaretro themselves, not the Sega documentation. And as for your programming, well, demonstrate it if you're going to appeal to authority. For all anyone here knows, you've just set up an environment for Jo Engine and compiled the samples.

and I have already said the biggest difference is that PS1 use real UV texture coordinates for its polygon faces. meaning you can " lay" your polygon triangle on any part of the texture. You can easily repeat textures across any model if you want and stretch a single texture across a 3d model.

Saturn does not use UV mapping. it is one bitmap stretched between four rectangle vertices. its always one texture to one quad. To make a textured model you split your model texture into individual textures. Some devs have found ways to fake UV to make environmental map effects though. to repeat textures you need just as many quads as texture repeats.

anywho.. so again PS1 interpolates its textures using triangles in a affine manner. we all understand that, but because its a triangle it will never be straight at an angle because a rectangular texture goes across two triangles that are interpolated differently where as on the saturn it uses a rectangle texture for a rectangle quad and the way it skews that rectangle to calculate the texture interpolations is more akin to a bilinear interpolation so you do not get as much distortion.. it is as simple as I can put it.

it all really makes sense if you think about it.

I know what UV mapping is, and I know why textures on Playstation warp. I literally said, "I'm not saying that the exact method is identical, it can't be". What I really want is a little expansion of how this "bilinear approximation" works. As far as I can see, the term is not used in the VDP1 manual, it's not used in the SGL manual, it's not used in Sega's tutorials. Where is it used? Oh, of course, Segaretro... and their source for it is some random ass page from '98.

Did Sega 32x also use rectangular polygons? I see no warping textures on the walls. Only when they are close to sides of the display.

Everything 3D on the 32X is software rendered. You can use whatever rendering techniques you want limited only by RAM and performance.

 

[polybius80]

Did Sega 32x also use rectangular polygons? I see no warping textures on the walls. Only when they are close to sides of the display.

software renderer games as long as treating correctly the quads should have less problems, being simpler games also helps

 

[RetroGamingUK]

simpler games as long as treating correctly the quads should have less problems

Impressive that this is fully rendered in quads on the 32X

If this were a Saturn game, the floor would be a Mode7 style infinite plane.

 

[polybius80]

Impressive that this is fully rendered in quads on the 32X

If this were a Saturn game, the floor would be a Mode7 style infinite plane.

yes like street racer as long as there is no problem with the movement to look detached as happens in destruction derby

 

[Parazels]

How is The need for speed so good on 3DO?
Also rectangular polygons?

 

[Parazels]

Textures 3DO (!) vs PSX:

 

[s_mirage]

How is The need for speed so good on 3DO?
Also rectangular polygons?

Yeah, 3DO uses quads too. I don't know what the performance hit was, but it doesn't seem to suffer the Saturn's transparency shortcomings either.

 

[RoboFu]

RoboFu I have a question for you, as you seem to be the most knowledgeable around here about Saturn dev.

I have read the entire dev documentation back then about VDP1 and VDP2 and how graphics were built on the console. My understanding is that VDP2 receives anything generated by VDP1 as a single layer, and can then prioritize this layer against the several other layers it manages directly. Another thing I understand is that pixels coming from VDP1 can be set to either display other VDP1 pixels behind, either VDP2 pixels. But not both. This limits transparency use-cases.

What I currently don't really understand is how Team Andromeda achieved full transparency from a VDP2 layer that cuts 3D models in half. Example here :

You can clearly see the rocks, in 3D, being cut at their base by the transparent VDP2 water layer, and the rocks below being shown through the transparent water. They did it too in Panzer Zwei (underground boss). Obviously something is happening here, and it is in no way the cheap trick they did in the first level of Panzer 1.

Edit : might be possible if you get the 3D objects in two passes, and then display the picture. This would work at 30fps.

There is a way to send the VDP1 framebuffer to the VDP2 to create transparency effects like this. We only seen vdp juggling like this in the later games.

the down side is it is a solid transparency only. No shaded sides or overlap and as you see the ripple effect does not turn with the player.


another example:

burning ranger also had texture clipping near the camera. there was no warping what so ever. it is clearly the goto show piece for the Saturn.




sonic R was different.
The traveler tales guy made a video on how he did it and the issue with transparencies and quads all together.

 

[Stuart360]

A few people have said this over the years. All i'd say is what difference does it make if 99% of the games didnt show it.

Same with the 360 vs PS3 situation.

 

[RoboFu]

here a cool interview with Andy Gavin from the REAL Naughty Dawg

he explains how he got Sony to let him bypass the C api calls.

 

[cireza]

There is a way to send the VDP1 framebuffer to the VDP2 to create transparency effects like this.

I know about this indeed, however I think this is a different technique here as it looks simply pixel perfect and 30fps smooth as well. Burning Rangers shows that cutting the zones to apply transparencies real-time costs a lot of process time.

I put an edit in my original post, guessing that it might be done in two passes. One that sends to bottom of the rocks, VDP2 gets the layer from VDP1, applies the water plane (transparency occurs), doesn't push the picture but waits for the second pass. VDP1 then sends the top of the rocks, VDP2 puts them on top of the previously prepared layer, sends the picture and we are good. Just a guess though.

 

[s_mirage]

RoboFu I have a question for you, as you seem to be the most knowledgeable around here about Saturn dev.

I have read the entire dev documentation back then about VDP1 and VDP2 and how graphics were built on the console. My understanding is that VDP2 receives anything generated by VDP1 as a single layer, and can then prioritize this layer against the several other layers it manages directly. Another thing I understand is that pixels coming from VDP1 can be set to either display other VDP1 pixels behind, either VDP2 pixels. But not both. This limits transparency use-cases.

What I currently don't really understand is how Team Andromeda achieved full transparency from a VDP2 layer that cuts 3D models in half. Example here :

You can clearly see the rocks, in 3D, being cut at their base by the transparent VDP2 water layer, and the rocks below being shown through the transparent water. They did it too in Panzer Zwei (underground boss). Obviously something is happening here, and it is in no way the cheap trick they did in the first level of Panzer 1.

Edit : might be possible if you get the 3D objects in two passes, and then display the picture. This would work at 30fps.

AFAIK, you can set per-pixel priority values for quads/sprites as long as they are palletized, and you can tie the priority to whether blending is performed using the color calculation condition and colour calculation condition enable bits.

I took a look at Zwei using Yaba Sanshiro. The water is set at priority 3, so behind the sprites which are priority 4 or 5. The pause overlay is set to priority 7. However, the color calculation condition is set to 4, and the colour calculation enable bit is set equal to priority. Basically, the geometry is all higher priority than the RGB0 background so would occlude it, but I'm assuming the sections below the water have the same priority as the color calculation condition (4) and so are blended instead. The stuff above the water is likely priority 5. I really wish the emulator had a per-pixel examination function.

Source:

SEGASATURN Developer's Documentation

docs.exodusemulator.com

SEGASATURN Developer's Documentation

docs.exodusemulator.com

There's no sign that it's doing any multipass rendering like Burning Rangers.

 

[RoboFu]

No. As far as I can tell, the language you used (bilinear approximation, medium polygon accuracy, for example) comes from Segaretro themselves, not the Sega documentation. And as for your programming, well, demonstrate it if you're going to appeal to authority. For all anyone here knows, you've just set up an environment for Jo Engine and compiled the samples.



I know what UV mapping is, and I know why textures on Playstation warp. I literally said, "I'm not saying that the exact method is identical, it can't be". What I really want is a little expansion of how this "bilinear approximation" works. As far as I can see, the term is not used in the VDP1 manual, it's not used in the SGL manual, it's not used in Sega's tutorials. Where is it used? Oh, of course, Segaretro... and their source for it is some random ass page from '98.




Everything 3D on the 32X is software rendered. You can use whatever rendering techniques you want limited only by RAM and performance.

lol no I'm running sgl but I already admitted I only got as far as a few spinning cubes and reading the docs.

Right now I'm more interested in working on a nes game using cc65. Then maybe a genesis game after that.

 

[PaintTinJr]

SCU doing perspective division? I did not think it had a divider unit at all…

Yeah I pressed CoPilot on that point when it suggested that the SCU did that in its first response and it gave me a inverted response, saying it couldn't find proof that it couldn't do projection, and that was its position after I asked it specifically if any of the processors in the Saturn had an FPU.

So you're probably right, but for whatever reason it suggested the SCU could do it.

After the docs being linked I went and checked and can confirm that the SCU DSP doesn't contain the ability to divide directly, even though it is clocked at 14Mhz and on reading (Addendum to) the SCU DSP Assemblers User manual the manual shows that matrix calculations can be done on it out with doing Control Unit work, and it can seemingly do those matrix calculation in parallel.

AFAIK for trying to understand the assembly it does two 16bit OPS at a time in last examples using the Low and High areas of the registers - I don't know assembly other than 6 weeks of a traffic lights project programming a Uni decades ago - But unless I'm missing something the SCU DSP should have enough memory to do some perspective division projections work, just needing to implement the missing division capability with recursive subtraction and do it with two different values at the same time to be able to use the parallelism. And obviously all the other maths would need to be in expand fractions in advance so the recursive subtraction (division) was only done once per matrix vector cell.

I would guess with the numbers being quite small signed whole integer numbers for the resolution coordinates, vector values and Frustum FOV and near/far plane values the actual divisions would have limited recursion using subtract. And maybe only be 5-6 times less efficient than having an actual DIV OP, but I'm hopefully someone skilled in assembly could weigh in on that and if it actually adds an meaningful geometry processing for complexity.

 

[cireza]

AFAIK, you can set per-pixel priority values for quads/sprites as long as they are palletized, and you can tie the priority to whether blending is performed using the color calculation condition and colour calculation condition enable bits.

I took a look at Zwei using Yaba Sanshiro. The water is set at priority 3, so behind the sprites which are priority 4 or 5. The pause overlay is set to priority 7. However, the color calculation condition is set to 4, and the colour calculation enable bit is set equal to priority. Basically, the geometry is all higher priority than the RGB0 background so would occlude it, but I'm assuming the sections below the water have the same priority as the color calculation condition (4) and so are blended instead. The stuff above the water is likely priority 5. I really wish the emulator had a per-pixel examination function.

Source:

SEGASATURN Developer's Documentation

docs.exodusemulator.com

SEGASATURN Developer's Documentation

docs.exodusemulator.com

There's no sign that it's doing any multipass rendering like Burning Rangers.

Thanks, I will further check the docs eventually. It doesn't look too complicated a solution in the end.

 

[Panajev2001a]

After the docs being linked I went and checked and can confirm that the SCU DSP doesn't contain the ability to divide directly, even though it is clocked at 14Mhz and on reading (Addendum to) the SCU DSP Assemblers User manual the manual shows that matrix calculations can be done on it out with doing Control Unit work, and it can seemingly do those matrix calculation in parallel.

AFAIK for trying to understand the assembly it does two 16bit OPS at a time in last examples using the Low and High areas of the registers - I don't know assembly other than 6 weeks of a traffic lights project programming a Uni decades ago - But unless I'm missing something the SCU DSP should have enough memory to do some perspective division projections work, just needing to implement the missing division capability with recursive subtraction and do it with two different values at the same time to be able to use the parallelism. And obviously all the other maths would need to be in expand fractions in advance so the recursive subtraction (division) was only done once per matrix vector cell.

I would guess with the numbers being quite small signed whole integer numbers for the resolution coordinates, vector values and Frustum FOV and near/far plane values the actual divisions would have limited recursion using subtract. And maybe only be 5-6 times less efficient than having an actual DIV OP, but I'm hopefully someone skilled in assembly could way in on that and if it actually adds an meaningful geometry processing for complexity.

It sounds like unless you were to do the same algorithm in the SH2s you would have mixed precision for vertices processed by the DSP and by the processors which does not sound particularly fun. Parallelism would allow you to process 2 vertices every two cycles. Extra latency, running at lower clockspeed, not the second SH2 but the SCU DSP seems one of the late additions to make it more competitive with PSX on paper at least (latency to move the data around seems like it would not make things fun / would easily cause a lot of stalls… need to understand more how memory would be moved around and what control you had on each processor’s local memory…). On top of the SCU DSP I think the late additions to make it more 3D optimised are probably a lot of small changes here and there in components that were already there (I would not rule out one or two more spins of both the VDPs for example).

From a certain point of view the Saturn appeals to me, like PS2 and PS3 (but especially like PS2). A puzzle to solve… all these units with their purpose and a way to combine them to get good results.

It would make me feel good to tame it for sure, but as a business if I did tame it I feel like I would be outcompeted by a cheaper team pushing the same (for users) or almost the same on PSX for a fraction of the cost (while Saturn is full of “nobody else does this in this way or will ever do it like this again” … although forward texturing makes me think with more memory and faster storage it would have been fun to do a MegaTexture based engine that rendered a lot of small unique composable textures swapping sprite sets rendered per frame… then again yet another must do it like this only for Saturn thing as John put in the video… large quads poor performance and swimming, but 3D non flat mesh cannot use a larger quad to stretch a texture you need to break the texture in smaller unique textures to compose the surface with…). I think PS2 and PS3 when mastered and pushed hard had a greater return on investment though and the whole design as a whole, more on PS2 than PS3 where the nVIDIA GPU was added late and with bugs like the FlexIO implementation for example that betrayed the original design, was laid out together in a difficult yes but more holistically designed or better designed for the purpose task.
Dev that mastered and optimised their engine for PS2 for example could trade blows with consoles like Xbox that came out later and with much more powerful specs too (the GS ability to switch state/flush buffers per object or more even was something that was just much much slower on any other GPU even to this day compared to proper patterns that reduce state changes).

 

[Team Andromeda]

Stories about the Sega Saturn emerge every time that make me imagine a different timeline.

FFVII entered Sega's negotiating table after Square Enix broke away from Nintendo. The deal wasn't closed because Sony offered something better: helping with marketing and distribution in the West.

Final Fantasy 7 Could Have Been A Saturn Game

A new document from a longtime SEGA employee details the company's attempts to have Square release Final Fantasy 7 on the Saturn hardware.

gamerant.com

Sega made a secret demo of Dragon Quest to demonstrate the console to Enix. The Japanese Sega wanted more RPGs on the console.

Ex-Sega Staffer Confirms "Secret" Dragon Quest Demo For Saturn

"It was said to be a top secret within the company"

www.timeextension.com

It's no story with RE 2 Capcom couldn't have made it any clearer that the game didn't use the 4MEG and was dropped because of Dreamcast. I do suspect a type in the SSM print over CPU instead of GPU and we all know the VDP1 was a bottleneck of Saturn .

IMAG0028 by Mega Drive, on Flickr


Over the breakaway with Nintendo for FF7 Square said they were looking at all other parties in an official announcement that was covered at the press. I seem to remember it being around the same time as SEGA and Bandai were in talks
Hironobu Sakaguchi told Retrogamer in a FF feature that one of the main reasons for going with SONY was because SONY agreed to give the game a massive push in America and how at the time Square was looking to expand out of Japan.
I really can't be bothered to dig through my Retrogamers mags to find it.

It seems that Skies of Arcadia's real creator, Shuntaro Tanaka, didn't ditch completely that idea years later...

It was with an online interview with SEGA Europe and the late great Kodama-san that I 1st learned of it being a Saturn project, that's sadly no longer up. Rieko also confirmed it years later, during an interview with Kotaku

Rieko Kodama: At the beginning of the project, Skies of Arcadia was originally planned to be on the Sega Saturn console, but production eventually was set in motion for the Dreamcast. This is when we started considering the concept of a world filled with airships flying around its skies. This contrasts with a previous concept where the story would have revolved around battling on top of trains and on land in general.

https://kotaku.com/my-childhood-dream-had-come-true-a-belated-interview-w-1834310414

RIP Rieko.

 

[Drell]

Ah! I get it now, this is the new "Was the Dreamcast really powerful at launch" topic.

 

[SweetTooth]

Ah! I get it now, this is the new "Was the Dreamcast really powerful at launch" topic.

A never ending cycle of hurt SEGA fans trying to secure a victory of any kind

 

[Geometric-Crusher]

Sega needs to make a new console so these guys can leave the past in the past, especially a flop past.

 

[Little Chicken]

This game still holds up pretty well

 

[thicc_girls_are_teh_best]

Saturn's geometry throughput simply isn't higher though. Even sticking to theoretical figures and assuming the almost impossible dream scenario where the two SH2s works perfectly in parallel at 100%, the theoritical ceiling is in fact much higher (three times as much) on PS1 due to GTE's abilities essentially. Fafalada already addressed the subject.

Yeah, you're right and I don't want anyone to think I'm underplaying the GTE here. I was coming at that quote more as playing devil's advocate and supposing even if what that person was saying, there would've been other reasons why the theoretical peak for Saturn's geometry abilities never manifested due to other aspects of the architecture bottlenecking that theoretical performance.

In general, people really do underestimate the GTE on average though. For 3D there was nothing in Saturn that could really compete with it, even if you also factored in the DSP (which again, had to send results along the bus to the CPUs to have anything meaningful done with the data, so that would eat up cycles).

I don't think I ever said dominating, but Saturn had a lead of a million units and had FF 7 come out to Japan it would have ensured the Saturn won. I seem to remember even the Panzer Dragoon team saying that SEGA had thought they won Japan until FF7 when at the GDC on the making of Panzer Dragon
ALPS gave SEGA Saturn a market share of 42% to the PS 36% or maybe 38% in July of 1996 I seem to recall

Well this is assuming a couple things. For one it's assuming Squaresoft made FF VII for Saturn; the truth is Squaresoft already had access to Saturn architecture details and kind of wrote the system off early on due to aspects of the architecture they didn't like. Honestly I don't think they were ever seriously considering the Saturn as a development platform; it was always between Sony and Nintendo for them.

You have to also consider that early on SEGA of Japan had an advantage of prior retail relations securing cache as a console manufacturer in the region, that Sony of Japan did not have, and had to build up with the PS1. People always say that Sony used their distribution advantage at retail to muscle out SEGA but if that were true, surely the PS1 would've had a massive lead in Japan even going as far back as '95. But it didn't, as you say, so which is true? I'm not asking you that specifically, just the people who try harping on Sony leveraging their retail partners as an advantage against SEGA and Nintendo; I think people exaggerate that advantage significantly.

Another thing is that during the 5th-gen era SEGA of Japan had a habit of reporting sold-in to retailers; Sony of Japan also reported sold-in but they also reported sold-through to customers. Therefore it's sometimes hard to get an exact read on what amount of Saturns had been sold to customers in Japan vs. sold to retailer outlets, whereas you generally always had an idea of both for PS1.

Anyways, yes it's probably worth saying that if FF VII came to Saturn and not PS1 that would've ensured Saturn's success over PS1 in Japan, but that assumes Squaresoft even wanted to ever work on the Saturn to begin with (again, their priorities that gen were between Nintendo and Sony; if Sony didn't work on getting closer with Squaresoft then they would've just likely stuck with Nintendo vs. go over to SEGA), and also assumes SEGA did something different with Dreamcast. They still had global reasons to push Dreamcast for late '98 in Japan which would've eaten away at the Saturn's market there post-'97, so it's still possible PS1 would've caught up and surpassed Saturn in Japan anyway thanks to releases in '98 and '99, then DQ VII in 2000.

IMO, at best FF VII would've helped extend Saturn as the sales leader in Japan for maybe a year, and maybe to a 1.5 million lead. But PS1 would've likely still clawed away at that between '98 and '99, then blown past it in 2000. PS1 being the market leader in Japan was inevitable, even without FF VII, but I could see Saturn having a larger lead over N64 lifetime in such a scenario for the Japanese market.

I will say, though, that Saturn having FF VII probably would've helped on some level globally as well, and maybe help the Saturn do somewhat better worldwide than it did. Maybe to go on selling 20-25 million instead of ~ 10 million. But that would've also required not basically killing retail presence for the system in 1998, and SEGA being a ghost in the West for '98 and most of '99 until Dreamcast launched.

And as for SEGA Rally breaking records for the ever best selling CD game that was the case in the UK at the time.
I'm see to remember SEGA Japan holding the record in Japan for the most pre-ordered game over there with VF2 with over a million Pre orders. Those were the days

Bro, is that record-setting claim only for the launch week? Sure seems like it. I thought you meant in terms of LTD, because I doubt Sega Rally would've accomplished that considering how Saturn performed in Europe including UK.

Also since the source is a magazine, likely possible another racing game after Sega Rally would've broken Rally's record. Like if just sticking to arcade racers, possibly something like Ridge Racer Type 4 or Mario Kart. If racers in general, I'm almost sure Gran Turismo would've smashed past Rally's launch & LTD numbers for UK & globally, since we have GT's sales numbers.

 

[Geometric-Crusher]

Sega and Saturn had no way of competing against three companies bigger than itself working exclusively on ps1 , it was a very powerful lobby
Namco, Konami, Square and Sony x Sega and some underground devs.

Nintendo only survived because it had a lot of success with western devs and powerful ip

 

[PaintTinJr]

It sounds like unless you were to do the same algorithm in the SH2s you would have mixed precision for vertices processed by the DSP and by the processors which does not sound particularly fun. Parallelism would allow you to process 2 vertices every two cycles. Extra latency, running at lower clockspeed, not the second SH2 but the SCU DSP seems one of the late additions to make it more competitive with PSX on paper at least (latency to move the data around seems like it would not make things fun / would easily cause a lot of stalls… need to understand more how memory would be moved around and what control you had on each processor’s local memory…). On top of the SCU DSP I think the late additions to make it more 3D optimised are probably a lot of small changes here and there in components that were already there (I would not rule out one or two more spins of both the VDPs for example).

From a certain point of view the Saturn appeals to me, like PS2 and PS3 (but especially like PS2). A puzzle to solve… all these units with their purpose and a way to combine them to get good results.

It would make me feel good to tame it for sure, but as a business if I did tame it I feel like I would be outcompeted by a cheaper team pushing the same (for users) or almost the same on PSX for a fraction of the cost (while Saturn is full of “nobody else does this in this way or will ever do it like this again” … although forward texturing makes me thing with more memory and faster storage it would have been fun to do a MegaTexture based engine that rendered a lot of small unique composable textures swapping sprite sets rendered per frame… then again yet another must do it like this only for Saturn thing as John put in the video… large quads poor performance and swimming, but 3D non flat mesh cannot use a larger quad to stretch a texture you need to break the texture in smaller unique textures to compose the surface with…). I think PS2 and PS3 when mastered and pushed hard had a greater return on investment though and the whole design as a whole, more on PS2 than PS3 where the nVIDIA GPU was added late and with bugs like the FlexIO implementation for example that betrayed the original design, was laid out together in a difficult yes but more holistically designed or better designed for the purpose task.
Dev that mastered and optimised their engine for PS2 for example could trade blows with consoles like Xbox that came out later and with much more powerful specs too (the GS ability to switch state/flush buffers per object or more even was something that was just much much slower on any other GPU even to this day compared to proper patterns that reduce state changes).

Interesting and good analysis of the hardware/s.

As for precision issues on the SCU DSP differing from the SH2, don't think that would happen unless it was floats, given the subtractive division with integers truncates the remainder on both, so the result is exact. However, I then realised that division by recursive subtraction, even if using binary long division 'binary chop' is quite involved in cycles even when using a divisor and dividend scale lookup table to retrieve iteration counts of the binary chop to speed up the recursion, but then I found this resource about hardware DIV implementation

How does division occur in our computers?

How does division occur inside digital computers? What is the algorithm for it? I have searched hard in google but haven't got satisfactory results. Please provide a very clear algorithm/flowchart...

electronics.stackexchange.com

and asked CoPilot about (integer) division on PS1 and on modern processors and it is 70 cycles on PS1 and anything from 13-90 cycles on modern AMD and Intel CPUs depending on the scale of the divisor and dividend end, so even if the SCU DSP averaged 150 cycles per division and at about 1/3rd of the PS1 MIPS throughput, it might have been oksy, if it wasn't for the fact that DIV on SH2 chips apparently worked in just 20cycles. So that's probably why the SCU DSP would have been better for transforming static data retrieved from the CD-ROM and projected afterwards with an SH2.

 

[SirTerry-T]

...But just like in the case of Dreamcast "justice for Sega crack suicide squad" is in dire need to regularly bring up the same matter to feed the bitter sensibilities.

Are those lot stationed in the same HQ as "The Sony Society For Videogame History Revisionism" and "The Nintendo Church of Purity and Platform Game Sanctity"?

Fanboyism works both ways, don't it.

 

[Team Andromeda]

Well this is assuming a couple things. For one it's assuming Squaresoft made FF VII for Saturn; the truth is Squaresoft already had access to Saturn architecture details and kind of wrote the system off early on due to aspects of the architecture they didn't like. Honestly I don't think they were ever seriously considering the Saturn as a development platform; it was always between Sony and Nintendo for them.

This is the trouble with these threads they just turn out to become a system-bashing thread telling us how wonderful the PS1 is.

Square dropped Nintendo that wasn't a option and SEGA was in the running, hell if the PC FX was doing better that would have been an option

It wasn't like FF7 was doing anything beyond the Saturn and if FF7 had to Saturn it would have been developed with its limitations in mind. In one of Retrogamer's features on FF Hironobu Sakaguchi told Retro that one of the main reasons they went on the PS1 was SONY commitment to looking to push the game big in the USA.

The video game industry can be full of what ifs. Had NCL not pissed off SONY or turned its back on CD Roms. Nintendo could have the PlayStation and FF7 .

Bro, is that record-setting claim only for the launch week? Sure seems like it. I thought you meant in terms of LTD, because I doubt Sega Rally would've accomplished that considering how Saturn performed in Europe including UK.

Like I said 'at the time' and the source wasn't just made up stuff from in a SEGA Mag, but it came from Gallop or however, was handing UK chart data at that time as it was reported in CVG ECT.
And another trouble on here in threads like this is that people only remember the final outcome and can't believe the Saturn was doing well in Japan for 2 years even beating the PS1 for large parts. Much like bet some won't believe how well the GameCueb did at its launch in Europe with one of the most successful Pal launches ever even better than the PS2 in parts of Europe and for a couple of years outselling the XBox

I bet there some on here who can't believe how crap NES and SNES sold in the UK where even the ZX Spectrum sold better.

 

[Lysandros]

Are those lot stationed in the same HQ as "The Sony Society For Videogame History Revisionism" and "The Nintendo Church of Purity and Platform Game Sanctity"?

Fanboyism works both ways, don't it.

I wouldn't know, i am just putting things on top of other things.

 

[PeteBull]

TLDR we see even bit more powerful saturn(difference was tiny, in comparision n64 vs psx/saturn was very visible back at its launch) doesnt mean shit w/o proper support of high quality games, wich lacked already in 1998 so 3-4 years(depend if we count japanese or US/EU launch) of the platform, imagine nowadays ps5/xsx launches in holidays 2020 but already holidays 2023 one of the platforms basically gets no new games and is discontinued like saturn was
Straight from the wiki:

Sega Saturn - Wikipedia

en.wikipedia.org

The Saturn was initially successful in Japan but not in the United States, where it was hindered by a surprise May 1995 launch, four months before its scheduled release date. After the debut of the Nintendo 64 in late 1996, the Saturn rapidly lost market share in the U.S., where it was discontinued in 1998.

 

[SkylineRKR]

Yeah, you're right and I don't want anyone to think I'm underplaying the GTE here. I was coming at that quote more as playing devil's advocate and supposing even if what that person was saying, there would've been other reasons why the theoretical peak for Saturn's geometry abilities never manifested due to other aspects of the architecture bottlenecking that theoretical performance.

In general, people really do underestimate the GTE on average though. For 3D there was nothing in Saturn that could really compete with it, even if you also factored in the DSP (which again, had to send results along the bus to the CPUs to have anything meaningful done with the data, so that would eat up cycles).



Well this is assuming a couple things. For one it's assuming Squaresoft made FF VII for Saturn; the truth is Squaresoft already had access to Saturn architecture details and kind of wrote the system off early on due to aspects of the architecture they didn't like. Honestly I don't think they were ever seriously considering the Saturn as a development platform; it was always between Sony and Nintendo for them.

You have to also consider that early on SEGA of Japan had an advantage of prior retail relations securing cache as a console manufacturer in the region, that Sony of Japan did not have, and had to build up with the PS1. People always say that Sony used their distribution advantage at retail to muscle out SEGA but if that were true, surely the PS1 would've had a massive lead in Japan even going as far back as '95. But it didn't, as you say, so which is true? I'm not asking you that specifically, just the people who try harping on Sony leveraging their retail partners as an advantage against SEGA and Nintendo; I think people exaggerate that advantage significantly.

Another thing is that during the 5th-gen era SEGA of Japan had a habit of reporting sold-in to retailers; Sony of Japan also reported sold-in but they also reported sold-through to customers. Therefore it's sometimes hard to get an exact read on what amount of Saturns had been sold to customers in Japan vs. sold to retailer outlets, whereas you generally always had an idea of both for PS1.

Anyways, yes it's probably worth saying that if FF VII came to Saturn and not PS1 that would've ensured Saturn's success over PS1 in Japan, but that assumes Squaresoft even wanted to ever work on the Saturn to begin with (again, their priorities that gen were between Nintendo and Sony; if Sony didn't work on getting closer with Squaresoft then they would've just likely stuck with Nintendo vs. go over to SEGA), and also assumes SEGA did something different with Dreamcast. They still had global reasons to push Dreamcast for late '98 in Japan which would've eaten away at the Saturn's market there post-'97, so it's still possible PS1 would've caught up and surpassed Saturn in Japan anyway thanks to releases in '98 and '99, then DQ VII in 2000.

IMO, at best FF VII would've helped extend Saturn as the sales leader in Japan for maybe a year, and maybe to a 1.5 million lead. But PS1 would've likely still clawed away at that between '98 and '99, then blown past it in 2000. PS1 being the market leader in Japan was inevitable, even without FF VII, but I could see Saturn having a larger lead over N64 lifetime in such a scenario for the Japanese market.

I will say, though, that Saturn having FF VII probably would've helped on some level globally as well, and maybe help the Saturn do somewhat better worldwide than it did. Maybe to go on selling 20-25 million instead of ~ 10 million. But that would've also required not basically killing retail presence for the system in 1998, and SEGA being a ghost in the West for '98 and most of '99 until Dreamcast launched.



Bro, is that record-setting claim only for the launch week? Sure seems like it. I thought you meant in terms of LTD, because I doubt Sega Rally would've accomplished that considering how Saturn performed in Europe including UK.

Also since the source is a magazine, likely possible another racing game after Sega Rally would've broken Rally's record. Like if just sticking to arcade racers, possibly something like Ridge Racer Type 4 or Mario Kart. If racers in general, I'm almost sure Gran Turismo would've smashed past Rally's launch & LTD numbers for UK & globally, since we have GT's sales numbers.

Regarding FFVII, I doubt it would do anything except for FF staying relatively niche in Europe. FFVII released late 1997 in the west. Saturn was already on life support by this time. Sega also didn't have the advertising muscles Sony had. Sony really pushed FFVII, unlike Sega with basically any Saturn game ever. This franchise picked up because it was on Playstation, not the other way around. With Nintendo the series never did remarkable on global level (they even failed to publish them in Europe). Sony found a way to get this game in the hands of mainstream gamers, pretty much like they found a way to get consoles to a broader audience. This is why the series is a global juggernaut since FFVII.

I think a comparison could be Tomb Raider. The first game debuted on Saturn, but gained stardom on Playstation. This was in 1996, basically a year past the western release of both systems.