If I understood the article point is interesting but I think the logic of going for the self made simple 3D game engine might be difficult in a modern complex realistic global illuminated game with millions of triangles/textures/AI/etc.. and all sort of effects and running on few code lines. I don't know if the code lines number might be the main problem these days but I imagine games are so complex that developers has less problems going for a ready game engine instead of writing a simpler own optimized one for that specific game.

Imho a part of the problem is when the hw acceleration should be needed and when not beside games. 3D acceleration nowdays if we can still call it "3D acceleration" seems to be an heavy requirement for the o.s. GUI itself to have ultra fast but also heavy GUIs which seems not really needed when a functional GUI was accelerated on Win 3.1 / 95 with those old 2D BitBLT accelerated chips. I understand many things that run nowdays on the o.s. like the web browser need 3D acceleration to render parts of the page and in the case it's missing it will use a real 3D sw renderer instead of the old style 2D native acceleration to scroll a 2D text webpage. OpenGL required to render a webpage using a Directx to wrapper with drivers workaround to OpenGL ES in a desktop enviroment even to read an newspaper text article on a background empty webpage.

So the GPU has to do much more than it was supposed to and imho this since smartphones needed to accelerate their touchscreens GUI speed/latency, OpenGL ES games, browser page scrolling because the early portable CPUs could not do much. Desktop o.s. gpu usage followed the same road and imho the sw designs/concepts evolved around that too. And at the end with all that old "generic accelerator" concept, we still have video decoding/encoding GPU stricly fixed to a single tech/codec without possibility to use all those free GPU units to offload at least a part of a newer codec decoding or encoding. Like it was in the 90s. Tomorrow a new codec is released and the GPU still can't do much for it.

Well daily dose of dumb quota just got filled reading that article.

The reality of gamedev is, the gamer, doesnt care, how you develop your game. As it should be.

No one cares what api is used, if you used a for loop instead of for each. You can look at those things, but at that point something was done right. Quake1 might have been a technical showcase, but its not anymore and people still play it. While it helped, theres still a good game underneath the tech.

If a game sucks, how you use your hardware will be last on the list of complaints. Khm Godfall khm..

A game was always "a vision" of a world, story, mehanics... An idea. How you realise it, no one could give 2 shits about, how well you realise that vision, thats what matters.

And yea software rendering has a place, even new build engine games are made and lots of pixelart games, filtered games that still look pixelated, but thats nothing to do with what technical approach is better, its more of a design decision and thats what matters.

Well, I found it interesting. And I can see the wisdom of using software rendering if you are an indie dev, and want to target the broadest possible set of hardware platforms, and want the C compiler to do all the heavy lifting of making sure basic math works on all the different CPU architectures. It's a more man-hour efficient way to go than supporting a half dozen different APIs, with quirks across a half dozen hardware manufacturers. And for a game of your average indie-game's production values, I doubt many people will notice the difference.

Obviously it's totally unworkable if you are trying to make a really high performance and visually impressive game.

Then again, I haven't gotten off into the weeds on it yet, but I also suspect the issues across hardware vendors are being oversold. I would hope there is some subset of safe API calls and arguments that are well known to have the highest compatibility across the most vendors. The author seems like the type to be off doing his own thing, ignorant of this common insider knowledge.