It depends how fast “fast” is. PCs in the 90s could run games like quake in lower quality mode with lower framerates, but they ran. CPUs that we have now are many orders of magnitude more powerful, so imagine what you can do with that.

Though most games don't bother so we don't really have actual evidence.

Quake used hand-coded assembly for blitting pixels. That could be a bit less efficient when using this engine.

I would expect multi+GHz CPUs hardware to be able to overcome that, though, especially if you’re happy with the tiny (for today) screen resolution of Quake.

Quake also did a few hacks to stay performant (https://en.wikipedia.org/wiki/Quake_engine#Engine_design_and...).

If necessary you would have to do the same for something that uses this library.

I'm not giving this library as an example of very fast code. I mean, it's really cool, but at the moment it doesn't even use SIMD (which dramatically improves performance).

Also, I think handmade hero started with a software renderer. Not sure how far they went with that, but I remember Casey mentioning once that software rendering is viable if you do it right. Certain art styles are easier to do as well — I'm not expecting PBR to be fast, but you could pull off a cel shaded look with simple lighting, and make it look good.

It's also worth mentioning that even with portable APIs like OpenGL, drivers are terrible and porting to other operating systems (and even other GPUs!) can be a chore. Software rendering can be an asset in those cases.

I was thinking about this just yesterday, it would be neat to have a game jam to make something run in dosbox at modern cpu speeds.

Uh, right? The demo page renders fine on this decade old core i5-3337u, with all the vulnerabilities patched.