GZDoom on GL 3.x core profile

[Rachael]

It's not an easy situation for anyone involved.

But at the same time, a system that will run OpenGL 3 is not that expensive.

You could literally walk to your local discount retailer (usually Walmart in the U.S. or some electronics store in other countries) and probably get a GPU or a system that will run OpenGL 3 cheaper than what it would cost for you to buy a brand new game.

Yeah, it sucks when your card isn't supported anymore. But the world won't stop for your computer alone.

[Graf Zahl]

The thing is, these people often say they do not have the money to upgrade. But what they never consider is the amount of extra work they burden the developers with, and in some cases the total lack of understanding that their hardware is obsolete and moved to legacy support. Right now it is still manageable but I already trimmed down the fullscreen colormap feature (the monochrome/inverse colormap effect) because the only way to do it without shaders is to use a different set of textures. And this is just way too much added code to be reasonable. And rest assured, at some point other things will also be removed - right now the biggest chunk of code that's only there for old hardware is the texture based dynamic lights - and considering how weak GL 2.x hardware is by today's standards; I still have an old computer from 2004 with a Geforce 6800 lying around, performance wise that's probably even better than most of Intel's integrated shit, and you can barely run any demanding map with lights enabled, stuff like KDiZD even becomes slow without it. My favorite test case had been Phobos: Anomaly Reborn's M6's starting cave. This was already choppy without lights, but with lights.pk3 loaded frame rates drop below 20 fps. So essentially we are talking about hardware that's barely good enough to play vanilla levels with no performance hungry add-ons.

It should be clear that under these circumstances I consider keeping features supported in the legacy path very low priority. If something gets in the way of modern stuff it will be removed.
As I said, the biggest problem case is the lights, the one most likely to removed next is warped textures - that has very little chance of surviving the upcoming refactoring of the texture management code (which will happen after the next release.)

What I find interesting is that so many other ports are fixated on this old hardware - sometimes even down to GL 1.4 "because there's some users still depending on it", essentially keeping themselves away from properly supporting modern hardware. AFAIK GZDoom is the only port that has made the transition to core profile so far.

That said, to make an informed decision I'd need some actual data being collected on end-users' machines to see how many are really still using this old stuff.

[dpJudas]

The fact that gzdoom was based on 3.x was actually one of the reasons I started adding the things I've working on. Supporting very old hardware might retain certain users, but at the same time you'll get the problem that it is very hard to get developers to contribute. Any developer remotely interested in 3D graphics does NOT want to hear the words fixed function pipeline.

[Graf Zahl]

Heh...

Well, to be honest, in 11 years you have been the only one who came forward. Which I found mildly disappointing. This stuff is no fun if you do not have someone to discuss ideas with.

And now that it's done, I am really glad that for 3.x I no longer need the compatibility profile. This makes it a lot easier when the time comes to finally dump the legacy code, even though I already encapsulated most of it away into a single file. The main reason I brought it back wasn't even the old Intel hardware but to discard the 1.x branch for macOS support.

[Edward-san]

I would like to do some benchmarks between the old way and the new way, but the 'bench' command works only on windows. If it could be there a way to make it work on linux (and macos, I guess?)....

[Graf Zahl]

What it needs is to calculate the time period the rdtsc command measures. For that you have to adjust gl_CalculateClockSpeed to how these systems measure time.

[dpJudas]

Well, to be honest, in 11 years you have been the only one who came forward. Which I found mildly disappointing. This stuff is no fun if you do not have someone to discuss ideas with.

I think that's partly due to gzdoom mostly been active in what I like to call the OpenGL dark ages. It only recently that coding up against OpenGL hasn't been really uphill due to Intel, buggy drivers, and people only having usable GPUs if they explicitly went for them. That is about to change as fewer and fewer people have hardware from that era.

And now that it's done, I am really glad that for 3.x I no longer need the compatibility profile. This makes it a lot easier when the time comes to finally dump the legacy code, even though I already encapsulated most of it away into a single file. The main reason I brought it back wasn't even the old Intel hardware but to discard the 1.x branch for macOS support.

It is an important milestone for sure. The post processing part might get all the attention, but this part will help pave the way for the future just as much.

[ibm5155]

Those people can stick with older gzdoom builds (because why not), They aren't going to miss anything, those hardwares may not even handle The new mods :S...
I still remember my two cases:
one was my experimental run, trying to run gzdoom on a Pentium mmx or a k6-III+ with a voodoo 3, after a long time trying, I did it, but man, 20 - 10fps in e1m1 with 640x480 res, imagine any other mod more complex than doom xD.
The other case was a Pentium 3 1Ghz with a radeon 7200, somehow, I used it for freakin 10 years (mostly playing skulltag), and even then, many new mods were unplayable to the point that I was forced to switch to the software render...

Doing a resume:
-Many mods are stull functional under older gzdoom releases so there isn't a huge miss here.
-If your hardware is too old and you still want to play those special cases, zdoom is there for that.
-don't do like me and try to run gzdoom in older notebooks, you'll fry it because 100% of they weren't designed to run at 100% cpu/gpu usage all the time. (and I did it two times )
-even a usb stick computer can handle the latest gzdoom build.

[Graf Zahl]

I mostly agree, but right now there's really no need to remove the code. Once things like multithreaded processing of the render data get added, these old systems may have to be dropped but the next release will still be OpenGL 2.x compatible.

[Rachael]

-even a usb stick computer can handle the latest gzdoom build.

That made me chuckle a bit.

Which is why I said what I said before.

I know it sucks to have to give up support for legacy hardware - but it's needed. I am going to be very sad when I can no longer run the latest GZDoom builds on my AMD GPU, but it's too old, anyway. That computer is only good for file/CPU-related stuff at this point, anyway, and also as a wifi/network monitor. Funny to think only two years ago it was my main gaming system.

Now I have a laptop that has extreme overheating issues, but that's okay because I can run things in lower settings and they still work.

[Graf Zahl]

Isn't your AMD still GL 3 capable? If I remember correctly, it's only the clip planes that are non-functional, but aside from that everything should work. So it may glitch a bit with sprite splitting and some reflective floors but basically it should work.

[Rachael]

Yes, it is. Without clipping planes it has no issues. I could test the latest GZDoom build on it if you like, since I just pulled from the master not 30 minutes ago - right after you comitted the xbrz files. It's doing a clean build, right now, over RDP.

[Rachael]

Tested it on the AMD. Everything seems fine until clipping planes are activated. When I load Tormentor667's Sapphire and warp to -1824, 1824 the screen goes black. It's running under the Core profile and, if relevant, the tonemap shader does work prior to testing out this trouble spot.

That's using the build I made for this post: http://forum.zdoom.org/viewtopic.php?f= ... 82#p937282 - which is 2.2pre-2130-g3ae2e77.

[Graf Zahl]

That's precisely what I expected. The clip planes are the only thing that appears to be broken in that driver - too bad that it's so badly broken that it nearly brings everything down...

[Rachael]

Are there any CVars available to disable any code that accesses clipping planes? At least as far as sector reflection goes - I really think that effect is purely optional.