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.

 

[Drell]

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

I meant that in a positive way because technical discussions are always interresting. Also fanboyism goes both way. The 5th gen of consoles, as first 3D dedicated hardwares were all extremly flawed in some specific domains.

 

[PaintTinJr]

Now that I've had a look through some of the Sega Graphic Library (SGL) documentation, this one in particular which reads like Hitachi's version of the original Opengl redbook with SL prefix instead of GL prefixes everywhere.

https://segaretro.org/images/f/f3/ST-237-R1-051795.pdf

(and the Addendum assembler guide pdf for the SCU DSP)

from

Saturn official documentation - Sega Retro

segaretro.org

and those documents along with info in John's DF Retro face video, my feeling is that the Saturn could have had much, much better results than we say.
Fundamentally I don't think it helps that the Sega documentation does nothing to suggest best practices, and I suspect every game that launched on the system was wasting half it polygon and texture throughput by using Dual_Plane - better known as two sided polygons in Opengl - because the documentation makes no reference to the performance hit of switching between between Single and Dual - and this must have been common and used as the model Esppiral extracted from Shenmue in the Dreamcast thread was modelled double sided, meaning even their description of the model was wasteful.

In addition to this, the documentation provides a hidden surface removal feature of the Hitachi SGL (presumably the VDP1 hardware accelerating) to do the calculations to calculate the point on a quad to be used for the sorting test of the painter's algorithm despite the GPU being way too weak for this additional burden and by comparison PlayStation was doing this on its single MIPS3000 CPU - even though it didn't have three processors (2x SH2 + SCU DSP) that could have done this work instead of the GTE - as shown in the pdf Panajev2001a linked some pages back.

That seems to be the entire story of the documentation, that for simplicity the SGL sets up to use all its transformation maths on the VDP1 in Saturn, rather than have the up to 6x OPS per cycle SCU DSP with its own small version of an iCache do some of the work, or the two SH2 CPUs that were arguably together much stronger than the MIP3000 in the PS1 do the bulk, and just use the pre-transformed quad vertices with SDL on VDP1.

But I suspect the main problem with performance on the Saturn IMHO is best depicted in this diagram and code snippet here .

What I suspect has killed performance on most Saturn games with texturing, is that the main CPU SH2 and B-Bus that seems to be the critical path for VDP1, VDP2 and the second SH into RAM or VRAM is that the 1 QUAD per texture rebinding calls will have likely thrashed the system, or been left with very little processing or bandwidth headroom if rapidly switching textures meaning more function calls and DMAcopy transfers on the highly contended B-bus, when flat coloured quads could have been rendered very cheaply in call counts by comparison via large drawlists using data indexes.

In addition to this, switching between the VDP1 and VDP2 probably wasn't the big saving it looked to be for skies, floors and text, because AFAIK anything offloaded onto cheaper VDP2 techniques caused VRAM and bus contention effectively stealing processing time and bandwidth away from the VDP1. So I would have thought that ignoring the VDP1 entirely and even falling back to software techniques for filling/texturing VDP1 rendered wireframe quads on the the SH2 CPUs and SCU DSP might have yielded far more, allowing the VDP1 to maximise VRAM use, the SH2 CPUs to maximise RAM and B-BUS usage, and the SCU DSP to maximise A-BUS usage and its internal data cache for processing and maximise scheduling of transfers between RAM - VRAM and its internal cache.

After getting a better idea of how conflicted all the processing on Saturn was, I think the games that came out with full 3D and lots of geometry like Tomb Raider did extremely well to run as well as they did without further cut backs.

 

[RetroGamingUK]

After getting a better idea of how conflicted all the processing on Saturn was, I think the games that came out with full 3D and lots of geometry like Tomb Raider did extremely well to run as well as they did without further cut backs.

People saying Tomb Raider ran badly on Saturn was due to releasing a month early are talking out of their cling-on infested backsides.

Do they really think an extra month in the oven would have fixed the frame rate issues?

 

[cireza]

Do they really think an extra month in the oven would have fixed the frame rate issues?

Of course lol.

Even today you get day-one patches that fix framerate issues, obviously a month would have helped.

 

[s_mirage]

Of course lol.

