Update

sw_rendering.md

@@ -1,6 +1,6 @@
 # Software Rendering
 
-Sofware (SW) rendering refers to [rendering](rendering.md) [computer graphics](graphics.md) without the help of [graphics card](gpu.md) (GPU), i.e. computing images only with [CPU](cpu.md). This mostly means rendering [3D](3d.md) graphics but can also refer to other kinds of graphics such as drawing [fonts](font.md) or [video](video.md). Before GPUs were invented, all rendering was done in software, of course -- games such as [Quake](quake.md) or Thief were designed with SW rendering and only added optional GPU acceleration later. SW rendering for traditional 3D graphics is also called software [rasterization](rasterization.md), as rasterization is the basis of current real-time 3D graphics.
+[Software](software.md) (SW) rendering refers to [rendering](rendering.md) [computer graphics](graphics.md) without the help of [graphics card](gpu.md) (GPU), i.e. computing images only with [CPU](cpu.md). This mostly means rendering [3D graphics](3d_rendering.md) but can also refer to other kinds of graphics such as drawing [fonts](font.md) or [video](video.md). Before GPUs were invented, all rendering was done in software, of course -- games such as [Quake](quake.md) or Thief were designed with SW rendering and only added optional GPU acceleration later. SW rendering for traditional 3D graphics is also called software [rasterization](rasterization.md), as rasterization is the basis of current real-time 3D graphics.
 
 SW rendering has advantages and disadvantages, though from our point of view its advantages prevail (at least given only capitalist GPUs exist nowadays). Firstly it is **much slower** than GPU graphics -- GPUs are designed to perform graphics-specific operations very quickly and, more importantly, they can process many pixels (and other elements) in [parallel](parallelism.md), while a CPU has to compute pixels sequentially one by one and that in addition to all other computations it is otherwise performing. This causes a much lower [FPS](fps.md) in SW rendering. For this reasons SW rendering is also normally of **lower quality** (lower resolution, [nearest neighbour](nn.md) texture filtering, ...) to allow workable FPS. Nevertheless thanks to the ginormous speeds of today's CPUs simple fullscreen SW rendering can be pretty fast on PCs and achieve even above 60 FPS; on slower CPUs (typically [embedded](embedded.md)) SW rendering is usable normally at around 30 FPS if resolutions are kept small.
 
@@ -10,7 +10,7 @@ SW rendering may also utilize a much wider variety of rendering techniques than
 
 A lot of software and rendering frameworks offer both options: accelerated rendering using GPU and SW rendering as a [fallback](fallback.md) (in case the first option is not possible). Sometimes there exists a rendering [API](api.md) that has both an accelerated and software implementation (e.g. [TinyGL](tinygl.md) for [OpenGL](opengl.md)).
 
-For simpler and even somewhat more complex graphics **purely software rendering is mostly the best choice**. [LRS](lrs.md) suggests you prefer this kind of rendering for its simplicity and portability, at least as one possible option. On devices with lower resolution not many pixels need to be computed so SW rendering can actually be pretty fast despite low specs, and on "big" computers there is nowadays usually an extremely fast CPU available that can handle comfortable FPS at higher resolutions. There is a LRS software renderer you can use: [small3dlib](s3l.md).
+For simpler and even somewhat more complex graphics **purely software rendering is mostly the best choice**. [LRS](lrs.md) suggests you prefer this kind of rendering for its simplicity and [portability](portability.md), at least as one possible option. On devices with lower resolution not many pixels need to be computed so SW rendering can actually be pretty fast despite low specs, and on "big" computers there is nowadays usually an extremely fast CPU available that can handle comfortable FPS at higher resolutions. There is a LRS software renderer you can use: [small3dlib](s3l.md).
 
 SW renderers are also written for the purpose of verifying rendering hardware, i.e. as a [reference implementation](reference_implementation.md).
 
