Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Shameless plug of my upcoming game [1] which uses software rendering. Also did a Show HN and write-up [2] last year for a previous game [3] using the same engine.
[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
by mvx64 - This should really be titled "I love pixelated textures".
> "3D cards smoothed textures with bilinear filtering"
You can just not do that.
- I recently got to try out Quake 2 on 9front, a Plan 9 fork, which ran surprisingly fast on my very, very modest Thinkpad T410i with a 2.4 GHz dual core i3 at 1440x900. Plan 9 has no GPU support so all rendering is software. Even had a little lan party with other devs. I really enjoyed the software rendering, it bought back early memories of playing Q2 before we bought our Voodoo2. I even used my ploopy trackball to play. Fun times.
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.
by MisterTea - Ah the software rendering era. Where I gained 10fps by adding a sound card.by Waterluvian
- 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.by 0x0203
- 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.
- 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.
by bob1029 - I really admire Woof[1] sourceport of DOOM and how it can achieve high fps at modern resolutions using software rendering (Sure, there are still GPU apis at work behind the scenes managing swapchain and all but rendering logic is still software). Also it's worth checking out for anybody who wants to see a good SDL3 codebase.
[1] https://github.com/fabiangreffrath/woof/
[2] https://github.com/fabiangreffrath/crispy-doom/ (simpler doom port from which woof inherited its rendering code)
by jiffygist