Did PDS use many transparency effects?

I…just dont agree I think NiGHTS looked nicer

The boss fights were good, I have to admit. I am too perfectionistic for my own good I suppose.

Aesthetically I agree that NiGHTS is a beautiful game, still mesmerizing to me, and it’s visually very busy and exciting. But it’s also ‘2.5D’ strictly speaking, which doesn’t technically lighten the rendering workload in any 1:1 sense, but because the camera is fixed and the composition of the image is relatively constant and predictable many more sins can be hidden. Even then the draw-in is conspicuous, but also constant so you stop noticing. A lot of the image relies on flat scaled sprites as well, which is not to criticize, it still looks amazing in motion, but it is less taxing for the VDP1. Indeed NiGHTS is perfectly suited for the Saturn’s strengths, and subjectively I even agree with you edge, but it’s definitely not technically superior to Sonic R or even a match as a raw benchmark.

And Geoffrey… I’m mostly thinking out loud here but I think you know that already, and I hope it doesn’t come across too much as a lecture, I know I’m preaching to the choir as well. I’m sure of about half of it and the other half is extrapolation from what I’m sure of. For example, one thing that video didn’t clarify is the fact that the reason you see either sprites blending with other sprites (“foreground”) OR sprites blending with the VDP2 (“background”) is because the VDP2 generates the final display, and the display order only goes one direction. So whether it is background planes blending with other background planes, or sprite/foreground channels blending with the background, if it includes the background/VDP2 display data then the blending must be done by the VDP2. Which is the no-cost function; since I know how it must work, and every example bears it out I’m sure of that. So now I’ve almost fully convinced myself that it is a single channel as well, it is probably the one VDP2 blending function that can either operate on an entire background plane - which is just like the only mode for transparencies the SNES had - or that blending function can instead be slaved to the sprite alpha channel, in which case there is still no performance cost, other than the alpha channel data itself. But you will always see the translucency effect “penetrate to the background” as Low Score Boy puts it. lol

Only when sprites are blended with other sprites is it done in VDP1, so that’s a different function, and watching the Sonic R video I saw again how the shield effect only appears blended with the other sprite or VDP1 elements. (I’ve never owned the game and it’s been a LONG time since I played it on loan), so that’s that.

As for the ultimate limitations, if it’s even theoretically possible to combine both functions for a flawless/universal tranlucency effect, would probably depend on whether the same alpha channel format is used for both functions or not - just think of it as the same control switch. If it is then it would need to operate in either one mode or the other, which would be my guess since I’ve never seen it. But there is one more wrinkle, because iirc the Saturn special stage in Symphony of the Night shows both the translucent sprites and another darkening effect simultaneously - which is also what made the use of the dithered light shafts in other areas so irritating to me - so there may be another simple luminance modifier function, which is still kind of a translucency effect but not color blending per se. So I’m almost sure about that now, which is a bit disappointing, but it makes sense of almost everything I’ve noticed before.

Which mainly leaves the question of how and why the VDP1 blending is such a problem that most games didn’t even try to use it. I’ve seen mentions of a requirement to write the other sprites first or something like that, which is almost both obvious and counter-intuitive at the same time to me. It is even possible that the sprite flickering I’ve mentioned is a red herring, which would offer an alternative explanation that turns the “sprites” almost into a lie and the whole puzzle is more mundane in a way, but I don’t think that’s likely. Regardless I’m probably overthinking it, and the reason Lobotomy and a few other games appear to make it look easy is just because they’ve been budgeted and optimized to factor in the performance overhead, whatever it is. I still think it’s telling that PSX Exhumed didn’t pull off the flare lighting in the same form, in theory it should have been able to regardless, so it must have simply been a performance concession.

Thanks for the excuse to obsess over this all over again, I’m sure it would look sad to most people, I can still get so excited about the specs of a 20 year old games console! I think I will have to search for some answers at least about the slavedriver engine now, but in a way it’s also too fun to try to figure it out. :smile:

I’m sure that someone somewhere will find your insights into this helpful. It’s ceased being relevant to me because I can’t change the outcome.

Personally, I think it would take a perfectionist to get the most out of the Saturn. Many developers were given a limited amount of time with little or no understanding of the hardware. Furthermore, Sega never bribed most of them like Sony did in a cut throat business world where time is money, which needless to say was a fatal mistake.

But we’ve been over this.

We should go back in time and become Saturn developers. I’d basically just look at the math. See what’s possible and what isn’t, and go from there.

The people behind the hardware might have seen everything that the Saturn was capable of rendering in theory (even translucent 3D effects), but not in practice. Some people can be really stubborn about this, as I am sure you are aware.

