2 ms·

Software rendering was fast enough for games in the 90s. On machines featuring a few megabytes of RAM and CPU clock speeds measured in tens of, or at most a co

by clarry 12y ago

Software rendering was fast enough for games in the 90s. On machines featuring a few megabytes of RAM and CPU clock speeds measured in tens of, or at most a couple hundred MHz. Now even the cheapest and lousiest PC hardware is orders of magnitude faster than back then. Why wouldn't software rendering be fast enough now that it is orders of magnitude faster than when it was fast enough? The benefit is that it is more reliable. If you can shove pixels on to the screen, you can do graphics in software. The graphics stack for hardware accelerated 3D graphics is incredibly complex and buggy. Questions like if I buy this laptop, will my graphics work? are sad sad reality. Problems like libGL error: failed to load driver: i915 are reality. And for those who write graphics code, doing workarounds for specific chipsets or drivers is reality.

moonchrome 12y ago
>Why wouldn't software rendering be fast enough now that it is orders of magnitude faster than when it was fast enough? Because games in the 90s used < 1k poly models for characters, I don't think you could get away with those nowdays, not even on mobile.
- fulafel 12y ago
  Unreal Tournament 2004 had a software renderer with good performance, on the single core CPUs of the era. See http://www.drdobbs.com/architecture-and-design/optimizing-pixomatic-for-x86-processors/184405765 http://www.drdobbs.com/architecture-and-design/optimizing-pi... The people working on that, Abrash and Sartain, went on to Intel to do Larrabee - something akin to "software renderer on GPU". If that had worked out, maybe we wouldn't be in the current dark ages, where GPUs are a nightmare to program and everybody suffers from the buggy, closed proprietary software stacks that hide the hardware behind many layers of obfuscation.
zanny 12y ago
It wasn't that software rendering was "fast enough", it was that we didn't have hardware acceleration, so game developers had to use what they could get away with. There is a reason than every console since the PS1 has a rendering coprocessor. And why all your phones have them, and why every CPU vendor is shipping APUs now. Yea, you could make a significantly better looking software rendered quake today with 10x the triangles and texture resolution. But that game would still run 1000x faster on a GPU priced the same as the cpu doing the software rendering.

by clarry 12y ago

moonchrome 12y ago

>Why wouldn't software rendering be fast enough now that it is orders of magnitude faster than when it was fast enough? Because games in the 90s used < 1k poly models for characters, I don't think you could get away with those nowdays, not even on mobile.

fulafel 12y ago
Unreal Tournament 2004 had a software renderer with good performance, on the single core CPUs of the era. See http://www.drdobbs.com/architecture-and-design/optimizing-pixomatic-for-x86-processors/184405765 http://www.drdobbs.com/architecture-and-design/optimizing-pi... The people working on that, Abrash and Sartain, went on to Intel to do Larrabee - something akin to "software renderer on GPU". If that had worked out, maybe we wouldn't be in the current dark ages, where GPUs are a nightmare to program and everybody suffers from the buggy, closed proprietary software stacks that hide the hardware behind many layers of obfuscation.

zanny 12y ago

It wasn't that software rendering was "fast enough", it was that we didn't have hardware acceleration, so game developers had to use what they could get away with. There is a reason than every console since the PS1 has a rendering coprocessor. And why all your phones have them, and why every CPU vendor is shipping APUs now. Yea, you could make a significantly better looking software rendered quake today with 10x the triangles and texture resolution. But that game would still run 1000x faster on a GPU priced the same as the cpu doing the software rendering.