The point is that the thing that OP likes has nothing to do with whether something is rendered in software or hardware.

"Nothing to do" is a bit strong. It has something to do, and the explanation is in the history of how these games worked.

Can it be simulated on GPUs? Sure. But it was typical of software renderers of that era, and NOT typical of GPUs, and it has to do with how they were used.

▲

adastra22 4 hours ago | parent | next [-]

This is incorrect. It is exactly the same algorithm as circuits in the GPU or as instructions on the CPU. No difference, except one: the way data is pipelined on the GPU makes texture blending free, or nearly so. So to show off, every 3D game back then turned it on (an OpenGL/Glide/D3D configuration option) and everything got smoothed out, often with no option to turn it off. That's why it ends up looking different: because the game itself selected different interpolation in accelerated vs software rendered. It was a game choice.

These days you can use different presets to override those choices, and have your 8K, 240Hz Quake look software rasterized, if you want.

▲

the_af 3 hours ago | parent [-]

> This is incorrect

Incorrect how? It's correct in that software renderers of the time TFA describes mostly looked like this, and GPU renderers didn't (of course, they weren't called GPUs back then), and there's a reason for this. Even you admit it later in your comment.

So saying "it has nothing to do" with software renderers (of the time) is wrong. It has something to do with how software renderers vs GPUs were used during that era in practice. It's also true you can simulate one with the other, but that doesn't make it incorrect or unrelated.

> So to show off, every 3D game back then turned it on (an OpenGL/Glide/D3D configuration option) and everything got smoothed out, often with no option to turn it off. That's why it ends up looking different

So it had something to do after all! So TFA has a point. He means software renderers in the sense you're describing here, and it's clear from the text. He's not implying you cannot use a GPU to achieve the same result.

▲

inexcf 2 hours ago | parent [-]

This is ridiculous. He explained it perfectly and he was right stating that it has "nothing to do with software rendering". The fact that people specifically chose to do it differently on hardware makes nothing about what the article mentions specific to software rendering. Otherwise if you do the smoothing on the CPU you have to call it a hardware renderer now to be consistent.

▲

the_af 2 hours ago | parent [-]

It's not ridiculous. It's also perfectly clear from TFA, one has to go out of their way to misinterpret this.

E.g.

> Software renderers generally sample textures pixel by pixel, so every texel stays a crisp square. Early 3D cards smoothed textures with bilinear filtering, which looked impressive in 1997 but turns everything soft and blurry to my eye now.

The author is a hobbyist discussing things in context. Early 3D cards, bilinear filtering as done in '97, etc. You cannot take random words and criticize the article. This seems to be a retrogaming hobbyist blog about doing stuff with old hardware and games.

Nitpicking is pointless.

	▲	inexcf an hour ago \| parent \| next [-]
		The point is that the look is not inherent to software rendering. You're misinterpreting this as some kind of denial of historical association. You're own quote there identifies texture filtering as the difference. Explaining that you can get those sharp textures with hardware acceleration, isn’t “pointless nitpicking.”
	▲	nkrisc an hour ago \| parent \| prev [-]
		I think the comments section is the perfect place to nitpick something like this.

▲

chpatrick 4 hours ago | parent | prev | next [-]

"Software" isn't the point. You can do the exact same math on CPU or GPU. OpenGL supports nearest neighbor texture filtering on whatever hardware you run it on since 1992, one year before Doom even came out.

▲

the_af 3 hours ago | parent [-]

But in practice, this didn't happen, which is what TFA seems to be all about. So it's not incorrect to talk about software renderers (of the time) vs hardware accelerated graphics (of the time) and how they were used in practice (at the time). It's just cumbersome to write "at the time", and it's understood from context; at least I did. It also helps to look at the rest of the blog's articles and what the blog is about...

	▲	chpatrick an hour ago \| parent [-]
		Sure, software rendering mostly used nearest neighbor, but it's not crisp because it's software rendering, which is what the article claims.

▲

GuB-42 2 hours ago | parent | prev [-]

I isn't "simulated" by GPUs, it is a rendering mode that GPUs had since before they were called GPUs.

The reason software rendering look different from 3D accelerated games (incl. 3Dfx) is nearest neighbor filtering and low resolution, which were necessary to keep a reasonable framerate. At the time, it was considered ugly, so if your hardware supported bilinear filtering for free, it was turned on, but it didn't have to.

In the time of fixed pipelines (3Dfx to GeForce 3), you couldn't do arbitrary operations on pixels, so some effects, like the kind that are common in the demoscene were software only. So games that used these effects, like Comanche voxels can indeed be thought as representative of software rendering, and they can, of course, be simulated on modern GPUs as everything that was done on software before can.

But the article uses Quake as an example. I may be wrong, but I don't think it does anything that can't be done by a fixed pipeline GPU. In fact, even keeping the same style (nearest neighbor filtering + low resolution), hardware rendering will probably look better because the GPU does proper perspective correction on every pixel. The tricks used by the Quake engine are awesome, but they don't beat raw power.

	▲	the_af 8 minutes ago \| parent [-]
		> I isn't "simulated" by GPUs, it is a rendering mode that GPUs had since before they were called GPUs. Yes, of course. That's what I meant. I didn't mean "simulate" as in fake, I meant it more as in "replicate the same effect". Ultimately, hardware and software are equivalent, give or take matters of costs, debugging and performance. > In the time of fixed pipelines (3Dfx to GeForce 3), you couldn't do arbitrary operations on pixels, so some effects, like the kind that are common in the demoscene were software only. So games that used these effects, like Comanche voxels can indeed be thought as representative of software rendering, and they can, of course, be simulated on modern GPUs as everything that was done on software before can. Yes, I think that's the spirit in which TFA's term "software rendering" must be taken. The context is old games and their pipelines as they were used at the time, not more recent GPUs or practices. > The tricks used by the Quake engine are awesome, but they don't beat raw power. I really don't think the article is contesting this.