Wrote a little software rasterizer for a roguelike years back and the best part was just being able to step through the whole pipeline in a debugger. No driver weirdness, no shader compile quirks, the pixel is wrong because your math is wrong.
Yeah, that is the hardest part about 3D graphics programming, at least it was the last time I had my elbows deep in it.
You're not doing traditional application programming once you get into 3D graphics. You are driving a microcomputer at arm's length. Every aspect of that challenge comes into play, from the fact that it's a black box to how you can have it working perfectly in one configuration of hardware, and then find it doesn't work on another configuration.
My favorite reasons for this include "there is a legitimate bug in the closed-source shader compiler" and "this graphics card advertises a capability but in reality it implements it in software so if you turned that flag on your render speed suddenly went to seconds per frame."
The CUDA era helped some with this problem because there was suddenly massive pressure on making the GPU into less of a bundle of pipelines and specialty hardware accelerators strapped together and more into standardized massively parallel fabric, because card manufacturers suddenly found themselves not wanting to be left out in the cold if they invested their time in building a very very fancy specialty hardware circuit for doing texture manipulation or something... And that proved to be useless for mining Bitcoin, or whatever they suspected might replace Bitcoin in the future. I think there are far less gotchas now regarding weird architecture than there were in the 2010s.
I'm going to guess if you did it on the video card and simply disabled those enhancements it would be considerably more energy efficient than doing it on the CPU as well which (a) means your laptop battery lasts longer on a charge, and (b) also opens up the possibility of not needing a particularly powerful CPU in order to juice the resolution, because the video hardware is doing the work for you.
From a programming perspective I do completely get the desire to have the CPU do all the work though - if you want absolutely everything under your control it's easier, and especially if your game is single-threaded.
I've mentioned this elsewhere, but nowadays, anything you see out of an HDMI/DP/eDP cable comes out of a GPU. Modern OSs make it impossible to do 'software rendering' any more; it's just that much faster and that much more efficient, even if it is harder to program directly. Even IPMI BMCs have a tiny GPU doing stuff.
It's also because at this point the operating systems themselves use the accelerated graphics architecture for things like window compositing, because that also turned out to be faster. And it's much easier to do cute little visual effects like wiggles and window distorts if those entities are actually 3D rendered graphics objects.
Even the standard desktop experience is a 3D graphics application these days.
Why is it “impossible”?
If you mean that a rendered frame has to reside in the graphics memory before being sent to the display, then I think that was the case even when software rendering was a thing.
If you mean rendering a frame entirely in the main memory by the CPU, then there is nothing making it impossible. I mean, most major 3D rendering software still have CPU renderers as an option. Slow, but doable.
P.S: I am using offline renderers here as an extreme example. A game renderer - especially for scenes like Quake’s - are definitely going to be far simpler and cheaper.
By 'impossible', I mean it in a very strict sense of blitting full-screen frames directly into the framebuffers provided by HDMI or (e)DP representing a visible surface. This is still kind of possible in Windows when games are properly full screen and not 'borderless full screen', but the OS still does compositing in the background, and the GPU is still involved to some extent.
Of course, offline rendering is a different story.
There's in no path for that. Each GPU is different, and I suspect won't even let the CPU access the final framebuffer they use for video signals, even if you wrote the driver yourself.
As for Windows compositing, use the graphics API to acquire exclusive fullscreen. Vulkan gives this example:
Modern "GPUs" have the ability to scan out from multiple buffers at the same time and do rectangular compositing during the scan out -- basically like a few giant sprites. It's got absolutely nothing to do with normal GPU work. Zero.
It lets a few unobstructed windows do animation without having to involve the compositor => lower latency AND lower energy use. They do NOT have to be full screen at all.
Oh, and they can also handle framebuffer formats that aren't RGB. This is very useful for video, as the natural format there is YUV or something similar. The YUV => RGB conversion step becomes unnecessary.
Using the extra unpopulated memory slots on your VGA card to get that 1024x786 at 256 colors. 800x600 is the largest which will fit in 512k of video memory at that colors depth, or getting 16bit color space in 800x600 due to having doubled your memory from 512k to 1024k. And those were definately the software rendering days, every ramdac needs it's own memory pool.
I think you're misunderstanding. No one is saying that a GPU isn't involved at all.
But if you rasterize your frames into a buffer using the CPU (and not OpenGL, Vulkan, Metal, D3D, etc.), and then scan that out on the GPU, that is indeed software rendering in the sense that matters here.
The idea that software rendering is impossible because the GPU owns the scanout buffers is just silly pedantry.
It just feels wrong historically. When HL came out, people were very enthusiastic about texture filtering and the game was clearly designed with hardware rendering in mind.
It was in development for a long time at a critical point in history. It seems to have started off as a software-first project (or possibly even software-only), then switched to hardware-first near the end of development. And not every effect was implemented in the hardware renderers.
Half-Life has a lot of grid textures that really need bilinear filtering and mipmapping to look decent, and they look even better with anisotropic filtering.
Many other games that released a little later (like Decent III) actually fully removed their software renderers before release because games needed to be hardware-only if they actually wanted to compete on visual quality.
But, what was actually broken in OpenGL pre-Steampipe update?
The two things I know about were:
1. The different looking water (not worse, just different)
2. In the software renderer some texture sets randomly tiled to make them look less repetitive. It's nice, but I would wager a bet that no one back then even knew about this bug, let alone complained about it.
People also forget that the software renderer was very slow on contemporary hardware, and even a basic 3D card had way better performance.
> 2. In the software renderer some texture sets randomly tiled to make them look less repetitive. It's nice, but I would wager a bet that no one back then even knew about this bug, let alone complained about it.
I'm pretty sure that's there with the GL rendere as well. It's HL Source that was missing that and its pretty noticeable if you know the game.
Yeah, I like when games use nearest, or dedicated pixel art shaders. Bilinear just looks low-effort to me, especially when it's used for whole-screen scaling! Apple's Lanczos also looks a bit disgusting to me, I can't tolerate the display scaling on iPad because of this.
Concur. Feels like a conflation; CPU vs GPU rendering doesn't change the appearance directly. The article performs further conflations later re the OS comparison and Steam re Ion Fury etc.
makes me wonder how would gameplay fare when a gpu renders the game with very limited options. Sometimes higher FPS would play weirdly with the physics engine and some moves you could do when capped at 24fps were not possible at 60fps.
No software rendering requires DOS, you could use it with Windows back in the day (how I originally played Half Life) and engines that still support it will run on modern OSes too.
I share the same opinion as the author. That said, it's also important to remember that the display devices of the time were different than they are now and the sharp pixelated textures we see now would look a bit different on a CRT from that period. The sharp, gritty look that he (and I) admire would have been just a little fuzzier back then.
A tiny bit fuzzier but not in a way that mattered back then. If you're running a software renderer it could well have been at 320x200 and on any monitor that comes out still looking pretty much like an LCD display, with slight blending on the edges technically but still large, large pixels not being blended. Even at 640x480 there was noticeable blockiness not being blended away. Monitors were designed to be sharper than the televisions the consoles were outputting to. Software rendering at anything high enough to be blended looking was a slideshow.
A lot of the fuzziness of TVs vs. PC monitors was down to the poor signaling (RF modulators, composite video). Some lucky/picky folks had TVs with component video (YPbPr) which produced images about as good as VGA monitors (RGB).
However, CRTs do not have fixed pixel geometries, and even when they produced relatively sharp images, they would seem fuzzier or softer in a side-by-side comparison with an LCD of the same size and resolution.
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 OP is discussing including shadow and texture LUTs can also be done on GPUs; there is nothing specific to software rendering. It bears mentioning that many modern software renderers (LLVMpipe/Lavapipe, WARP) are basically full D3D and 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.
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.
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.
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
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.
In a software-rendered game, the CPU draws every pixel. There’s no 3D card involved: the game works out each frame in its own code and writes it straight to video memory
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.
Not necessarily. Someone unfamiliar with graphics might believe that there’s something about a CPU that a graphics card doesn’t have such that the look can’t be achieved. Certainly the author of this piece seems to believe that.
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".
This is fine, but then we'd also have to specify your CPU performance constraints. If you max out a modern CPU for CPU rendering, you will get graphics vastly exceeding what 80s/90s CPU rendering could achieve.
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.
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.
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.
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.
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.
The article says that "even a 3.3GHz quad-core Xeon “isn’t quite enough to run Shadow Warrior at full 1600 by 1200”." But we are on DOS, so I guess three cores are just not doing anything there?
That quote about Shadow Warrior doesn't pass the smell test. You're right there must be bottlenecks in the way.
There is simply no way a modern CPU cannot crush much harder problems than Shadow Warrior. The throughput of multiple threads/SIMD/memory bandwidth + data-oriented design is terrifying. The TFLOPS are an order of magnitude less than a GPU, but still well beyond human comprehension.
The Build engine's rendering was stunningly simple (and dare I say: elegant). You could run hundreds of instances of Shadow Warrior on a single EPYC (since they mentioned Xeon) at that resolution and framerate if you rewrote the engine with modern mechanical sympathy in mind. On a modern desktop CPU it'd probably be over a hundred instances.
People, including many programmers, just don't grasp how much power we have under the hood nowadays...
Quake DOS is from a year earlier to Shadow Warrior and it would get around 60fps at 320x200 on a Pentium II 266. The Xeon from that video is from 2008, and from geekbench 2 results it's ~30 times faster than the pentium. 1600x1200 is 30 times the pixels of 320x200.
Additionally Shadow Warrior used some newer rendering techniques, so it's possible they don't scale well to higher resolutions.
I don't think it really applies when we're talking about PC gaming. Consoles were blurry as hell on a huge interlaced low-res TV, but late-'90s PC games on a decent monitor had nice and crisp pixels on a CRT that weighed as much as a large dog. Especially when flat-glass trinitron CRTs and the like came out (yes spellcheck, that's a word), I don't think the end-user appearance on the screen was all that different from what we have now, other than obvious stuff like aspect ratio and incremental improvements to resolution and framerate. Maybe deeper blacks and lower latency on CRT.
The ability to shift resolutions natively was neat, though, I missed that in the pre-4K days.
Even the oldest and cheapest CRT monitor my family had was pretty pixel-accurate unless you were right at the edges. I was doing pixel art on it as a child and had no issues at all.
> Ion Fury, a Build engine game from 2019, still ships with a software renderer.
Amazing game BTW, best shooter I've played in many years. I never really got into build engine games back then, so it's not just my rose-tinted glasses, that game is a masterpiece.
Ion Fury uses a modified version of eDuke32 which can do software only rendering, and quite well, but defaults to GPU acceleration because Ion Fury uses the real time lighting.
That said, the Build Engine had software voxels in 1997. Which was pretty cool.
Unreal (and Unreal Tournament), Thief, Quake II (a slight improvement over Quake), Half-Life (a great improvement over Quake), Shadow Warrior,
Any modern port of Doom supporting software rendering, Heretic, Hexen, Descent, System Shock, Homeworld.
Software renderer of Quake II has no colored lighting. It's OpenGL-only feature. Half-Life and Unreal do this better, they support colored lighting in their software mode.
Quake II is a completely different game from Quake, isn't it? The levels, artwork and gameplay feel quite different. I personally prefer the look and feel of the original Quake, particularly when using the Arcane Dimensions mod.
A few years ago I seriously contemplated making a game using software rendering, in part because the only target was SDL. I actually got a 3D engine running 2K@60Hz with HL2-level scenes, with the CPU basically idle, so it's not a terrible idea.
(Then LLMs started taking off and I decided I needed to reskill out of the industry, just in case)
It's like 2.5D, maybe like 2.75D or so. Technically, every map in vanilla Doom is a 2D map, with various "sectors" in the map having height; they're rendered in a sort of pseudo 3D, but crucially the map will never have one floor about another¹. I don't think I'd argue the 2D maps technically make it "not 3D", though.
However, Doom also renders textures using an algorithm that sort of paints walls as like vertical lines of sorts. The exact algorithm it uses makes it hard to look up (to pitch), and I think impossible to roll the camera. See <https://en.wikipedia.org/wiki/Doom_engine#Rendering> — it has a good animated graphic of what happens if you do look up, and the differences between the output of Doom's software renderer's algorithm and something actually rendering 3D.
¹modern ports have ways to accomplish this, and even before there were direct ways of doing it, clever map layout and instantaneous teleporting can get pretty close.
Software rendering was useful for me for a long time but as a long-time gamer (from the original DOOM to Cyberpunk 2077 and beyond) I can firmly say that real-time raytraced games at 4K/60FPS with dynamic lighting, reflections, massive geometry detail, etc, all greatly enhance the experience. That said, the old DOOM aesthetic pre-Voodoo was definitely nice. The voodoo smoothing had a nice cheap feel to it, too.
Software rendering often provided better visual effects than the GPU paths could provide at the time. A general purpose CPU can technically do any effect since the software is the pixel shader.
Programmable shader pipelines weren't a thing until Geforce 3 in 2001.
Ah,Sorry,in 2001 it was actually the first, so Geforce 1 / ONE.
It hat -fasten your seatbelts- one(!) dedicated pixelshader and one dedicated vertexshader :-)
High times back then - it was like entering next dimension.
I remember when I finally saw my favourite 3D games (Quake 2 and Pod) on a Voodoo2 and I immediately bristled: I hated the blurry way the textures looked with bilinear filtering, and was iffy on their love of yellow lighting.
I've softened on the issue of non-white lights, but I 100% am still full of nostalgia about unflitered low-res textures.
I love Software Rendering too! I'd add Unreal Tournament to the list of "Games worth trying", though not sure what the multiplayer scene is like nowadays.
The sound card took sound computation off the CPU as well. Back in the day, every aspect of the game was fighting for CPU cycles.
Way back in the day there were some very impressive (given the technology) arcade ports to things like the Apple ][. That system's audio required running an assembly function that literally touched a memory address over and over again at a specific time rate; each touch flipped the electromagnet on the speaker. So games with theme music had to time slice hanging out in the audio routine versus doing anything else.
I grew up with a copy of Moon Patrol on Apple ][c and I didn't know for years that the theme song isn't supposed to sound like it's being played through a tea kettle.
I think it's because adding a sound card offloaded sound processing from the CPU and it had more cycles to draw frames! Probably back when we were at like 25Mhz
In the first waves of multimedia PCs - the CPU was tasked with doing sound, networking, hard drive control, etc. - pretty much all of the cost savings came from having minimal hardware for the auxiliary components and doing it all in drivers.
A common "Trick" was to buy cards that had essentially their own processors to handle this stuff - SoundBlasters, 3Com nics, IDE drive controllers that had their own processor (hell, even up to their own OS) since that freed the CPU up for doing actual work - gaming. Even an external or other
CPUs were a bottle neck but most people didnt tax the single core machines doing most daily work (office work, browsing the web) so it was fine, but once you load up a game that needs sound, 3d, networking, disk access all at once it would start stealing clock cycles trying to do all of that in one place.
A 16(!!!) bit ISA slot card, which revolutionized PC-audio-experience.
Are they still on the market or crashed by the ever-more-increasing onboard chips?
And there was Gravis Ultrasound, where you could upload samples into the RAM of the soundboard (that was like superpowermegatech back at these days :-)
IIRC, the highest degree of fidelity was fu**ng 16 MB of onboard RAM on the soundboard.
The Sound Blaster 2.0 wasn't 16-bit. It could do a higher sample rate than 1.0 but it was still doing 8-bit audio in an 8-bit ISA slot. The Sound Blaster 16 was a separate product another year or two later.
They might be thinking of the Sound Blaster Pro or Pro 2 which were 16-bit ISA cards, although really they were basically still 8-bit ISA cards that only used the extra pins on the 16-bit connector to give you a few more choices for IRQ/DMA. My gut feel is that the Pro and Pro 2 were when the SB really hit the mainstream. A lot of people I knew had them at the time, at any rate.
The thing is that Duke3d ran fast/sounded just fine even on a slow Pentium with a basic sound blaster. GUS was very useful in the 486 era, but it sounds like it was actually better to not use it with a faster computer in this case.
> Are they still on the market or crashed by the ever-more-increasing onboard chips?
I don't think any major vendor has made ISA sound cards in almost 30 years. Discrete PCIe sound cards exist but I don't know who exactly their intended market is. Audio pros?
You can find old 90's ISA cards used on eBay and whatever. The more sought after types (e.g. SB Pro) may not be exactly cheap, though.
Also, for the retro PC market, there are hobbyist cards such as the PicoGUS. [1]
So, yes or no, depending on what you're asking for.
> had essentially their own processors to handle this stuff
Most of the benefit came from the sound card doing DMA from a memory buffer instead of using a high-frequency interrupt to have the CPU give it sound samples one or two bytes at a time (fetched from the very same memory buffer(s)).
More sophisticated cards could also do mixing of several sounds in "hardware" (usually by having their own little CPU do the work) instead of having the main CPU doing the mixing. Some of them could even play the constituent sounds at different speeds (Gravis Ultra Sound and Midi cards but the Midi cards usually had fixed sound samples). This mattered for more sophisticated game audio for a few years until x86 performance improvements made it irrelevant. DMA is still crucial.
I vividly remember playing around on a friend's 486 that had a scsi controller for the hard drives, that was the best 486 I ever used! It's been all win modems and liquid glass window borders since then!
Off-loads sample mixing to the sound card. Computers of that era were slow enough that doing 44100 additions per second was expensive (IIRC quake had 8Khz samples anyway).
Something that always seems to surprise me when I remember it today: Playing an MP3 on my Pentium CPU in 1996 worked, but it _really_ brought the system to its knees. I could choose between listening to MP3 music or interacting with some other program (mIRC, Netscape, etc) but certainly not both.
Decompression in conjunction with primitive multi-tasking on MacOS and Windows. That remained an issue until Windows XP.
(Very small groups of) people used be in awe at LAN parties when I showed them how Linux could play an MP3 without stutters while copying large files across the network and browsing images.
Then it was time to play games and people were less impressed by me not being able to join any other game than Quake...
Winamp was perfectly fine by itself as I recall it. Even on a P100 without MMX which was what I rocked around 96-97. But as soon as you did anything else that involved any kind of IO, there would be skips and stutters.
Odd. I distinctly remember listening to music via Winamp, and updating my tsv-databases, while copying downloaded data (mostly e-books and music) from the local uni's internet saved to Zip 100 disks (and later Zip 250s on a Pentium II). Same for the ubiquitous LAN parties. One thing to add is that the read and written data were completely sequestered (i. e. on different drives); an early safety practice that became a habit a long time ago.
CPUs from that era were single core and pretty slow. They had to do everything like game logic, graphics, sound, etc all at once, so it was often resource starved. Sound took some resources, sometimes significant depending on the sound and what else the cpu was doing, unless it was a really simple sound (think NES style sound). Moving that to a dedicated sound card meant the cpu didn't have to worry about sound anymore.
MY NAME IS DOCTOR SBAITSO.
I AM HERE TO HELP YOU.
SAY WHATEVER IS IN YOUR MIND FREELY,
OUR CONVERSATION WILL BE KEPT IN STRICT CONFIDENCE.
MEMORY CONTENTS WILL BE WIPED OFF AFTER YOU LEAVE,
SO, TELL ME ABOUT YOUR PROBLEMS.
I am still a big fan of CPU render for VFX (not games). It is stable, capable of very large scenes. GPU is fast but you will never render something really big. And CPU look is much much better.
> you will never render something really big. And CPU look is much much better.
Why do you believe these things? In VFX and film, the GPU shaders and rendering is identical to CPU, they use the exact same programmable shaders on either side, so there is no difference in look or capability. Today’s GPUs have out of core streaming and caching and access to host memory. Pixar showed off their pixel-matching between GPU and CPU at Siggraph this year, and mentioned that today’s consumer GPUs are big enough to render IIRC ~98% of their scenes without much ‘out-of-core’ tech. Lots of film and VFX studios are using GPUs in production today to render pretty big shots. I think your story is a bit out of date; GPUs being size limited was somewhat true in the past, but is quickly going away. The CPU vs GPU look question has never been true for VFX or film, and was only true in games if you chose different rendering algorithms.
Its so interesting to me that back then we would have died for the graphics we have today, and now this retro look is being appreciated. I mean, it definitely has an aesthetic but its generally unappealing. I guess nothing is immune to nostalgia and pining for being at the age when we had less responsibilities and life seemed easier.
188 comments
[ 0.94 ms ] story [ 30.0 ms ] threadYou're not doing traditional application programming once you get into 3D graphics. You are driving a microcomputer at arm's length. Every aspect of that challenge comes into play, from the fact that it's a black box to how you can have it working perfectly in one configuration of hardware, and then find it doesn't work on another configuration.
My favorite reasons for this include "there is a legitimate bug in the closed-source shader compiler" and "this graphics card advertises a capability but in reality it implements it in software so if you turned that flag on your render speed suddenly went to seconds per frame."
The CUDA era helped some with this problem because there was suddenly massive pressure on making the GPU into less of a bundle of pipelines and specialty hardware accelerators strapped together and more into standardized massively parallel fabric, because card manufacturers suddenly found themselves not wanting to be left out in the cold if they invested their time in building a very very fancy specialty hardware circuit for doing texture manipulation or something... And that proved to be useless for mining Bitcoin, or whatever they suspected might replace Bitcoin in the future. I think there are far less gotchas now regarding weird architecture than there were in the 2010s.
> "3D cards smoothed textures with bilinear filtering"
You can just not do that.
From a programming perspective I do completely get the desire to have the CPU do all the work though - if you want absolutely everything under your control it's easier, and especially if your game is single-threaded.
Even the standard desktop experience is a 3D graphics application these days.
If you mean rendering a frame entirely in the main memory by the CPU, then there is nothing making it impossible. I mean, most major 3D rendering software still have CPU renderers as an option. Slow, but doable.
P.S: I am using offline renderers here as an extreme example. A game renderer - especially for scenes like Quake’s - are definitely going to be far simpler and cheaper.
Of course, offline rendering is a different story.
As for Windows compositing, use the graphics API to acquire exclusive fullscreen. Vulkan gives this example:
https://github.com/KhronosGroup/Vulkan-Samples/tree/main/sam...
It lets a few unobstructed windows do animation without having to involve the compositor => lower latency AND lower energy use. They do NOT have to be full screen at all.
Oh, and they can also handle framebuffer formats that aren't RGB. This is very useful for video, as the natural format there is YUV or something similar. The YUV => RGB conversion step becomes unnecessary.
But if you rasterize your frames into a buffer using the CPU (and not OpenGL, Vulkan, Metal, D3D, etc.), and then scan that out on the GPU, that is indeed software rendering in the sense that matters here.
The idea that software rendering is impossible because the GPU owns the scanout buffers is just silly pedantry.
It was in development for a long time at a critical point in history. It seems to have started off as a software-first project (or possibly even software-only), then switched to hardware-first near the end of development. And not every effect was implemented in the hardware renderers.
Half-Life has a lot of grid textures that really need bilinear filtering and mipmapping to look decent, and they look even better with anisotropic filtering.
Many other games that released a little later (like Decent III) actually fully removed their software renderers before release because games needed to be hardware-only if they actually wanted to compete on visual quality.
But, what was actually broken in OpenGL pre-Steampipe update?
The two things I know about were:
1. The different looking water (not worse, just different)
2. In the software renderer some texture sets randomly tiled to make them look less repetitive. It's nice, but I would wager a bet that no one back then even knew about this bug, let alone complained about it.
People also forget that the software renderer was very slow on contemporary hardware, and even a basic 3D card had way better performance.
I'm pretty sure that's there with the GL rendere as well. It's HL Source that was missing that and its pretty noticeable if you know the game.
However, CRTs do not have fixed pixel geometries, and even when they produced relatively sharp images, they would seem fuzzier or softer in a side-by-side comparison with an LCD of the same size and resolution.
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.
Video: https://www.youtube.com/watch?v=8TvVMzyxACc
Browser(shareware): https://quake-srp.pages.dev/
Source: https://github.com/terrapapagalli1516/quake-srp
I love the graphics in your video, really interesting and fit the vibe of the original game too.
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.
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
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.
Any look in older games, 2d or 3d, can be achieved on modern GPUs, so that seems like a vacuous thing to state.
That's unfair, especially if you read his other articles.
> Someone unfamiliar with graphics
... is probably not the intended audience of a hobbyist, specialized blog such as the one we're discussing.
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".
aka (just) anti-aliasing, we are talking original quake 1 era, after all.
Unreal did. Or maybe Unreal 2, I don't remember which.
It's called "nearest neighbour texture sampling", as opposed to bilinear/trilinear/anisotropic
There is simply no way a modern CPU cannot crush much harder problems than Shadow Warrior. The throughput of multiple threads/SIMD/memory bandwidth + data-oriented design is terrifying. The TFLOPS are an order of magnitude less than a GPU, but still well beyond human comprehension.
The Build engine's rendering was stunningly simple (and dare I say: elegant). You could run hundreds of instances of Shadow Warrior on a single EPYC (since they mentioned Xeon) at that resolution and framerate if you rewrote the engine with modern mechanical sympathy in mind. On a modern desktop CPU it'd probably be over a hundred instances.
People, including many programmers, just don't grasp how much power we have under the hood nowadays...
Additionally Shadow Warrior used some newer rendering techniques, so it's possible they don't scale well to higher resolutions.
Sources: * https://framebuffer.io/project/quake * https://browser.geekbench.com/geekbench2/327940 * https://browser.geekbench.com/geekbench2/529270
Now that will truly blow his mind, at least on this setup and older games.
The ability to shift resolutions natively was neat, though, I missed that in the pre-4K days.
Amazing game BTW, best shooter I've played in many years. I never really got into build engine games back then, so it's not just my rose-tinted glasses, that game is a masterpiece.
That said, the Build Engine had software voxels in 1997. Which was pretty cool.
I can add more:
Unreal (and Unreal Tournament), Thief, Quake II (a slight improvement over Quake), Half-Life (a great improvement over Quake), Shadow Warrior, Any modern port of Doom supporting software rendering, Heretic, Hexen, Descent, System Shock, Homeworld.
That colored lighting, though.
(Then LLMs started taking off and I decided I needed to reskill out of the industry, just in case)
However, Doom also renders textures using an algorithm that sort of paints walls as like vertical lines of sorts. The exact algorithm it uses makes it hard to look up (to pitch), and I think impossible to roll the camera. See <https://en.wikipedia.org/wiki/Doom_engine#Rendering> — it has a good animated graphic of what happens if you do look up, and the differences between the output of Doom's software renderer's algorithm and something actually rendering 3D.
¹modern ports have ways to accomplish this, and even before there were direct ways of doing it, clever map layout and instantaneous teleporting can get pretty close.
Programmable shader pipelines weren't a thing until Geforce 3 in 2001.
The market clearly decided the tech. And yes, for I felt Comanche'94 was just uggly and "bricky"
It hat -fasten your seatbelts- one(!) dedicated pixelshader and one dedicated vertexshader :-) High times back then - it was like entering next dimension.
(Two chips, guys, two!)
I've softened on the issue of non-white lights, but I 100% am still full of nostalgia about unflitered low-res textures.
Way back in the day there were some very impressive (given the technology) arcade ports to things like the Apple ][. That system's audio required running an assembly function that literally touched a memory address over and over again at a specific time rate; each touch flipped the electromagnet on the speaker. So games with theme music had to time slice hanging out in the audio routine versus doing anything else.
I grew up with a copy of Moon Patrol on Apple ][c and I didn't know for years that the theme song isn't supposed to sound like it's being played through a tea kettle.
A common "Trick" was to buy cards that had essentially their own processors to handle this stuff - SoundBlasters, 3Com nics, IDE drive controllers that had their own processor (hell, even up to their own OS) since that freed the CPU up for doing actual work - gaming. Even an external or other
CPUs were a bottle neck but most people didnt tax the single core machines doing most daily work (office work, browsing the web) so it was fine, but once you load up a game that needs sound, 3d, networking, disk access all at once it would start stealing clock cycles trying to do all of that in one place.
A 16(!!!) bit ISA slot card, which revolutionized PC-audio-experience.
Are they still on the market or crashed by the ever-more-increasing onboard chips?
And there was Gravis Ultrasound, where you could upload samples into the RAM of the soundboard (that was like superpowermegatech back at these days :-) IIRC, the highest degree of fidelity was fu**ng 16 MB of onboard RAM on the soundboard.
:-D
https://en.wikipedia.org/wiki/Sound_Blaster#Second-generatio...
Im getting old :-D
:-D
I don't think any major vendor has made ISA sound cards in almost 30 years. Discrete PCIe sound cards exist but I don't know who exactly their intended market is. Audio pros?
You can find old 90's ISA cards used on eBay and whatever. The more sought after types (e.g. SB Pro) may not be exactly cheap, though.
Also, for the retro PC market, there are hobbyist cards such as the PicoGUS. [1]
So, yes or no, depending on what you're asking for.
[1] https://picogus.com/
Most of the benefit came from the sound card doing DMA from a memory buffer instead of using a high-frequency interrupt to have the CPU give it sound samples one or two bytes at a time (fetched from the very same memory buffer(s)).
More sophisticated cards could also do mixing of several sounds in "hardware" (usually by having their own little CPU do the work) instead of having the main CPU doing the mixing. Some of them could even play the constituent sounds at different speeds (Gravis Ultra Sound and Midi cards but the Midi cards usually had fixed sound samples). This mattered for more sophisticated game audio for a few years until x86 performance improvements made it irrelevant. DMA is still crucial.
(Very small groups of) people used be in awe at LAN parties when I showed them how Linux could play an MP3 without stutters while copying large files across the network and browsing images.
Then it was time to play games and people were less impressed by me not being able to join any other game than Quake...
No problems here on Winamped Windows 98, albeit on a Pentium 166 with MMX. Often enough it was just a systems configuration issue.
Why do you believe these things? In VFX and film, the GPU shaders and rendering is identical to CPU, they use the exact same programmable shaders on either side, so there is no difference in look or capability. Today’s GPUs have out of core streaming and caching and access to host memory. Pixar showed off their pixel-matching between GPU and CPU at Siggraph this year, and mentioned that today’s consumer GPUs are big enough to render IIRC ~98% of their scenes without much ‘out-of-core’ tech. Lots of film and VFX studios are using GPUs in production today to render pretty big shots. I think your story is a bit out of date; GPUs being size limited was somewhat true in the past, but is quickly going away. The CPU vs GPU look question has never been true for VFX or film, and was only true in games if you chose different rendering algorithms.
(And I actually do like their sound, but I wouldn't want to be stuck with only tubes)