I love software rendering
jamesfmackenzie.com
jamesfmackenzie.com
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!)
[1] https://github.com/fabiangreffrath/woof/
[2] https://github.com/fabiangreffrath/crispy-doom/ (simpler doom port from which woof inherited its rendering code)
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.
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.
These days you can use different presets to override those choices, and have your 8K, 240Hz Quake look software rasterized, if you want.
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.
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.
I do agree that the author may have missed the fact that they could have overridden texture blending modes via their GPU driver, and gotten a similar graphical look using the hardware renderer. But even that's a little uncertain; there are some other comments in other subthreads that point out that the hardware rendering modes on many of these older games also did other stuff that wasn't feasible with the software renderer, and those other things sometimes can't be tweaked/disabled. So if your goal is "exact same visual style as the software renderer", you might actually have to use the software renderer.
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.)
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!
The author didn't qualify every word he wrote with "of the time" and "typically", possibly because he didn't expect their article to be nitpicked on HN, but a cursory reading shows that's what he meant.
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.
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.
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.
You might think that if you didn't know about the breadth of cassette players, but you'd be wrong on the technical merits, because cassette players existed that did not have those buttons (and also those buttons predate cassette players).
Describing your love of a certain kind of button as a love of things that play cassettes is a misattribution. If you had said "I like the audio cassette players that have those kinds of buttons because those buttons are amazing" you'd have hit the truth encased in the trappings of your nostalgia.
In an case, the author specifically cites the example of Ion Fury, a game which ships with a hardware renderer enabled by default but also uses nearest neighbor interpolation, so the premise that the author isn't aware that the aesthetic isn't possible with hardware rendering is mistaken. He knows. He's calling it software rendering because that's what the aesthetic is historically connected to.
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.
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.
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.
If you would please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
Video: https://www.youtube.com/watch?v=8TvVMzyxACc
Browser(shareware): https://quake-srp.pages.dev/
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
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 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.
(It even had graphic errors, green textures in the faces etc giving everything a very alien look. But that's not what I mean).
Is that the case?
https://fabiensanglard.net/3dfx_sst1/ has a side-by-side screenshot comparison of the two, and software Quake's colours and lighting look way more rich and vibrant; it's not just smoother textures. It's possible that GLQuake/one of the many source ports since has improved on this though.
Of course I know this is a particular quality of GLQuake and not an actual limitation of hardware rendering. And I agree with in general with the contention that this article is talking about a particular art style associated with mid 90s software rasterizers rather than about "software rendering" itself.
This could have been corrected on the art side, by recalibrating the texture maps to the voodoo gamma levels, and that’s why there are great arcade machines from that era with wonderful graphics (designed for the hardware they were running in production), but GLQuake looks all washed out.
DF Retro has good comparison of software Quake, GLQuake and VQuake (for the Rendition Verite).
You can do nearest neighbor in hardware rendering and you can do bilinear in software rendering. Rendering mode and texture sampling are two totally different things.
Yeah you can hack configurations or create your own game to mimic this look.
If you read the post you will see it’s not only about the texture sampling, but also the color depth.
OP picked a good headline. You are fighting for semantics nobody cares about, and picking a more complicated synecdoche.
That said, historically, software rendering meant non-accelerated passes that could be carried out by a cpu at decent enough FPS.
ps: some could also say that a FPU is not software rendering since early x86 didn't have it in the cpu.
The whole process is standardized with GPU rendering, leading to ways of rendering and content authoring that's quite different from how things used to be, and while definitely possible, modern 'retro' games often render like GPU accelerated games and just disable texture filtering, which doesn't quite give you the look.
He mentions Build games, which are not strictly polygonal.
While general purpose computation exists on GPUs, and the standard rasterization pipeline can be implemented in software, graphics cards have pushed people towards a 'look and feel' which comes partly from standardized data structures, content authoring and rendering approaches, that have made games feel samey.
Whereas with software rendering, essentially you have an array of pixels which you can set to a certain color, and the rest is up to you, which made devs come up with unique ways of rendering and authoring content.
The intricate level designs that were made possible with BSP based tools and are basically 'free' to render in software, had hell of a time making the transition to GPUs, as they rely on traversing the tree while drawing pixels, whereas for the GPU, you need to submit a list of triangles (unless you go GPGPU)
There is some standardization in that, if you issue geometry and sample textures normally, you will be relying on hardware units for rasterization and texture sampling, and those do have a relatively limited set of options for how they work. However, those options encompass most if not all of what 3D engines could ever want or need, even the early 3D ones that had all sorts of hacks. The kinds of things GPUs can't actually rasterize in hardware are things like NURBS or metaballs, but this doesn't matter because the industry settled on triangles[0] as the medium of real-time 3D really early on.
A lot of the look of old 3D games comes down to them doing things the lazy way, and I'm proud to say the lazy way is still very much supported - so long as you turn off features that didn't exist later on and limit yourself. I'm not as familiar with old DOS games, so I'll use the PS1 as an example. The "PS1 look" is very much a result of its incredibly limited rasterizer, whose limitations can be trivially emulated in modern hardware:
1. Don't allocate or bind a depth buffer. You will need to Z-sort your geometry every frame. Part of the "PS1 look" is that some games did it wrong; if you do it correctly you'll be burning performance for no visual benefit. Pick a scheme that breaks in a visually interesting way. Likewise make sure to not allocate any multisampling since the PS1 didn't anti-alias either.
2. Restrict the precision of vertices in your vertex shader by rounding them. The PS1 did vertex math with incredibly low precision and it makes vertices wobble.
3. Restrict the precision of UVs in your fragment shader. PS1 UVs were 0-255, so you want 1/256 precision.
4. Aggressively discard geometry that clips the edge of the viewport. The PS1 did not have proper polygon clipping; you just couldn't render off the end of the viewport, so games had to discard geometry and subdivide polygons to avoid things disappearing. This is another "if you do it well, nobody will notice" thing.
5. Turn off perspective-correct attribute interpolation; this will make your UVs warp and distort at certain angles. You do this with the `noperspective` attribute in GLSL.
6. Disable bilinear filtering when sampling textures.
7. Allocate and render to a low-precision color buffer. Lots of games would change the color depth to match the available VRAM. This is probably the hardest aspect to emulate unless you are actively counting VRAM usage and sticking to realistic values.
8. Bitcrush your textures before uploading them. The same reasoning applies here. Also, don't upload any mipmaps.
9. Lighting was done through vertex colors, which were calculated on the CPU. You don't have to limit yourself to CPU lighting but you do have to make sure lighting is done in the vertex shader.
10. Optional: implement the early model PS1 texture banding bug in your fragment shader.
This will give you a rendering pipeline that is good for basically all purposes except bit-accurate PS1 emulation. Of course, if you were doing bit-accurate emulation, nothing stops you from issuing a screen-filling quad and writing a GPU shader that does software rasterization on the GPU. Or launching a compute shader that accesses the framebuffer arbitrarily - although you do have to worry about memory coherency across warps and workgroups. Texture sampling can also be done "in software" if you so wish - i.e. by doing unfiltered reads to the texture which are glorified array lookups, and then filtering those reads as you wish.
[0] There was a brief moment where quads might have been able to win - artists like to work with them, and Nvidia was shipping quad hardware. But the advantage died very quickly, and quads can be easily converted to triangles - not so much the other way around.
There's no single oldschool look, as people writing software renderers didn't have a sanctioned way of doing so - a lot of them weren't even using triangles, or were using a mix of techniques.
You are describing how to make a game look like the PS1 games, but the PS1 actually had a - somewhat flawed, but unique - GPU which kind of forced the limitations you outlined here, and forced a singular way of rendering.
That wasn't really true with Quake or Duke3D or the PC in general. You just drew to the screen with whatever technique you chose, which resulted in a unique look for each game.
In Quake's case, it uses rasterization. Modern GPUs' rasterization pipeline are extremely configurable, not even needing triangles as immediate inputs anymore.
Doesn't Duke3D use the same rendering method as Doom? While there's no specific acceleration for column-based rendering, compute shaders can replicate the same behavior, but in parallel.
Modern GPUs can handle, from raymarched fractals, to raytraced voxels, to rasterized PS1-inspired scenes, etc. It's not like styles are lacking. If anything, GPUs have provided opportunities for more weird combinations by making other techniques viable as well. Contrast that to past, where techniques were cutoff by hardware limitations, resulting in similar ones being used to achieve the same results (both Doom and Duke3d use column-based rendering, for instance).
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
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.
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.
Sound, like a lot of things, could be seen as a peripheral and a lot of peripherals back then needed their own cpu to perform well. One interesting fact I recently learned is the commodore 64 was so resource starved, the external floppy drive you could buy had its own 6502, just like the C64 did as its main processor. It just had to off-load that to another cpu because its own cpu was too busy to reliably run a disk drive. There are other reasons for this like commodore's experience in drives previously was this kind of architecture so they went with what they knew, but its a bit interesting to know your floppy drive was essentially another C64 with its own commodore OS and ram and 6502.
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.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.
> "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.
Since Windows 10 fullscreen mode can use a borderless window, with DWM not compositing if the game covers the entire screen. That's how Alt-Tab switches smoother and faster now.
https://devblogs.microsoft.com/directx/demystifying-full-scr...
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.
Presently, Plan 9 in general lacks 3D graphics but has an in-kernel 2D rendering engine referred to as devdraw. Quake 2 software rendering is done in-engine by rendering full frames to a bitmap displayed by devdraw. A fun experiment was to rcpu into my industrial DIN rail PC, a 1.2 GHz 4 core Atom, from the Thinkpad and play Quake 2. When I run Quake 2, it runs on the CPU server but graphics are sent to my laptop. However, since Q2 is rendered in-engine on the remote iPC, full frames are copied over gigE to my laptop. Q2 full screen was stuttering badly but at about 1/4 screen size it was surprisingly playable.
An other example is a port of cave story done by a 9dront dev where he integrated devdraw so the game renders by loading its assets into devdraw and issuing rendering commands. It is likely the first Plan 9 native game. It plays perfectly over an rcpu session at full screen as the rendering is done by the client side devdraw.
Another 9front dev is doing a lot of graphics work and implemented affine warping in devdraw which is useful for rapidly transforming bitmaps, e.g. scaling the output of the gameboy emulator and Doom. He and others are interested in implementing a concurrent 3D rendering software devdraw engine as we have many-core machines now. When GPU's first hit the streets, we were on single core machines. SMP machines were not affordable by mere mortals when the 3Dfx Voodoo hit the market. So the idea is, why struggle with the gargantuan task of implementing a "modern" GPU stack when you have all these CPU cores now? Why not take a step back, think about what we have learned, and extract all the performance we can from modern many-core CPUs with all sorts of vector extensions. In a Plan 9 context, you could run the game on a many core machine to handle game logic and play remotely with a bigger many-core spraying pixels at a display. Distributed gaming. Might even be able to do multiplayer with a single engine instance with multiple rendering clients attached. Fun system to play with.
[1] https://store.steampowered.com/app/5277420/Omega_Transmissio... [2] https://news.ycombinator.com/item?id=45270981 [3] https://totenarctanz.itch.io/a-scavenging-trip
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.
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...
Edit: my old iPhone SE, fully utilized, can produce the same GFLOPS as the Cray T3E (the one with thousands of DEC Alphas inside). This is our reality.
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
Secondly, I love software rendering too. The nicest rendering I ever made was painters-algorithm sorted and shaded by the z-component. It just looked so simple and lovely.
The original Marathon allowed you to look up and down, but it wasn't actually tilting the camera frame; it was applying a distortion on the field of view and then basically vertical scrolling the render target. Essentially, you can think of it like you were playing the game in vertical phone mode all the time but you were looking at the middle third of that possible output domain, and looking up and down pretty much just scrolled what you were looking at and applied a trapezoid transform.
This is why you couldn't look straight up or straight down, the trapezoid transform would become painfully obvious quickly and the actual algorithm did not really tilt your field of view.
But it was good enough that they could slap it on the box as a novel feature for Wolfenstein style first person shooters.
What's meant by software rendering is really software rasterization - the process of taking the triangles, textures, etc. of the scene and turning those into the pixels that eventually make their way to the screen. You can still do that in software on the CPU today without touching the GPU, even the integrated one. At that point you hand it off to the hardware to make its way to the screen, sure, but it's only an implementation detail that makes that different from handing 0xA0000000 over to the VGA card. The interesting part of the process, and the results, are functionally the same.
I have an Intel i9 with no integrated graphics, if I don't use a GPU, the screen would barely render in very low resolution, although haven't really test it that. I can disable hardware acceleration in the browser and it spikes several CPU cores and is terribly inefficient.
(Then LLMs started taking off and I decided I needed to reskill out of the industry, just in case)
Raycasting (in gaming, some graphics folks just use it as another term for raytracing) means to fire a ray for each column of the screen, identify where it collides with a wall, and use that to determine what to render for that column - it's basically per-column raytracing.
DOOM's engine instead uses a BSP tree so that, from any position, you can determine which walls are on-screen instantly just by walking the tree - the nearer walls appear earlier in the traversal than farther walls. It's still column-based (it tracks whether each column has been drawn and won't draw further walls behind an already drawn column, and stops drawing once all columns are filled), but there's no rays cast.
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.
I've softened on the issue of non-white lights, but I 100% am still full of nostalgia about unflitered low-res textures.
The tech specifics covered have been out of use for decades. But, it's still a very fun read about thinking through the process of optimization.
Unfortunately I didn’t do anything as impressive as modding a game; I read the book because the writing style itself was engaging and gripping like a novel.
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.
Playable in the browser (shareware version): https://quake-srp.pages.dev/
It's a faithful port of Quake's original software renderer. Everything happens on the CPU, which made it easier to match the original exactly. In theory the same could be done on a GPU, but I think it would be harder and messier.
The trade-off with software renderer is that it's more code. With GLQuake much of the actual rendering work is handed off to OpenGL itself, i.e. the driver and the GPU. In the software renderer, the engine does all of that in its own code.
A mix of software and gpu
Nanite is a bit weird because it doesn't use the hardware rasterization of the GPU, but it's still doing rasterization on the GPU, so it doesn't really fit this dichotomy.
(And I actually do like their sound, but I wouldn't want to be stuck with only tubes)
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.
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.
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.