Even today you get day-one patches that fix framerate issues, obviously a month would have helped.

And yet the US version ran no better, and neither did the Japanese version which had file dates of December '96. It's not impossible that they didn't touch it after the PAL release but there were some minor changes that suggest at least a little work continued.

 

[RetroGamingUK]

And yet the US version ran no better, and neither did the Japanese version which had file dates of December '96. It's not impossible that they didn't touch it after the PAL release but there were some minor changes that suggest at least a little work continued.

Yeah I remember people claiming for decades that Japanese Saturn Tomb Raiders fixed the frame rate issues

John Linneman proved this was bollocks

 

[PaintTinJr]

People saying Tomb Raider ran badly on Saturn was due to releasing a month early are talking out of their cling-on infested backsides.

Do they really think an extra month in the oven would have fixed the frame rate issues?

It depends. I personally think the Hitachi VDP1 chip would have been a consistent design with all the other state machine paradigm PC GPUs of the time for running OpenGL conformant code, except for the quirks - like no hardware UV mapping, with just one texture per primitive and no hardware support for conventional polygon 3 vertices - so going by the documented examples it was being used as intended and giving the expected results because of those quirks IMO, so major tradeoffs to eliminate drawing efficiently at a single quad per call and needing a new texture binding or DMAcopy per unique texture use would have been needed,

Unlike the GTE in the PS1 I have my doubts there was any assembly language mechanism for the VDP1 to write directly to the texture cache and invalidate the GL state machine and still render to circumvent the performance hit of 24,000 draw/binding calls and synchronisations of the GL per second without either replacing half the textured quads with flat coloured quads rendered as batch draw list efficiently, but effectively an inferior visual, or without rendering everything as carefully chosen colours for Gouraud shaded (as quads) to a image that allowed a CPU core or the SCU DSP (or possibly he VDP2) to read each pixel and from the colour shade derive a standard UV position and from the unique colour mix use a translation table for a texture cache to texture location, and from the next UV determine orientation to allow the processor to texture the final image using assembly efficiently. But I don't see how they'd have come up with that in a single month, so it would have been more colour quads IMO and less texturing to get a frame-rate boost to 30 in a month - they would need 30, as it was the next natural divider into 60Hz

 

[nkarafo]

People saying Tomb Raider ran badly on Saturn was due to releasing a month early are talking out of their cling-on infested backsides.

Do they really think an extra month in the oven would have fixed the frame rate issues?

For every game that runs badly on the Saturn there will be at least one person blaming something other than the system itself.

The same thing applies for the Dreamcast. If a port on the PS2 is better the reason is because something unrelated to Dreamcast's hardware is holding it back. Maybe a delay, maybe the developer didn't care, whatever. It's never because the other system is simply better.

But if something runs badly on a non-Sega console? It's "weakness". Or "bottleneck". Or "badly designed hardware".

This is a double standard i notice with a lot of Sega fans, ever since i was lurking in the Sega16 forums. I understand being a Sega fan in the mid/late 90's was difficult (there was a lot of unfair pushing against the Saturn by gaming magazines and game stores) but it's over guys.

 

[cireza]

And yet the US version ran no better, and neither did the Japanese version which had file dates of December '96. It's not impossible that they didn't touch it after the PAL release but there were some minor changes that suggest at least a little work continued.

They obviously didn't work on performance, only putting a few more saves for the Japanese release. Minor functional enhancements, nothing touched in the engine.

Yeah I remember people claiming for decades that Japanese Saturn Tomb Raiders fixed the frame rate issues

I don't remember anything like this.

 

[Geometric-Crusher]

People saying Tomb Raider ran badly on Saturn was due to releasing a month early are talking out of their cling-on infested backsides.

Do they really think an extra month in the oven would have fixed the frame rate issues?

The only way for the Sega Saturn to get +15fps was Sega to make an SLI of vdp1.

In modern times, to match two consoles, the number 1 choice is resolution, if a console is 30% superior, simply reduce the resolution by 20% to 40% as it is not always linear. But how to match 320x240 consoles? Lowering the resolution doesn't make sense, so the devs chose 4 options.

