Did PDS use many transparency effects?


i noticed the radar and wings of my dragon had these checker patterns http://www.plasticpals.com/wp-content/uploads/2009/07/pdsaga-1.jpg when i used my s video cable is this an example of faux transparency? how much transparency does PDS use?


The shield spells are a mesh effect as well, but all the riverscapes are completely transparent and stunning to behold.


so the wings and shadow are mesh?


i thought that video said the river was semi-transparent


It’s a 2D illusion. I have actually played the game, so I know that it is. But the riverscapes are stunning. The Saturn had no in-built hardware to perform 3D transparencies. It was a flaw in the Saturn’s design. Some developers simply made the most of this, like Team Andromeda.


Also, devs used the fuziness of the Composite signal to blur effects (like the shadows in VF2). Emulators haven’t really emulated this well.


i wouldnt call it a “flaw” i love the meshing i think it makes it look more retro like the voxels in 3d dot game heroes


ive read that PDS was a very difficult game to make but i wonder why…ff7 was a bigger game and i never heard square enix complain


I’m sure the reason the guy in the video used the term “semi transparency” is to be more precise, he intends the strict connation of a ‘translucency’. “Transparencies” is itself a misnomer that unfortunately got coined and normalized by some dumbass gaming critics when it was a big deal on the SNES. I gave up making an issue about it, but it has always irritated me. I’m sure that the Japanese or other Asian gaming communities never adopted the same bad habit, of conflating something invisible with something not fully opaque, as it were.

Sorry for the rant, but since you are asking about it. lol

It is also a little misleading (no offense Geoffrey) to put it in 2D vs 3D terms, all rendering is ultimately fakery, exactly what process a pixel went through to arrive at that value and location doesn’t determine how much D it deserves. The VDP2 rotation and Z rasterization is much higher precision than the texture rasterization of the PSX for example, and even the VDP1 bitmap rasterizaion as well as geometry precision is superior in some respects. The ‘Saturn doesn’t do true 3D’ thing was another unfortunate fallacy of too simplistic knowledge, there is nothing inherently less three dimensional about any of these games for the fact that they are rendered from sprites and playfield elements instead of a texture rasterizer operating on a single contiguous frame buffer.

I think the distinction Geoffrey is trying to make, is that with the VDP2 effects it is like doing the most you can with a single big texture, but that one texture can still be as 3D as anything else. And that also connects to one of the things the video fell short on explaining, some of the VDP2 playfields (display channels) can be blended with any or all of the final display channels, like you see with the smoke or haze effects at Mel-Kava and the burning forest in Azel, and it should be essentially a free effect, the blending computation is a hard coded function of the final video conversion. I think the rare cases where you see sprite channels blended with other sprite channels, the computation has to be done by VDP1 and comes at a cost then. But again Lobotomy’s games don’t show much compromise in raw data output, but they are simpler in geometry so I’d like to know if that factors in.

But yes when you see that kind of checkered or “screen door” effect with S-Video it is the dreaded “fake transparencies” of the Saturn. Mostly noticeable on the HUD elements and the wings of some of the dragon models or other enemies in Saga. I don’t think there is any VDP1 (or sprite channel) blending employed anywhere in the game, so the only “true transparencies” are the big full scene and set piece effects like with water, smoke, and the fight in Sestren.


Translucent 3D effects are far more aesthetically pleasing than dithered mesh effects. It’s as if Sega looked at the Saturn’s capabilities in theory but not in practice.

The explosions in Amok shouldn’t have been dithered effects. They could have been like the explosions in the sub-par conversion of Alien Trilogy and we’d have a more memorable game.

I always see things the way they should be as opposed to the way things are. I suppose it’s a blind spot in my thinking. Terms are sometimes redefined and popularized, so you will have to forgive me if I am not specific enough.

I’m still impressed with the art and 2D sprites in Exhumed even to this day. Duke Nukem and Quake were a bit too ambitious for the Saturn. I wish Lobotomy had made another game specifically with the Saturn in mind instead of downscaling two PC first person shooters.

Better to build on your strengths than try to strengthen your weaknesses.


its still pretty funny all these years later seeing where they put all the meshing once you bump up the resolution


Indeed. The Composite signal blurred mesh effects in some games like with shadows. That’s why emulators need an original native resolution Composite signal option.

But maybe I am being too perfectionistic.


I don’t mean to be insufferable Geoffrey (not that thet has ever mattered I’m sure) I’m only trying to clarify. :smile:

I could have put it better about the 2D thing anyway, what I was concerned with explaining is, the fact that an effect is done with a VDP2 (background) channel doesn’t in and of itself make it 2D as opposed to 3D. But yes some of the raster effects they also use could be termed 2D, or more technically what is now commonly referred to as a screen-space effect. So you aren’t wrong per se. However some sprite effects also qualify, which is why the 2D/3D thing doesnt really describe it, for the example used. And in the end it is the game engine that is 3D or not, rather than the image, these distinctions are archaic at this point.