Apologies for the necro, but this is so connected to what was already discussed here, it seemed more rude or at least inefficient to make a new thread about it. I finally came across some solid explanations for the main issues about the Saturn architecture and translucency in particular, and confirmation on a hunch I had even alluded to here a year and a half ago… Biggest help was from this thread:

http://www.sega-16.com/forum/archive/index.php/t-19962.html

To summarize: I am actually really freshly angry about all the “Saturn doesn’t do ‘true’ 3D, it uses ‘warped sprites’” shit. It actually is an even more misleading case of semantics than I had already assumed, since the VDP1 itself operates on a double buffered frame system just like any other texture rasterizer or conventional GPU. Basically there’s no meaningful distinction between how the PSX or N64 render graphics and how the Saturn’s VDP1 does, the SS simply has an extra dimension to its video display system. Hell the Xbox One has extra separated video planes, does that make it not count too? You could as well say nVidia does “true 3D” while AMD doesn’t, it’s just a matter of individual execution. Now if what all those fucking experts or “journalists” had said 20 years ago was that Saturn doesn’t use proper texture mapping, that at least would have been passably accurate and illuminating.

Okay whatever, here are the big points of clarification: I still have a reservation about flickering noted in games like Guardian Heroes and Last Bronx, there could yet be something idiosyncratic about the VDP1 DMA fetch for its “sprite” data, since it is still built off of a lineage of SEGA arcade architectures; or it is indeed just a red herring and some artifact of other performance limits. The important factor is that in the final video display raster only a single “sprite” channel exists, as far as the VDP2 is concerned, but how this factors into the blending issues is a little more interesting than I previously guessed.

  • VDP1 can operate in a “paletted” mode, which is effectively like (nearly) all previous arcade/console sprite based systems. The sprites are comprised of indexed-color pixels, so the data value points to an arbitrary color defined by a (256) color palette. This can be much more bandwidth efficient, and most 2D games use it to throw down with lots of action and effects. The main issue in 3D is that the VDP1 isn’t working with direct color data, so it cannot apply its shading or blending logic directly.

  • Alternatively VDP1 can operate on (15 bit) “true color” or RGB data, which is identical to what nearly all PSX games run. Effectively every pixel value is a direct definition of the color - equal to the SNES’s total absolute palette. This is required for the shading logic, so almost all later Saturn 3D games render in this mode. It also costs 2-4 times the data, and I don’t think the Saturn (or PSX for that matter) have any innate color compression options, which are now de riguer for GPUs. But it makes me wonder if there’s any super clever way you could use these two modes to cheat it…

  • The “transparency bug” is… both better and worse than I thought, if I actually have an accurate understanding now. So again the sprite color blending is only possible in 15-bit, absolute RGB mode; this already incurs a greater performance cost, but you need it for decent shading anyway, but apparently VDP1 is shit at blending just at a baseline since takes “six times” longer to render a quad. The “bug” is a combination of two things, first is an “anti-aliasing” function which I have never even heard about, but even though it’s not entirely obvious this could explain why even at time Saturn IQ looked a little softer / more blended than PSX. The sad thing is that may actually have translated to PSX appearing “sharper” = “better” for most people, and further explain why I couldn’t relate to said people’s taste. (ahem) Anyway this function would seem to resample pixel data to crudely average color values near the edges of textures, but it somehow compounds with the color blend function in an even more crudely unfortunate manner. The other part is the bare minimum blend function itself, which merely averages the base luminance values together, rather than interpolate the real colors. This has a cumulative effect with the AA function resulting in a poor to worthless translucency appearance on highly warped textures… and for a huge performance penalty.

So yes it’s understandable how few games considered that a worthwhile tradeoff. The nice thing is at least it doesn’t appear to be a hardware “bug” in the sense of a defect in the intended spec, but rather an oversight which may or may not have been fixable in late stage manufacturing. Hard to say I guess, until I see some further quote about it. It’s also interesting just to find out that it’s an artifact of something the Saturn hardware is actually more advanced / ambitious about.

Between the performance overhead and the chaotic visual result, I think that explains why you see it used sparingly in some of those cutscenes in Azel. Perhaps they tweaked the angles used until they got a decent appearance out of it, since the camera is fixed for the cutscene. Also then the shield effects seen in Sonic R are I think flat effects, which avoids most of the negative artifacting of using it on warped textures.

That just leaves Powerslave, but I now think I could have misinterpreted what I was seeing at the time, because it just looks so unique. If there is any actual blending in use for (some of?) the flare lighting, perhaps precisely matched angles avoids the cumulative opacity problem…

Well just in case anyone else still had curiosity about it. Not that I necessarily expect so. :slight_smile: