VOGONS

Common searches


First post, by Jo22

User metadata
Rank l33t++
Rank
l33t++

Hi everyone,

Just found another interesting article/blog thing.

https://read.cash/@Geri/software-rendering-is … opengl-6f902fdb

I think that's an interesting read.
It's refreshing to see another, unconventional point of view here.

Best regards,
Jo22

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 1 of 3, by 386SX

User metadata
Rank l33t
Rank
l33t

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.

Reply 2 of 3, by Dolenc

User metadata
Rank Member
Rank
Member

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.

Reply 3 of 3, by Namrok

User metadata
Rank Member
Rank
Member

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.

Win95/DOS 7.1 - P233 MMX (@2.5 x 100 FSB), Diamond Viper V330 AGP, SB16 CT2800
Win98 - K6-2+ 500, GF2 MX, SB AWE 64 CT4500, SBLive CT4780
Win98 - Pentium III 1000, GF2 GTS, SBLive CT4760
WinXP - Athlon 64 3200+, GF 7800 GS, Audigy 2 ZS