When it comes to writing, I think the biggest factor that determines if/what/and how you write is the audience you imagine. When you write, you sort of picture yourself telling the story to someone. And the way that scene plays out in your mind depends entirely on who that person is.

If your mental image of the audience is "some random Internet user whose interests are different from mine", then you can't imagine them standing there patiently while you laboriously walk through all the details of your renderer. So you don't.

But if you imagine an audience that is "another retro renderer enthusiast who has similar projects", then you can imagine them getting hyped up by what you're saying and gleaning bits of useful stuff from it that they can apply to their own side projects. It almost feels wrong to not write it and let them down.

One advantage of this is being able to look back on previous projects in the future, as a form of documentation. That helps me pick up on a project I haven't worked on in a bit. True, you don't need to publish the documentation publicly, but since I wrote it, putting it up publicly is almost no effort now that I have a blog.

I personally am not "retro renderer enthusiast" nor have similar project, but this article was joy to read.

Either audience choice is fine, I just think it's interesting how it impacts the resulting writing.

While it's true that the PS1 handles perspective projection through the GTE (as the GPU is a primitive rasterizer, after all) I don't think it's fair to call it 'faked 3D' since, in my understanding, 3D projection is another fundamental stage in the graphics pipeline (our displays are 2D grids of pixels, so we need to transform the 3D world into something it can be displayed there). Other consoles like the Nintendo 64 provided more capability on the GPU side (the RCP) which allowed to move part of the matrix operations away from the CPU chip.

Be as it may, I've seen the 'fake 3D' claim before and I'm starting to wonder if I'm missing something in my understanding of this technology, maybe someone can offer a third opinion?

P.S I'm the one that wrote https://www.copetti.org/writings/consoles/playstation which is referenced at the bottom of the article (the 'Other reading'), I'm glad the author found it helpful (or interesting)!

In a "real 3D" rasterizer, you interpolate the depth coordinate for each individual pixel. You need this value to perform two steps in the pixel pipeline that are required to get the correct look: First, you use the depth coordinate the perform depth testing (reject pixels that should be hidden). Then, you use it to perform a perspective correct texture lookup (make straight lines on the texture obey the laws of perspective).

If you throw out the depth coordinate anywhere earlier in the pipeline, as the PS1 did, you can’t do either of those things, so you get artifacts where objects flicker and warp when rotating. The rasterizer really needs to be "3D aware" right until writing out the final pixel values.

Note that both artifacts can be lessened, to some degree at least, with workarounds. For depth testing, you simply sort the polygons (which doesn’t work in every case, as triangles can overlap in cycles). And for the texture lookup problem, you subdivide the polygons (this helps because the vertex calculations are perspective correct, but it's expensive and you'd need infinite subdivision to fully solve the problem).

As an aside, the PS1 had another issue where the rasterizer didn’t support subpixel precision, which also leads to artifacts. But IMO that’s mostly unrelated to the 3D coordinate problems — 2D games need that as well to get smooth movement.

I agree that all 3D is 'faked' in the sense that it's drawn to a 2D grid of lights eventually, I guess it just depends on where in the pipeline you make that fundamental transformation. I only meant faked in that the GPU itself is 2D, whereas the GTE is just math. So it's kinda like doing CSS transformations to make a web page all 3D-looking (a gross understatement I know, but, nevertheless). Though, semantically, I guess the '3D' part of a modern GPU is also 'just math'. Well now you've got me thinking about it harder...

Wonderful article by the way! I've read yours a few times myself.

So, like, the vertexes are in the right spots, but the texture mapping is off. So it kinda depends on if you need texture mapping to be perspective correct to consider a given example of 3D "real" vs "fake". Dark Forces also has perspective warping that happens in it's engine when you look up/down, as an example.

* https://youtu.be/VutzIK3DqZE?t=341 DF Retro analyzes ports of Tomb Raider

Great link. The artifacts are especially apparent when the walls are near the camera, for example at this timestamp: https://www.youtube.com/watch?v=VutzIK3DqZE&t=398s And note that here, the seemingly flat walls are already heavily subdivided into smaller polygons to lessen the impact of the problem. (Why they wouldn't then make use of those additional polygons to include more geometry details for free is beyond me, however.)

Wolfenstein's correct texture mapping is due to it using raycasting in a 2D plane and rendering scaled vertical strips of texture, which just happens to be perspective correct because you only ever have surfaces at 90deg angles in the vertical.

As to why those extra triangles weren't used for detailing, it's likely because that would take up extra level data. Tessellation of an existing triangle into smaller triangles doesn't.

Wolfenstein and Doom are 100% correct because Carmack 'cheated' by deciding to never look down/up or draw slopes :-) so whole game is drawn with 'lines of constant Z'. Or as they put it

Chris Hecker (Microsoft/Maxis/etc): that's a classic Carmack thing which is like Fuck those general problems, Im gonna solve this other problem perfectly

John Miles (ORIGIN/Miles Design/etc): Its all about not doing the math, we were still at a point in time when you won by not doing the math

The company I work for considers this kind of writing to be fundamental to being a considered a principal engineer. I can't imagine they invented this idea; it's probably relatively common in the startup world.

While this might not have been the author's motivation, having a popular tech blog certainly doesn't hurt one's employment prospects.

Z-buffer is just an array of values you can sample, often as a texture. There is no inherit coordinates, unlike, say, vertices. Z-buffer is a 2d map anyway. The offset into that buffer would be the x and y.

Or do you just mean there's no hardware accelerated z-buffer?