alt Hacker NewsSoftware renderers can do bilinear filtering. It does not change any aspect of how the software renderer works. I’ve implemented this, so I know: it’s a couple of lines change in the texture lookup. But it adds three lerps per channel, per pixel, whereas nearest neighbor requires none. That’s 9 multiply-adds in the tightest inner loop that would normally have zero. In the 3D accelerators of the era, the pipelines were all fixed-function (programmability is why NVIDIA renamed it GPU when they released the GeForce 256), so those lerps were in the silicon whether you used them or not. Bilinear filtering had zero impact on render speed, so long as you weren’t saturating video RAM with the added texture lookups.
TL;DR a software rendered game and a 3D accelerated game from that era looked VERY different, but that difference was largely down to a feature that was often implemented in the software renderer, and was only a couple of lines in the innermost loop. But rarely used outside of a few choice effects due to the massive performance impacts. On 3D accelerators it was free, and default-on.
(I’m an old fart that cut my teeth in programming writing software renderers with the community at Flipcode, if anyone remembers that.)
I'm not disputing the technical details of anything you're saying. I don't think the author of TFA is, either.
So when you say "this is incorrect", and also:
> Software renderers can do bilinear filtering.
What do you mean? Nobody is disputing they can. The author is talking, in my opinion, about how software and hardware renderers of that time behaved in practice in games you could buy at the time. It's just that peppering the text with "at the time", "typical" and "in practice" makes for very cumbersome reading.
I'm also an old fart, by the way :) I don't remember Flipcode, but I wrote software renderers for fun and also for my CS coursework. I read my Abrash and my Foley & van Dam, etc. I then lost track of that, time was finite and I had to choose my hobbies more carefully!