Both of these issues can be fixed without switching away from forwards texture mapping.
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.