I’m still fuzzy about how the VDP1 sprites operate, I may still be missing a piece of understanding that would clarify all the blending issues, I have previously assumed there must be some rudimentary bandwidth conservation (algorithmic culling of sprites from the list if they aren’t visible) but rethinking it I guess that isn’t a given. So I’ll try to explain this as simply as I can: at it’s most basic, a (hardware) sprite is just a pointer to a discrete range of video data, which is fully independent of the main video buffer. So the logical location of the sprite data in RAM is arbitrary, it has no fixed correlation with the pixels of the final video display. So in practice this means that a small section of the image you see, where many sprites intersect, could be fetching from dozens of data ranges scattered across the video RAM. It doesn’t sound very efficient, but it’s not so different in the end from the work a GPU does in compositing texture data to build up an image. The main issue is that all of this compositing is done as part of the video conversion itself, all of those sprites are in effect individual video buffers.

The Saturn has a lot of them, but I definitely recall seeing flickering in two games: Guardian Heroes if you fill up the screen with fireballs and general chaos, and Last Bronx during the win poses when the camera brings the ring fence in a lateral view behind the character closeup. This puzzled me at first but then it seemed to explain a lot. Remember all the data for those sprites has to be fetched for the video conversion, and there is a fixed amount of data bandwidth available at any stage in the process, so even if you can logically point a hundred sprites to the same screen space, if they overload the bandwidth that’s when flickering occurs. Which is the significant disadvantage of the architecture.

When I put it together it appears to answer the problem of something that had always annoyed me about Tomb Raider. It made no sense to me why there’s two different detail levels on the environment textures, when the PSX version employs the same higher grade textures on everything. I can’t imagine it having any significant impact on performance, and the need to store two sets of textures obviously uses up more RAM and you can see even the close up textures are lower resolution than the PSX version on some elements. But the visual composition of that game is very advanced for the time, relatively long draw distances and a free camera, with a lot of organic, detail rich environments. I think the issue is not that you would have seen much slower performance if it had uniformly high textures, what you would have seen is flickering on some of the scenery. Those lower resolution bitmaps should basically halve the bandwidth load, even though they occupy the same screen real estate.

But back to the transparencies. Thinking it over again, it seems clear enough that the VDP2 only has a single blending channel, and it’s possible that is the same function that the basic sprite alpha channel uses. Because I’m not actually sure I’ve ever seen the combination of sprites blended with a background plane AND a full scene translucency effect at the same time. Although the Saturn special stage in SotN and the shield effect in Sonic R, which that video notes, might refute this. Not entirely sure now.

Also I never played that Alien game, but there were a number of early games that seemed to put more effort on stuff like that. But I think after a while the performance expectations of the later gen of games made any extra overhead too much for most developers and projects. But I always really liked the AMOK solution, their interlaced effect works much nicer for dynamic effects like explosions than the standard dither.


I’m surprised that you looked into the specs so deeply.

The mesh effects (interlaced or not) are ugly compared to truly translucent ones IMO. Perhaps a purist could handle it, but a perfectionist couldn’t. This was a view shared by many gamers.

I have no idea how the last stage of Sonic R was created. All I know is the translucent track isn’t a mesh effect (same with the Wendigo spell in Shining Force 3).

Croc had an impressive graphics engine for the Saturn as well. Personally, I think Tomb Raider was great on the Saturn. It had a greater draw distance and less texture warping than the PS version which was sharper. The Saturn could have handled the sequel IMO. Devs could have taken advantage of better dynamic lighting effects.

God, even thinking about it now is making me angry.

Anyway, there’s still quite a few Saturn games I’d still like to play.

My main problem with the Saturn is, even as it stood, the last generation of Saturn games should have been the first. Imagine going from there. Imagine Exhumed, Sonic R, Grandia and Sega Rally as launch titles. Those graphics should have been the norm for the Saturn. Sony still would have completely destroyed it (Sony is run by demonic intra-species predators after all), but it would have made a world of difference.


sonic r looks terrible panzer dragoon was a great launch title


Ok, imagine Burning Rangers as a launch title.


i think they should have kept sonic in 2d like megaman


Is that what you mean by Sonic R “looks terrible” edge? Technically the game is easily in the top ten most impressive 3D engines for Saturn, but it dissappointed most Sonic fans obviously. Sonic Xtreme could have been great I think, it preserved the spirit of the 2D gameplay while playing to the Saturn’s graphical strengths in an impressive way.