@@ -29,25 +29,27 @@ Possible tricks, cheats and [optimizations](optimization.md) you may utilize inc
 - Using painter's algorithm (sorting triangles and drawing back to front) instead of z-buffer if you need to save a lot of RAM. But remember sorting doesn't [work](work.md) perfectly, glitches will inevitably appear, and you will probably gain overdraw penalty.
 - Ad previous point: you don't have to perform whole triangle sorting each frame if you need to save speed, it may be good enough to perform a constant continuous sorting by performing only a few iterations of some sorting algorithm per frame.
 - You may lower the quality of far-away objects in many ways, e.g. with [LOD](lod.md), only using affine texturing for them (as opposed to perspective-correct one) or even just using a constant color (average color of the texture), maybe even just drawing 2D sprites instead of 3D models etc. This may help a lot.
+- Try to reduce [overdraw](overdraw.md) (overwriting already rendered pixels with new closer ones) which wastes computation time. This can be achieved by good [culling](culling.md) of obscured objects or by using z-buffer along with front to back drawing.
 - Generally use cheap [approximations](approximation.md) such as [Gouraud](gouraud.md) (per-vertex) [shading](shading.md) instead of [Phong](phong.md) (per-pixel), nearest neighbour texture sampling, only approximate perspective correction (every N pixels), simplified handling of near-plane culling (e.g. just pushing the vertices in front of camera instead of actually culling a triangle) etc.
-- Use general [optimization](optimization.md) techniques: e.g. using power of two resolution for textures, fixed screen resolution that's known at compile time or inlining of your shader function will probably help performance.
+- Use general [optimization](optimization.md) techniques: e.g. [precomputation](precomputation.md), using power of two resolution for textures, fixed screen resolution that's known at compile time or inlining of your shader function will probably help performance.
 - TODO: MORE
 
 ## Specific Renderers
 
 These are some notable software renderers:
 
-- **[Build engine](build_engine.md)**: While not a "true 3D", this was a very popular [proprietary](proprietary.md) portal-rendering engine for older games like Duke Nukem 3D or Blood.
+- **[Build engine](build_engine.md)**: So called ["pseudo 3D"](pseudo_3d.md) or primitive 3D, this was a very popular [proprietary](proprietary.md) portal-rendering engine for older games like [Duke Nukem 3D](duke3d.md) or [Blood](blood.md).
 - **[BRender](brender.md)**: Old commercial renderer used in games such as Carmageddon, Croc or Harry Potter 1. Later made [FOSS](foss.md).
 - **[Dark Engine](dark_engine.md)**: Old proprietary game engine which includes a SW renderer, used mainly in the game Thief. The author writes about it at https://nothings.org/gamedev/thief_rendering.html.
-- **[id Tech](id_tech.md)**: Multiple engines by [Id software](id.md) (later made [FOSS](foss.md)) used for games like [Quake](quake.md) included a software renderer. Quake's SW renderer was partially described in the *Michael Abrash's Graphics Programming Black Book*.
+- **[id Tech](id_tech.md)**: Multiple engines by [Id software](id.md) (later made [FOSS](foss.md)) used for games like [Doom](doom.md), [Quake](quake.md) and its successors included a software renderer. Quake's SW renderer was partially described in the *Michael Abrash's Graphics Programming Black Book*, Doom's renderer is described e.g. in the book *Game Engine Black Book DOOM*.
 - **[Irrlich](irrlicht.md)**: [FOSS](foss.md) game engine including a software renderer as one of its [backends](backend.md).
 - **[Mesa](mesa.md)**: [FOSS](foss.md) implementation of [OpenGL](opengl.md) that includes a software rasterizer.
 - **[small3dlib](small3dlib.md)**: [LRS](lrs.md) [C](c.md) 3D rasterizer, very simple.
-- **SSRE**: The guy who wrote [LIL](lil.md) also made this renderer named Shitty Software Rendering Engine, accessible [here](http://runtimeterror.com/tech/ssre/).
+- **[SSRE](ssre.md)**: The guy who wrote [LIL](lil.md) also made this renderer named Shitty Software Rendering Engine, accessible [here](http://runtimeterror.com/tech/ssre/).
 - **[System Shock](system_shock.md) engine**: Old proprietary game engine.
 - **[TinyGL](tinygl.md)**: Implements a subset of [OpenGL](opengl.md).
 - Many old [games](game.md) in the 90s implemented their own software renderers, so you can look there.
+- ...
 
 ## See Also