Saturn did support alpha blending on quads (quads are ostensibly just sprites). The problem was the blending became uneven due to the distortion. Ie distortion caused the quads to have greater transparency on some parts and lesser transparency on others. This was largely due to developers skewing quads into triangles.
It works “correctly” for distorted quads, it’s just pixels overlay as part of the front to back rendering of the distortion process, thus creating combined blend methods greater than 50% but less than 100%. Ie literally what I said in my previous comment.
I think we are basically arguing the same thing, but from my point of view I’d say the end result is visually undesirable but technically correct.
The only "correct" that matters here is if it produces a result that's useful for 3D graphics.
The "some pixels get randomly blended multiple times" behaviour is simply not useful. And if it's not useful, then it might as well not exist. And it certainly can't substitute for the more capable blending behaviour that I'm claiming the Saturn should have.
In another comment [1], I go into more detail about both why visually correct (and capable) translucency modes were very important for early 3D consoles and speculate on the minimal modifications to the hardware design of VDP1 to fix translucency for distorted quads, while working within the framework of the existing design.
> The "some pixels get randomly blended multiple times" behaviour is simply not useful.
It’s not random. Not even remotely.
> And if it's not useful, then it might as well not exist.
It is useful in some scenarios. The problem here is you’re describing it as a 3D system but it really isn’t. The whole 3D aspect is more a hack than anything
Sure, it's technically deterministic. But it's also very chaotic, as it depends on the exact position of the vertices. It's not something a game could predict and take advantage of.
> It is useful in some scenarios
I'm really struggling to think of any scenario where the chaotic pattern of over-blending might produce a desirable result. Do you have any examples?
> The problem here is you’re describing it as a 3D system but it really isn’t. The whole 3D aspect is more a hack than anything
That's an argument I strongly disagree with.
The Sega Saturn was designed to be a 3D capable system from the start. It was always intended that those distorted sprites would be used as textured quads.
Sure, the intention was for the Saturn to be a powerful 2D focused system and it's 3D capabilities were considered to be secondary (maybe even a novelty). But it's not like the Saturn was designed as a 2D-only system that some clever engineer later hacked into doing 3D by abusing the distorted sprite capability the hardware just so happened to have, just to compete with the 3D focused Playstation.
We can tell this because the "distorted sprites" have the wrong API for 2D games. 2D games kind of think about sprite transformation as putting the sprite at an origin, then applying rotation, scaling and skew to it. And if the Saturn was designed as a 2D-only console, then it's API would line up with this 2D game understanding of sprites. The resulting API would probably look like the GBA affine sprites, where you pass in a transformation matrix that expresses the scale, rotation and skew.
(Actually, it's very questionable if a 2D-only console design would include the ability to skew sprites. Skewing isn't anywhere near as useful in games as scaling and rotating, and the additional hardware is a bit expensive. None of SEGA's "Super Scalar" arcade boards did skewing, and the GBA's affine sprites only support rotation and scaling)
But that's not how "distorted sprites" are implemented on VDP1. You actually control the distortion by specifying the coordinates of the four sprite corners. This is a very unnatural format for a 2D game, they have to do a bunch of extra math on the CPU to calculate how their desired transformation will affect the four corners. Even worse, this API means the VDP has to contain expensive division hardware to convert those "sprite corners" back into a form that's mathematically closer to the origin + transformation which 2D games like.
But do you know who likes the idea of stretching "distorted sprites" between "sprite corners"? That's right, 3D graphics. Just do a bit of find/replace: "distorted sprites" becomes "textured quads", "sprite corners" become "vertices", and you have an API that's actually quite ideal for doing quad-based 3D graphics. 3D games want to be able to transform their lists of vertices into new screen-space coords each frame, and let the textured quads fill in the gaps between verts.
If the Saturn had a more 2D orientated API, the CPU (or DSP) would need to do a bunch of expensive math (divisions are not cheap) on those screen-space vertex coords, just to get the origin + transformation of each quad.
To summarise: The fact that "distorted sprites" take vertex coords is very strong proof that they were always intended to be used as textured quads for 3D graphics, and that the Sega Saturn was always intended to be 3D capable.
And since the Saturn was always intended to be a 3D capable system, I think it's only fair to point out it's deficiencies in that area, and explore how an alternative history Saturn might have looked if the engineers had put more focus on it's 3D capabilities.
> Sure, it's technically deterministic. But it's also very chaotic, as it depends on the exact position of the vertices
Exactly. It’s not random. So let’s not exaggerate things please
> I'm really struggling to think of any scenario where the chaotic pattern of over-blending might produce a desirable result. Do you have any examples?
You’re deliberately misrepresenting my comment here.
You claimed that alpha blending is useless on the Saturn and I said it does have its edge cases but you need to stop thinking about the console as a 3D system. Sure, it was intended to compete with 3D systems but architecturally it’s really just a super powered 2D console.
This is why for pseudo-3D purposes, alpha blending doesn’t work well. But for 2D purposes it’s great.
Also I’d argue that the problem with 3D isn’t the alpha blending specifically but rather how order in which the Saturn renders and the use of quads.
> …APIs…
you keep talking about Saturns APIs but it wasn’t released with an SDK on launch (the PlayStation was, which is another reason behind its success with 3rd party studios). Saturns SDK came later, originally developers were expected to write assembly.
> And since the Saturn was always intended to be a 3D capable system
I doubt we’ll ever full know the truth as there are conflicting reports from people who were in Sega itself during genesis of the Saturn (pun intended).
We also know that Sega turned down Silicon Graphics (who later worked with Nintendo) and the reasons Sega turned them down is a topic of great speculation too.
There is so much folklore around the Saturn that it is hard to say anything for certain beyond the hardware architecture. And architecturally, speaking its 3D capabilities are kludge because Sega tried to hedge their bets with 2D as well.