Geoffrey, I’ve never disagreed with you about the dithered transparency issue in those terms, of course there’s nothing preferable about it. It’s only that I understood why it is the way it is, and made my peace with the fact early on. Tomb Raider is the perfect example, and I’ve used it enough times before, the Saturn game is the only version I would ever want to play, given a choice. The coherent image, both in the (absence of) texture warping and the geometry precision (no seams) puts the PSX to shame for me; nothing spoils suspension of disbelief like erratic image quality. Beyond that is the more nuanced and atmospheric lighting, particularly with the water effects - also the water distortion effect lacking in EVERY other version - and as you mentioned not just a better draw distance but also a more consistent frame rate compared to PSX - which drops into single digits very often in the big open room areas. Some of the colors are nicer on PSX though, and the minor translucency effects are of course better, and the textures are definitely higher res overall, but for me there is still no contest. TR also makes an interesting sort of negative example of the most powerful distinction of the Saturn, because it is effectively powered only by the VDP1, but still holds its own with the PSX.

A couple great examples of that potential discrepancy are Mass Destruction and Robo-Pit, which run at twice the frame rate on the Saturn vs the PSX versions (only single player for Robo-Pit) all because of their reliance on large detailed bitmaps for the terrain, which is exactly what the VDP2 excels in. Essentially that one “Mode 7” processor is effortlessly doing the same work that, in the other case is consuming half of the PSX’s fill rate for it to approximate. I had some grasp of these tradeoffs from the start of my Saturn relationship - since VF2 also shows that power to fine advantage - and so I accepted them.

Just a little more about Powerslave/Exhumed and Lobotomy. That’s also a case of a game that, even though it doesn’t seem to capitalize on the VDP2 power it still more than holds its own with the PSX example. Extrapolating from the hints I have, and the fact that I don’t see how that engine could be using the same trick as Burning Rangers for the blending seen in the flare lighting effect; I think there is some priority protocol with the VDP1/sprite alpha blending, which may still be connected to the VDP2 circuitry, like it interrupts the sprite data fetch to pass through the blend function maybe. Between Ezra Dreisbach being a code monkey par excellance, and the more easily sorted composition of the image, it may be a special case where the “transparency bug” can be properly accounted for and the blending itself still incurs no performance overhead. Hard to explain especially when I don’t have a firm grasp of the details, but I can roughly make sense of it in theory.

So to wrap up this train of thought, I haven’t ever looked into it all that deeply, but my understanding of the basics from well before the Saturn days helped me to understand the references I saw as they accumulated into a pretty solid picture. I have had the thought of scrounging through SEGA-16 for more details on the graphics spec but too lazy / not in the mood so far. Heh

So one final response, in Sonic R the soft draw-in (fogging) effect is indeed true blending and it is accomplished by the exact same function as the translucency effect of the special track - which is why it can’t do both - and also every other (true) sprite translucency effect you see in games like Guardian Heroes and Silhouette Mirage. EDIT: also I remembered a couple examples of true sprite blending seen in PDS, the underwater connecting tubes in Uru, which IIRC appear to operate the same as this current example; but also in some cutscenes like the dogfight with Atolm after Azel ambushes Edge at Uru, you see the nice energy barrier effect. - And it is basically a no-cost effect, because all the video data is collected for final output regardless, if the alpha-channel data is non-zero for any given pixel the display processor simply sends the sum value of all lower priority channels (in this case the background bitmap) and the sprite color value through the blending function. Because there is no read-modify-write overhead it is in one respect much more efficient than the alpha-blending the PSX or any other modern GPU employs - so when it is usable it is a cheap effect for Saturn, while blending is always costly for a standard architecture and therefore why you typically see flat color effects on the PSX - but it has inherent limitations. Which is why all these overall tradeoffs are excusable, in the context of the technology of the day. I’m still guessing that the Saturn has two alpha channels / blending circuits, in some form. But maybe not, and in either case the dithered transparencies are understandably unavoidable for some situations, given the practical technology of the day. EDIT: well that and the fact that the Saturn is a kludge architecture informed more by SEGA’s Super Scaler arcade legacy, which was always about throwing more processors on a board for purpose built functions I think!


oh no i hold NiGHTS into dreams… as the standard for saturn 3d graphics so sonic R just looks blocky and ugly to me


I actually completed Tomb Raider on the Saturn. It was a great game with tons of exploration and wall jumping and climbing. The Saturn could have handled the sequel IMO.

It almost sounds like the Saturn had hardware that even most of Sega’s developers didn’t understand, and the Saturn certainly didn’t reach its full potential in most games or perhaps never reached its full potential altogether. I’d have to look at the actual hardware to see what can be channeled through it, where and in what order, but it was certainly needlessly complex.

In any case, the Saturn was capable of true translucent 3D effects, but it was too little too late.

Bah I say! Bah! I would honestly love to know what Camelot did in SF3 Scenario 2 to improve the 3D character models so much.

I had the opposite perception. Nights never impressed me graphically.

If you set Sonic R side by side with Wipeout 1-2 (native composite resolution – not upscaled), you’d suddenly wonder why the Saturn had such a poor reputation for 3D graphics. Sonic R built on the Saturn’s strengths by using all that extra processing power (the Saturn has two 32-bit RISC processors running at 28.6 MHz, and the Playstation has one CPU running at 33.9 MIPS).

The music still makes me laugh though.