6

During a conversation, a friend of mine sent me this picture:

It's the first Thief (I guess), with so-called software rendering.

I already experienced this effect in Quake 1-2 and to an extent, in Shogo: M.A.D., but never actually understood, what it is.

How these settings work, why they produce lower quality and why it diseppeared after the millenia?

  • 3
    Which "effect" are you referring to? Is it the pixellatedness? The low colour depth? The lack of anti-aliasing? – wizzwizz4 Mar 12 '18 at 17:37
  • @StephenKitt If you see what it's asking, then I suppose it's not unclear... I'll re-open. – wizzwizz4 Mar 12 '18 at 17:40
  • @wizzwizz4 all of them. The general phenomena, maybe the best encompassed by "lower quality than what the use of libraries like OpenGL would produce". – Katamori Mar 12 '18 at 17:42
  • That question falls in agreatly subjective cathegory, as 'uggly' is int the eyoe of the beholder - I would see abobe as rather awesome. Possible answers will be rather broad and as well unclear. More of a topic for a free form forum than a Q&A site, isn't it? – Raffzahn Mar 12 '18 at 17:54
  • @Raffzahn then I'll edit out subjective parts; I'm genuinely interested in a factual technical answer. – Katamori Mar 12 '18 at 17:58
15

“Software rendering” usually refers to 3D rendering which doesn’t use hardware assistance (see Wikipedia for a lengthier description).

Older games only had software renderers; hardware rendering didn’t exist in consumer PCs. In the late 90s, 3D-capable graphics processors became available, including the famous 3Dfx chips, and games started using them — initially via game patches, e.g. the various 3D accelerated patches available for Quake. Eventually hardware-assisted 3D rendering became the default, using OpenGL or Direct3D, but for a few years, games continued to ship with software renderers too; examples include Thief, the early Unreal games... However as hardware renderers increased in capabilities and speed, it became unrealistic to maintain equivalent software renderers running at an acceptable speed, and game developers stopped building software renderers.

During the intermediate phase, when hardware renderers and software renderers were both available, quality varied; early hardware renderers weren’t always all that good (see for example the various renderers available in Tomb Raider), and significant effort was spent on certain software renderers (Unreal’s was particularly impressive). As time wore on though, developers produces better hardware-assisted rendering engines, hardware accelerators improved, and less time was spent on software renderers, resulting in the quality differences you’re seeing. This is still visible on older engines today: Quake or Quake II on a recent GPU are much nicer to play than they were when they first came out! (And yes, the engines have been tweaked since then, but the core is fundamentally unchanged.)

  • 1
    Possibly also relevant: as noted, there were several competing graphics cards, and games would need to include extra code for each they supported. Some early games, especially from smaller companies, might not support all the graphics cards/accelerators out there. If a game didn't support the graphics card you had (or you hadn't yet got a graphics card), you had to use software rendering. – TripeHound Apr 6 '18 at 12:50
  • It's also worth noting that some of the early 3D hardware produced better-looking output, but were slower to render in games that took advantage of it. I briefly owned an S3 ViRGE card, but returned it when I decided that the slightly-better graphics weren't worth the reduced frame rates. Hardware rendering wasn't much of a win until T&L got added. – fadden Apr 10 '18 at 18:02
  • @fadden that was definitely relevant with many “3D” cards; I would argue though that 3Dfx cards were quite useful despite their lack of T&L (speaking as someone who had Voodoo 1 and 2 cards back in the day, followed by a GeForce 256 DDR — in fact I still have the Voodoo cards...). – Stephen Kitt Apr 10 '18 at 18:42
5

The Mode is called software rendering, because the program is painting all pixels with the CPU. So you are not using a 3D-Interface like OpenGL or DirectX (which interfaces with 3D-hardware) but set single Pixels (aka Bytes) in a framebuffer(a rectangle part of your Memory you usually copy to your Graphics card)

Why is it so ugly?

Because the CPU was busy painting the triangles with (sometimes affine) texturemapping into the memory. There was simply no time to do transparency (which needs reading the already painted pixel and multiplying!) or antialiasing(which is even more costly).

  • With today's increased CPU capacity, would it be possible to do all the features you mentioned with software rendering? (regardless of its practicality) – Katamori Mar 12 '18 at 19:09
  • 3
    @Katamori no ... it is not a matter only of CPU speed but also parallelism and memory through output. GPUs have massively more processing power for rendering than CPU because of many reasons like more cores, HW architecture designed for rendering meaning much less instructions to do the same as on CPU and HW interpolators .... – Spektre Mar 12 '18 at 19:11
  • @Katamori Yes, of course it is. – immibis Apr 3 '18 at 4:46
  • Full ack to Spektre, but there are still some fearless souls at radgametools.com/cn/pixofeat.htm who were coding the pixomatic 3D engine, a pure DirectX 9 comaptible Software Renderer. Still on the performance comparison you can extrapolate todays performance – Peter Parker Apr 4 '18 at 14:57
5

Taking as given: software rendering uses the general-purpose CPU to paint pixels rather than a dedicated GPU; the general-purpose device has less ability because it's not optimised for the job; writing two sets of code rather than one is more work and GPUs became commonplace so the worse option died out.

Then the specific flaws you're seeing in that image — to answer "why they produce lower quality" — are lack of texture filtering and very harsh geometry edges.

When deciding which colour to make a screen pixel, both the CPU and the GPU know which point on the original textured surface is visible there. That's where processing diverges. It is very unlikely that the point on the original surface falls exactly on the centre of a pixel in the texture.

A 3d accelerator of the period is likely to have time to perform bilinear or trilinear filtering. Bilinear filtering samples all four texture pixels that surround the point being output, then calculates a weighted sum. So that's four texture lookups, six multiplies and a summation. Trilinear filtering does that twice with two different resolutions of texture and calculates the weighted sum of the results, for eight texture lookups and thirteen multiples.

That's far too much work for a CPU. So it just figures out which source pixel is closest to the point and outputs that.

The difference is between textures that when stretched too large obviously show their individual pixels as boxes, and surfaces that just look very blurry.

In that era, harsher geometry edges result from the CPU just not being fast enough to draw the same number of pixels as a 3d accelerator. So a lower screen resolution is used. They also tend to run at a slower frame rate, which makes the effect more apparent. Several 3d accelerators of the period support edge blending as a way to eliminate rough edges, which uses per-pixel weighted transparency on each edge pixel, but that's not as useful as it sounds because it presupposes you're drawing all geometry from back to front and therefore doesn't interact very well with engines built around z-buffering.

The posted screenshot doesn't show these problems, but other divergences you might see in contemporaneous titles:

  • the software renderer may use a lower colour depth. That's to reduce the amount of data that needs to be worked on and moved around. But it tends to severely deteriorate lighting;
  • the software renderer may decide not to perform perspective calculations within polygon faces at every pixel, either not doing it at all (for the PS1 look) or just doing it less frequently (as per Descent and Quake; it tends to look a bit like walls are fabric strung on box frames that move with the player);
  • the software renderer may use lower-resolution textures. That's just a simple effect of the difference between being a game that has to fit in 16mb of RAM and being a game that can stretch out to 16mb RAM plus an extra 4mb on the GPU.
0

OpenGL, Direct3D and so on take advantage of hardware 3D accelerators which can draw 3D scenes much more quickly than the CPU can do by itself. So to maintain acceptable frame rates, scenes rendered in software with the CPU must be much more simple (easier on the CPU) than scenes rendered in hardware.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.