James Mackenzie’s case for software rendering is about preserving a visual language, not rejecting faster hardware. Original DOS renderers on newer machines offer a third option beyond low-resolution software and hardware-accelerated ports: the original look at resolutions its contemporary hardware struggled to deliver.
The implementation choices are visible in the result:
- Pixel-by-pixel texture sampling preserves crisp texels rather than the softer look of early hardware bilinear filtering.
- Palette lookup tables produce stepped lighting and colour banding. What looks like a technical limitation also supplies the gritty atmosphere.
- Games designed around those renderers can look different when acceleration changes texture filtering and lighting.
- More pixels still mean more CPU work. Mackenzie reports Quake holding 60fps at 800×600 on his OptiPlex 380, but cites high-resolution Build engine games that remain demanding on much faster machines.
He avoids making this a universal rule: Tomb Raider’s underwater scenes look better accelerated to him. Native DOS is his preservation preference, not a requirement for software rendering; modern source ports provide another route, while original binaries bring compatibility and sound-card constraints.
The engineering takeaway is an interpretation rather than a benchmark claim: replacing a backend can change observable behaviour even when the replacement is faster. Decide which output characteristics matter before treating a renderer upgrade as an unqualified improvement.