locks at 30fps on PS1 and 20fps on Saturn
zoom in on the game's graphics like Argonaut did with Croc.
Use sprites on enemies on Saturn and polygonal enemies on Playstation
Leave the frame rate open and oscillating on the Saturn.

All this, apart from the ridiculous shadows and the off lighting effects, damn why the hell did Sega release such a weak console?

 

[PaintTinJr]

They obviously didn't work on performance, only putting a few more saves for the Japanese release. Minor functional enhancements, nothing touched in the engine.


I don't remember anything like this.

But the fundamental bottleneck - and I've only just noticed it applies to Gouraud shading in addition to texturing and this is where sorting is forced too - is that the system forces you to send one primitive per call to the GL server with these features enabled - instead of a batch display list when just using colour vertices in an indexed mesh - which results in orders slower for the GPU and GPU.

How could they find another 10 frames per second without lowering the target output or spending 6months more working on the project to use a complex workaround?

 

[cireza]

How could they find another 10 frames per second without lowering the target output or spending 6months more working on the project to use a complex workaround?

Who knows ? If the team had been prioritized one month on improving performance, they would have most certainly managed something. Maybe not a full 10fps gain, maybe 5 ? Core Design were quite talented, don't underestimate them. They made some of the most impressive Mega-CD games out there. And one of the very first full 3D with free camera exploration game, that's Tomb Raider. They were also developing 2 on Saturn before Sony bought the exclusivity.

An obvious gain can be obtained by reducing draw distance to the one used on PS1, for example. But this one is an easy win.

 

[PaintTinJr]

Who knows ? If the team had been prioritized one month on improving performance, they would have most certainly managed something. Maybe not a full 10fps gain, maybe 5 ? Core Design were quite talented, don't underestimate them. They made some of the most impressive Mega-CD games out there. And one of the very first full 3D with free camera exploration game, that's Tomb Raider. They were also developing 2 on Saturn before Sony bought the exclusivity.

An obvious gain can be obtained by reducing draw distance to the one used on PS1, for example. But this one is an easy win.

I don't think you are understanding how forced function calls bottlenecks everything, and for all we know they may have seen a way to gain 5fps and realised it would still result in a US version at 20fps because of the 60/25 is a screen tear, whereas 60/20 is a 2/3rd image hold and update.

So there was no reason to push for 25fps, without hitting 30fps, and draw distance was actually helping the performance by minifying Lara's animation and the background geometry reducing the cost of fillrate when texturing at 1 quad per call, which given the 600 quads - IMO it looks like in the wireframe - is a lot more than the vast majority of the Saturn games John showed wireframes of in his recent faceoff.

I agree that the UK development scene was unbelievable after the Spectrum lighting up the home computer market of the 80's and they were highly skilled, but what needed to improve Saturn development was 25years of game techniques and hindsight. At the time the workarounds just weren't options IMO in 1month, maybe 6months for amazing unexpected workaround for a company that had bet the farm on a killer Saturn game, but not a company that was about to get a huge return on a PlayStation 1 release IMHO.

 

[Parazels]

Can't wait, when the modern enthusiasts improve frame rate on Tomb Raider up to 30 or 60 fps!

 

[cireza]

At the time the workarounds just weren't options IMO in 1month, maybe 6months for amazing unexpected workaround for a company that had bet the farm on a killer Saturn game, but not a company that was about to get a huge return on a PlayStation 1 release IMHO.

Thing is we can't tell. So what ifs won't take us very far. Given the rhythm at which they released the games, you can be sure that focus switched immediately on TR2 after release. The game was planned on Saturn, started development even, and has larger environments. I don't think they would have shipped a game performing worse than the first one. Improvements would have been seen in this sequel, if it wasn't for Sony stepping in.

 

[PaintTinJr]

Thing is we can't tell. So what ifs won't take us very far. Given the rhythm at which they released the games, you can be sure that focus switched immediately on TR2 after release. The game was planned on Saturn, started development even, and has larger environments. I don't think they would have shipped a game performing worse than the first one. Improvements would have been seen in this sequel, if it wasn't for Sony stepping in.

The Sega Saturn constraints are in the documentation and fully backed by what John showed in the video. The sequel would have just used flat shaded polygons with sparse texture decals to fake texturing and would have hit 30fps with that hidden workaround.