I briefly scanned through these articles and did not see any mention of polygon clipping. A note to the inexperienced; it took me some years (I am dense at times) to realize that one of the primary uses for polygon clipping is to clip polygons against the view frustum in view space (ie after polygons have been projected to the screen). This is useful to only draw the part of a possibly very large polygon that is visible. As a consequence of clipping, a triangle can result in 5 sided polygon, so drawing/rasterizing arbitrary polygons, not just triangles is desirable. You'll often read about rasterizing arbitrary side polygons when studying software 3D, this is why.
Also, I always like to link this tour de force by Charles Bloom when software 3D comes up, it's a great read:
I totally agree that knowing how triangle/fragment clipping works at the lowest level is a valuable skill but for the vast majority of people its a level of complexity way above their need. From a practical perspective (i.e. you want to make a Game, Simulation, realtime 3D rendering of any kind), you should not be writing a software rasterizer. As an exercise in learning, go for it, but if you want to have both practical and marketable skills, you need to learn a graphics API like OpenGL, Direct3D or even Metal. These APIs mask a lot of the implementation details but in return you get a fast, reliable and consistent API.
From a high-level, you find ways to use these APIs in smart ways to optimize for modern graphics cards. That in itself is a MASSIVE challenge and not to be underestimated. This is where a smart use of API calls becomes an excellent Engine.
For myself, I started backwards, learned OpenGL then Direct3D then finally built a software rasterizer and raytracer. To me that was a great way to learn because I first understood the high-level concepts (what are textures, what is a mesh) before learning low-level concepts (what are barycentric coordinates, how does bresenhams work, how do you do perspective correction).
Just a guess.
I can recommend the game programming gems series. I don't know what number they are up to now, I had the first three and they were a huge asset in learning all these techniques and more.
I think this is the link but it doesn't work on mobile: http://www.gdcvault.com/play/1014628/Classic-Game-Postmortem
http://sysweb.cs.toronto.edu/publication_files/0000/0247/icc... is a good example of the kinds of things I'm looking at but I only barely grasp the concepts in the paper itself.
Lets see if they are still on time to change the wave.
This leads me to wonder what a game would look like if all perspective were so inverted, so that the farther away an object is, the larger it appears.
If you want to change that, you can't have a camera that is a point. That's how parallel projection works; the camera is basically a plane of the same size as the picture plane, so the rays never diverge. What you're suggesting is basically that the camera would be larger than the projection plane. That would cause the rays to converge in a single point some distance away from the camera. You might then just as well think of that point as the camera, and do what pnp wrote, just reverse the z buffer.
Edit: I realize what I saw is a textured version of what you are describing.
In other words, it's elucidating to do, but unless you're an industry veteran or subject matter expert, you should almost never do it with the intent of actually using the result.
Loading large worlds while maintaining a high frame rate? It's one deep problem for Skyrim-style worlds. Another for shooters. Yet another for Minecraft. Shadows are yet another deep problem, and so is ambient occlusion, and any number of lighting/rendering techniques.
In other words, you're not really in tutorial territory anymore. You're in article/paper territory.
Academic approach is nececary for research work but when you're just implementing stuff it's already been groked by other people and you can find their blog/notes/code online.
* http://procworld.blogspot.com/ which is a voxel-based rendering engine mostly developed by one person
* http://the-witness.net/ which is a game with a custom engine developed by a small team and features many realistic effects