Comment by delta_p_delta_x
3 days ago
This isn't software rendering, it's called turning off spatial anti-aliasing. You can still do that in the modernest of modern games. Software rendering went out of the window because the CPU tends to have other things to do whilst playing the game besides only multiplying 4x4 matrices, which was shifted to the shader cores of GPUs. The look-and-feel that the author is discussing including shadow and texture LUTs can also be done on GPUs by passing the tables in to shaders as constant read-only storage buffers; that is not specific to software rendering. It bears mentioning that many modern software renderers (LLVMpipe/Lavapipe, OpenSWR, WARP) are basically full D3D/OpenGL/Vulkan devices in their own right, including shader compilers.
Also, modern spatial anti-aliasing works by multisampling within a pixel (or even neighbouring pixels) and taking the average, rather than filtering across singly-sampled pixels, which massively reduces the quality. Not to mention temporal and machine learning AA techniques including DLSS, XeSS, FSR, and all the TAA implementations in many games.
His definition of software rendering is
I think that’s the standard definition. If you mean that this style can be achieved with graphics hardware then that’s a different argument and why your first sentence is deemed contentious
> If you mean that this style can be achieved with graphics hardware
I really ought to have been more specific with my first sentence to ward off any hair-splitting.
The author claimed to love software rendering, but the examples given to highlight the supposed positives of software rendering can all be achieved on GPUs. If the author had instead highlighted the ability to easily debug and inspect the inner workings of the rasterisation pipeline with a software renderer, that might have been a much more relevant argument.
He says he likes the look, that's subjective and doesn't need arguments. You wanted to read another, technical article.
15 replies →
> the examples given to highlight the supposed positives of software rendering can all be achieved on GPUs.
Any look in older games, 2d or 3d, can be achieved on modern GPUs, so that seems like a vacuous thing to state.
3 replies →
I agree with you and I think others aren't understanding your point. "Hardware rendering" can also be achieved by the CPU in "software". It will just not be realtime. Just fire up Blender and render scenes using the CPU, which is a standard option. You will see how amazing "software" rendering can be.
There's nothing special about the GPU besides doing certain kind of operations that are very useful for graphics (and AI, among other things) really efficiently. The distinction should never have been "software rendering" vs "hardware rendering", but "what CPU rendering could achieve when GPUs weren't widespread" versus "what GPU rendering has been able to achieve since they became available".
2 replies →
What they meant was: "This aesthetic isn't exclusive to software rendering". I thought the rest of their comment made that pretty clear once you got past the first sentence.
I think the issue is that modern aliasing can be done without a GPU, so it's not that he loves software rendering, it's that he loves the style the constraints of the time imposed, and that style is not married to CPU-exclusive rendering.
Yes - but most of the rest of the article describes something different! (Which is what the post you're replying to explains)
yup, it should be renamed to "I Love GL_NEAREST_MIPMAP_NEAREST"
Real players know you us the coarsest mipmap level the whole time, so every texture is something like 4 pixels. And 320x200 and directmouse. It's the smooth movement, high fps and direct control that provides the sense of "being there". Not the graphical fidelity.
I think you've almost exactly described my Counter-Strike setup 25 years ago.
Friends at LAN parties complained how ugly it was and my rebuttal was usually: "I'm afraid it stays unless you can buy me a better video card." The fact that the CRT slowly drifted to a yellow tinge on everything didn't help the asethetics--especially on de_dust. The GPU at the time might have been a Riva 128 ZX.
Is there a video somewhere (or easy download/install on linux) so I can see/play what this looks like
4 replies →
Of course you can but I think author’s point is to actually test/evaluate maximum performance of true software rendering on modern machines, and this is fine and refreshing exercise, even with filtering.
This actually what I have also returned to in my latest demoscene demo: https://www.pouet.net/prod.php?which=106969
It’s 100% software rendering on CPU just multithreaded. But no metal/direct3d just framebuffer and rest is yours routines… and I actually added bilinear filtering…
Still fun project to do and remind yourself about fundamental algorithms behind elementary 3D graphics
You have to admit, it makes for a less catchy title
T-shirt worthy
Yeah, when glquake and the Voodoo1 came out, I was actually initially disappointed because I'd seen demos of vquake on the verite and its texture mapping was closer to the original. But you couldn't complain about the framerate of the 3dfx.
His point is more about the texture filtering than about anti aliasing. Software rendered games never supported texture filtering (although they could have, at a significant cost), they always used simple nearest neighbor scaling. Of course you can turn filtering off on a GPU too, but hardly any game ever did that.
> Software rendered games never supported texture filtering
Unreal did. Or maybe Unreal 2, I don't remember which.
It didn't use true bilinear filtering, but another technique: Texture Coordinate Space Dithering https://www.flipcode.com/archives/Texturing_As_In_Unreal.sht...
> it's called turning off spatial anti-aliasing.
It's called "nearest neighbour texture sampling", as opposed to bilinear/trilinear/anisotropic
Software rendering went out of style because z-buffer based rasterization is embarrassingly parallel and benefits from a hardware implementation.
TAA has a pretty bad reputation among many gamers for being too blurry. TSR (temporal super resolution) is a newer implementation that's overall sharper, better at eliminating "jaggies", and performant, without visible ghosting or artifacting.
Indeed. Personally I am quite old-school, I like MSAA (despite the performance hit) and subpixel morphological AA (SMAA, used to great effect in Crysis). DLSS is interesting but I cannot unsee the artifacts.
TAA is a nightmare, and Unreal Engine depends way too much on it. TSR also suffer from ghosting and artifacts unfortunately. But I have come to the realisation that gaming will be about massive compromises for the next decade.
TAA introduce aliasing on fast moving element which is far more annoying than blurring
The alias was there from the start. It just couldn't find where it was in an older frame to do the anti aliasing.
"Software rendering went out of the window because the CPU tends to have other things to do besides just multiply 4x4 matrices, which was shifted to the shader cores of GPUs."
Hardware rendering took over because generating a 3D scene is embarrassingly parallel, and the industry quickly learned that you can have thousands of reasonably simple "cores" that can divide and conquer a scene in parallel. There was a no way a general purpose CPU could keep up.
Not so quickly. The shader cores were a breakthrough from early 2000s. First consumer GPUs were built as same as the 1980s GPUs but everything had been integrated in a single chip.
It is the sheer amount of compute and memory bandwidth that mogs a CPU but the parallel processing doesn't help much, at least in realistic 3D: an 8 core AVX-512 march CPU has an order of magnitude more SIMD lanes than something like RSX in PS3 yet it still wouldn't be able to match its performance in rendering textured z-buffered triangles. 3D graphics can really go wide only on wireframe/points, z-buffer forces sequencing between polys so the parallelism there is very limited.
Parallel processing was fully in force in the very first GPUs, like the Voodoo. Not like a modern GPU with thousands of more flexible shader cores, but the first iteration had a pipeline architecture that saw multiple blocks operating on rendering separate parts of the pipeline in parallel. This was revolutionary. Especially given that CPUs at the time had a single core.
I'm not sure what the PS3 comparison is for, or why we're comparing a 2026 AVX-512 CPU with a 2006 gaming console. Okay? A modern GPU can obliterate any CPU in SIMD, presuming you conform with the types it wants. Add that it's weird to bring up as AVX and other SIMD techniques are basically the same sort of architecture, parallelizing a problem.
> 3D graphics can really go wide only on wireframe/points, z-buffer forces sequencing between polys so the parallelism there is very limited.
Rendering a 3D is scene is the very definition of embarrassingly parallel. While optimizers can cull the scene, you know that the entire depth within the frustum (there are a variety of optimizing techniques to minimize the overdraw, but it's a part of rendering a scene) is "rendered" and in amalgamation the Z-buffer values are compared and discarded, blended, or whatever? It is an extraordinarily parallel operation.
4 replies →
spatial anti-aliasing
aka (just) anti-aliasing, we are talking original quake 1 era, after all.
How is it not software rendering? These games shipped without hardware renderers. Yes, they also don't have AA, but how does that make it not software rendering?
Here’s an analogy. Suppose someone said, “I love manual transmission cars” and then described in detail the physical knobs and dials that all the cars from the 1950s had.
It turns out what they like is physical knobs and dials. You can have those in automatic transmission cars. It so happens that most modern automatics also have shitty touchscreens.
(I know this analogy isn’t precise because there was a long period of automatics with physical controls, but bear with me.)
The point is that there’s nothing _inherent_ to software rendering that’s responsible for the thing he likes. The distinction is useful because, for example, he could go seek out modern games with the look he likes. Or make games. And if he thought the thing he likes comes from having a software renderer, he’d leave a lot of performance and power efficiency on the table for no good reason. He likes a certain rendering style that’s equally achievable with both GPU and CPU rendering. The choice of hardware should probably be driven by considerations like performance, debuggability, platform support, availability of libraries, etc.
Ah, I see. Maybe: somebody says they love audio cassette players, and start talking about the super tactile mechanical buttons and switches that go chunk in a satisfying way. You could rightly object that that you can put buttons like that on an mp3 player. But it's a historical fact that these things are actually linked, in a way that's meaningful to people, namely in their personal nostalgic experiences.
2 replies →
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.
15 replies →
They mean that what the OP prefers about it is not the fact that it’s done in software. “This” is “the thing the OP seems to prefer”.
[flagged]