> The first missing feature is texture mapping. Basically the ability to pass in uv coordinates for each vertex.
These two situations are fundamentally related. Most 3D rasterizers including the Playstation use inverse texture mapping, iterating over framebuffer pixels to find texels to sample. The Saturn uses forward texture mapping, iterating over the texels and drawing them to their corresponding framebuffer pixels.
The choice to use forward mapping has some key design consequences. It isn't practical to implement UV mapping using forward mapping, and quads are also become a more natural primitive to use.
> The second missing feature is alpha blending, or semitransparent quads. The Saturn did support half-transparency, but it only worked for non-distorted sprites, and you really want more options than just 50% or 100%.
I don't consider this to be a significant problem. The checkerboard mesh feature provides a workable pseudo-half-transparent effect, especially with the blurry analog video signals used at the time.
Side note but forward mapping is also the reason why half-transparency does not work for distorted sprites. Forward mapping means that the same pixel may be overdrawn. If a half-transparent pixel is blended twice, the result is a corrupt pixel.
VDP2 can also provide half-transparent effects in various circumstances - this video provides a comprehensive look at various methods which were used to deliver this effect.
Forward texture mapping sounds like something I would have imagined as a novice before I learned how inverse texture mapping worked.
> Polygons contain diagonal lines that may result in pixel dropout (aliasing). When this occurs, holes are anti-aliased. For this reason, some pixels may be written twice, and therefore the results of half-transparaency processing as well as other color calculations cannot be guaranteed.
We have at least one examples of this being implemented in real hardware at around the same time: Nvidia's NV1 (their first attempt at a GPU) was a quad based GPU that used forwards texture mapping. And it had both UV mapping and translucent polygons. The sega saturn titles that were ported to the NV1 look absolutely great. And I the Sega Model 3 also implemented both UV mapping and transparency on quads (I'm just not 100% sure it was using forwards texture mapping).
I'm not suggesting the Saturn should have implemented the full perspective correct quadratic texture mapping that the NV1 had. That would be overkill graphically (especially since the ps1 didn't have perspective correct texture mapping either), and probably would have taken up too many transistors.
But even a simple scheme that ignored perspective correctness were the artist provided UV coord for three of the vertices (and the forth was implicitly derived by assuming the quad and it's UVs were flat) would have provided most of the texture mapping capabilities that artists needed. And when using malformed quads to emulate triangles, the 3 UV coords would match.
And most of the hardware is already there. VDP1 already has hardware to calculate the slopes all four quad edges from vertex coords and an edge walker to walk though all pixels in screen space. It also has similar hardware for calculating the texture space height/width deltas and walking though texture space. It's just that texture space is assumed to always have slopes of zero.
So that's the only changes we make. VDP1 now calculates proper texture space slopes for each quad, and the texture coord walker is updated to take non-zero slopes. I'm hopeful such an improvement could have been made without massively increasing the transistor count of VDP1, and suddenly the saturn's texture mapping capabilities are roughly equal with the PS1.
> I don't consider this to be a significant problem. The checkerboard mesh feature provides a workable pseudo-half-transparent effect
I think you are underestimating just how useful proper transparency is for early 3D hardware.
(by proper transparency, I mean supporting the add/subtract blend modes)
And I haven't put it on my list of "important missing features" because sometimes games want to render transparent objects. As you said, the mesh (checkerboard) mode actually works for a lot of those cases. And if you are doing particles, then you can often get away with using non-distorted quads, which does work with the half-transparent mode. (though, from an artistic perspective, particles would really look a lot better if they could instead use add/subtract modes)
No. Proper transparency is on my list because it's an essential building block for emulating advanced features that aren't natively supported on the hardware.
One great example is the environment mapping effect that is found in a large number of ps1 racing games. Those shiny reflections on your car that sell the effect of your car being made out of metal and glass. The ps1 doesn't have native support for environment mapping or any kind of multitexturing, so how do these games do it?
Well, they actually render your car twice. Once with the texture representing the body paint color, and then a second pass with a texture representing the current environment UV mapped over your car. The second pass is rendered with a transparency mode that neatly adds the reflections over the body paint. The player doesn't even notice that transparency was used.
Environment mapping is perhaps the most visually impressive of these advanced rendering tricks using translucency, but you can find dozens of variations spread out though the entire PS1 and N64 libraries.
Probably the most pervasive of these tricks are decals. Decals are great for providing visual variation to large parts of level geometry. Rather than your walls being a single repeating texture, the artist can just slap random decals every so often. A light switch here, a patch of torn wallpaper there, blood spatters here and graffiti over there. It the kind of thing the player doesn't really notice except when they are missing.
And decals are implemented with transparency. Just draw the surface with it's normal repeating texture and then use transparency to blend the decals over top in a second pass. Sometimes they Add, sometimes they Subtract. Sometimes they just want to skip transparent texels. And because the Saturn doesn't support transparency on 3D quads, it can't do proper decals. So artists need to manually model any decal-like elements into the level geometry itself, which wastes artist time, wastes texture memory and wastes polygons.
For some reason, VDP1 doesn't even support transparent texels on 3D quads, the manual says they only work for non-distorted quads.
> Side note but forward mapping is also the reason why half-transparency does not work for distorted sprites. Forward mapping means that the same pixel may be overdrawn. If a half-transparent pixel is blended twice, the result is a corrupt pixel.
No... This isn't a limitation of forwards texture mapping. Just a limitation of VDP1's underwhelming implementation of forwards texture mapping.
I don't think it would be that hard to adjust the edge walking algorithm to deal with "holes" in a way that avoids double writes.
My gut says this is basically the same problem that triangle-based GPUs run into when two triangles share an edge. The naive approach results in similar issues with both holes and double-written pixels (which breaks transparency). So triangle rasterizers commonly use the top-left rule to ensure every pixel is written exactly once by one of the two triangles based on which side of the edge the triangle is on.
----------
Though that fix only allows 3D quads to correctly use the half-transparency mode.
I'm really confused as to why VDP1 has such limited blending capabilities. The SNES had proper configurable blending in the 90s, and VDP2 also has proper blending between it's layers.
And it's not like proper blending is only useful for 3D games. Proper blending is very useful for 2D games too, and certain effects in cross platform 2D games can end up looking washed out on the Saturn version because they they couldn't use VDP2 for that effect and were limited to just VDP1's 50% transparency on VDP1 instead of add/subtract.
VDP1's 50% transparency already pays the cost of doing a full read-write-modify on the framebuffer, so why not implement the add/substract modes? A single adder wouldn't be that many transistors? That would be enough to more or less match the playstation, which only had four blending modes (50/50, add, subtract and 25% of background + 100% of foreground).
Though, you can go a lot further than just equality with the PS1. The N64 had a fully configurable blender that could take alpha values from either vertex colors or texture colors (or a global alpha value).
> VDP2 can also provide half-transparent effects in various circumstances - this video provides a comprehensive look at various methods which were used to deliver this effect.
> https://www.youtube.com/watch?v=f_OchOV_WDg
Yeah, that's a great video. And it's the main reason why I started digging into the capabilities of the Saturn.
> No. Proper transparency is on my list because it's an essential building block for emulating advanced features that aren't natively supported on the hardware. One great example is the environment mapping effect that is found in a large number of ps1 racing games.
That's a good point which I had not considered. However, just adding support for half-transparency wouldn't have been enough to bring the Saturn up to speed in this regard. Half-transparency is also really damn slow on the Saturn. Quoting the VDP1 User's Manual:
> Color calculation of half-transparency is performed on the pixel data of the original graphic and the pixel data read from the write coordinates. Drawing in this case slows down, so use caution—it takes six times longer than when color calculation is not performed.
This compounds with the Saturn VDP1 already having a considerable reduction in fillrate compared to the Playstation GPU. Playstation wasn't just capable of transparency, it was also damn fast at it, so emulating effects with transparency was feasible.
PS2 took this approach to its illogical extreme.
My proposed changes only really bring the Saturn's 3D graphics into roughly the same technical capabilities as the Playstation.
They don't do anything to help with the performance issues or the higher manufacturing costs. Or the string of bad moves from SEGA management that alienated everyone.
But an alternative history with these minor changes might have been enough to stop developers complaining about the Saturns non-standard 3D graphics and keep a healthy market of cross-platform games. It might have also prevented commenters on the internet from making overally broad claims about the Saturn's lack of 3D capabilities.
---------------
Fixing the performance limitations and BoM cost issues would have required a larger redesign.
I'm thinking something along the lines of eliminating most specialised 2D capabilities (especially all of VDP2). Unify what's left to a single chip and simplify the five blocks of video memory down to a single block on a 32bit wide bus. This would significantly increase the bandwidth to the framebuffer, compared to VDP1's framebuffer which uses a 16bit bus, while decreasing part count and overall cost.
The increased performance of this new 3D focused VDP should hopefully be powerful enough to emulate the lost VDP2 background functionality as large 3D quads.
Playstation indeed had unified video memory on a 32 bit bus, but the bus is only saturated when drawing 2D elements or untextured polygons[1].
Sprite-heavy 2D games like DoDonPachi already run better on Playstation than Saturn due to the faster framebuffer, while games like Spyro the Dragon, Crash Bandicoot and Final Fantasy 7 demonstrate the effective strategic use of untextured polygons.
[1] https://psx.arthus.net/sdk/Psy-Q/DOCS/CONF/SCEA/adv_gpu.pdf , slide 17.
It's basically inevitable. Any proposal for fixing the Saturn that slaps on a "optimise for BoM" requirement will be pushed towards unified video memory. And the only contemporary example of such a GPU was the playstation. Not to mention, the design of the playstation GPU appears to be pretty close to optimal for it's era and price point.
And if you were to also switch your hypothetical Saturn design to triangles and inverse texturing, the resulting design looks even more like the Playstation GPU.
> but the bus is only saturated when drawing 2D elements or untextured polygons
The Playstation's bus will also be saturated when loading the texture cache, or when scanning out the previous frame (only on the later SGRAM versions of the GPU). Even with textured triangles framebuffer writes are limited to 16bit bandwidth, less time is wasted on those other tasks which periodically interrupt rasterisation.
Though, now that I think about it, inverse texturing probably gives the playstation a massive performance advantage over and forwards texturing. Inverse texturing allows triangles to be rasterized in strict left-to-right then top-to-bottom order, which is also the order that the framebuffer is laid out in memory. This order will minimise the amount of time spent waiting for the next DRAM row to be prefeched.
The order of framebuffer writes with forwards texturing is somewhat chaotic and probably wastes a bunch more time closing and opening DRAM rows.
Saturn doesn't have a texture cache, since texel reads should be nice and sequential. But then it pays a penalty when writing to the framebuffer.
But I'm only saying that because I know write combining is a thing, and I'm not sure a hardware engineer in 1993 would have gone down that path.
AFAIK the problems lie in things like clipping/collision detection. Now that you have four points instead of three, there is no guarantee that the polygon is a flat surface.
About collision: I don't know how it is computed, but if it's by ray casting, that is now also used for lighting effects and sometimes reflections. Which would be another reason to stick to triangles.
The Nintendo DS actually supports both tris and quads as rasterization primitives, which has some interesting consequences for shading[2].
[1] https://psx-spx.consoledev.net/graphicsprocessingunitgpu/#gp...
Most games avoid using the same meshes for both rendered graphics and collision detection. Collision detection is usally done against a simplified mesh with much fewer polygons.
Since most games already already have two meshes, there isn't a problem making one mesh out of quads and the other out of triangles.
After VDP1 has rendered all quads to the framebuffer (aka VDP2's "sprite data" layer), some pixels in the framebuffer layer can use an alternative color mode. Normal 3D quads (with Gouraud shading) use a 15 bit format with five bits of Red, Green and Blue representing the final color (and the the top most bit is set to one).
Those background elements instead use a palletted color format. The top bit is zero (so VDP can tell which format to be used used on a per-pixel basis) and then there are 3 bits of priority (unused in this case), 3 bits of "Color calculation ratio" which Gamehut used to implement the fade, and a 9 bit color palette index.
So it's not just that you can't use Gouraud shading, but these fading objects are limited to a global total of 512 unique colors which must be preloaded into VDP2's color ram (well, I guess you could swap the colors out each frame)
-----
Importantly, since this trick only works against VDP2 background layers, it can't be used to blend two 3D quads against each other.
At minimum, it really needed to support the addition/subtraction blend equations.
Second, because it doesn't work correctly for distorted quads, it really doesn't exist in the context of "Saturn's 3D capablties"
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 "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.
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.
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.
> I think his biggest mistake was that he underestimated how quickly the industry would switch to mainly focusing on 3D.
I think his mistake was a bit more subtle than that. Because he didn't have any experience in 3D or anyone to ask for help, he didn't know which features were important and which features could be ignored. And he ended up missing roughly two important features that would have bought the Saturn upto the standard of "workable 3D".
The quads weren't even that big of a problem. Even if the industry did standardise on triangles for 3D hardware, a lot of the artist pipelines sick with quads as much as possible.
The first missing feature is texture mapping. Basically the ability to pass in uv coordinates for each vertex (or even just a single uv offset and some slopes for the whole quad). The lack of texture mapping made it very hard to export or convert 3D models from other consoles. Instead, artists had to create new models where each quad always maps to an 8x8 texel quad of pixels.
The second missing feature is alpha blending, or semitransparent quads. The Saturn did support half-transparency, but it only worked for non-distorted sprites, and you really want more options than just 50% or 100%.
With those two features, I think the Saturn would have been a workable 3D console. Still not as good as the playstation, but probably good enough for Sega to stand its ground until the Dreamcast launched.