Update

sw_rendering.md

@@ -4,13 +4,13 @@
 
 It must be noted that SW rendering doesn't mean the program is never touching [GPU](gpu.md) at all, in fact most personal computers nowadays REQUIRE some kind of GPU to even display anything. Even if GPU is involved in presentation of the computed image, we still talk about SW rendering as long as the image was computed by the CPU. Of course there may exist a gray area where SW and hardware accelerated rendering are combined.
 
-SW rendering has advantages and disadvantages, though from [our](lrs.md) 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, no [antialiasing](antialiasing.md), [nearest neighbour](nn.md) texture filtering, no [mipmaps](mipmap.md), ...) 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.
+Insofar as advantages and disadvantages of SW rendering go, there are both of course, but from [our](lrs.md) point of view the advantages prevail (at least given only capitalist GPUs exist nowadays). First of all it must be said that 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, no [antialiasing](antialiasing.md), [nearest neighbour](nn.md) texture filtering, no [mipmaps](mipmap.md), ...) 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.
 
 On the other hand SW rendering is **more [portable](portability.md)** (as it can be written purely in a portable language such as [C](c.md)), **less [bloated](bloat.md)** and **eliminates the [dependency](dependency.md) on GPU** so it will be supported almost anywhere as every computer has a CPU, while not all computers (such as [embedded](embedded.md) devices) have a GPU (or, if they do, it may not be sufficient, supported or have a required [driver](driver.md)). SW rendering may also be implemented in a simpler way and it may be easier to deal with as there is e.g. no need to write [shaders](shader.md) in a special language, manage transfer of data between CPU and GPU or deal with parallel programming. SW rendering is the **[KISS](kiss.md) approach**, which also implies it's **more [future proof](future_proof.md)** etc. Furthermore SW rendering is **more predictable** -- this is because GPUs are highly [magical](magic.md) devices [optimized](optimization.md) to work well under certain assumptions (e.g. not drawing too many small triangles) and each GPU (or even the same GPU with different drivers) may react differently to what we're rendering, so even though GPU performance will be higher, it will be much more difficult to be kept stable and predictable over a wide range of different GPUs and drivers.
 
 SW rendering may also utilize (at least more easily and without penalties) a much wider variety of rendering techniques than only 3D [rasterization](rasterization.md) traditionally used with [GPUs](gpu.md) and their [APIs](api.md), thanks to not being limited by hard-wired pipelines, i.e. it is **more flexible**. This may include [splatting](splatting.md), [raytracing](raytracing.md) or [BSP rendering](bsp.md) (and many other ["pseudo 3D"](pseudo3d.md) techniques) and even completely different rendering paradigms such as [frameless rendering](frameless.md).
 
-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)).
+Rendering frameworks and [libraries](library.md) commonly offer both options: accelerated rendering using GPU and SW rendering as a [fallback](fallback.md) (should the prior be unavailable for whatever reason). 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](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).