What's up for GZDoom after running the survey?

[RockstarRaccoon]

Honestly, I'm impressed that people are still running Hardware that is old enough that it doesn't support opengl 3.0, seeing as that hardware has to be over a decade old.

What I'd really like to see is GZDoom externalize the renderers into .dll files (or .so for non-Windows platforms) like Quake 2 did.

If you did this, Membrane would ship with a stripped down version of the render, because some of the optional features (like lighting levels) break the game.

[Graf Zahl]

What I'd really like to see is GZDoom externalize the renderers into .dll files (or .so for non-Windows platforms) like Quake 2 did. Then all that's required is maintaining the renderers separately, they can be cut from the main executable and anyone who wants to maintain legacy renderers may do so.

That won't work because the renderer runs off the same data as the game itself. Change one thing and the DLL becomes invalid. Add access functions to counter this and you'll lose a lot of performance. THis would need quite a bit more of refactoring than what I did.

[Graf Zahl]

Honestly, I'm impressed that people are still running Hardware that is old enough that it doesn't support opengl 3.0, seeing as that hardware has to be over a decade old.

These are 5-8 year old laptops mostly which came with bottom-of-the-barrel Intel chipsets. The game most likely runs like shit on them anyway.

[Rachael]

That won't work because the renderer runs off the same data as the game itself. Change one thing and the DLL becomes invalid. Add access functions to counter this and you'll lose a lot of performance. THis would need quite a bit more of refactoring than what I did.

I think a lot of that can be solved by returning data pointers, instead, and having the .dll file cache them during initialization so that it does not need to call the functions later on. It can then access the data using its own internal pointer system, instead, which should be more resistant to change.

[RockstarRaccoon]

I think he might be referring to stuff like the interpolation code, which I can imagine relying on some very specific internal variables. It should still be doable, because every game I've ever written has had Graphics running on a separate thread as a completely separate module from the rest of the code, but with all the Legacy support stuff, I can understand if it's more trouble than usual.

Still a bit entertained with the idea that there are people trying to run this on such obsolete Hardware, but then again, it's one of those games that I expect to run on weird things, and I guess as a developer, I would prefer that it can be run on strange equipment like that.

[_mental_]

Still a bit entertained with the idea that there are people trying to run this on such obsolete Hardware, but then again, it's one of those games that I expect to run on weird things, and I guess as a developer, I would prefer that it can be run on strange equipment like that.

GZDoom is for modern PCs and OSes. If it still runs on something old and abandoned, that’s fine.
But do not expect any significant development in attempt to support deprecated technologies.
There are source ports for that. Even Choco is limited by minimal requirements of SDL2.

[Graf Zahl]

but then again, it's one of those games that I expect to run on weird things, and I guess as a developer, I would prefer that it can be run on strange equipment like that.

That's precisely the issue here. Some people never realize that an engine with loads of modern-ish hardware rendering effects cannot run well on old hardware and that eventually the time comes where a decision has to be made between backwards compatibility and better features.

Let's be serious here: If it wasn't for Intel completely missing hardware trends 10 years ago we wouldn't face this problem. But due to their crappy 3D hardware a lot of cheap-ass laptops were dumped into the market with graphical capabilities that don't even match a real vintage-GL2 system from 13 years ago. I once had the fun of running GZDoom on an older Mac with an Intel HD3000 and calling the performance "bad" would be a major understatement - but the hardware we are talking about here is even worse and will already start to choke on medium sized Boom maps without any advanced features being enabled.

I may get my hands at that system over the summer again and then will do some very thorough performance tests, and depending on those decide whether to keep GL2 support or not. In all seriousness, I do not really think that many people will lose out if it got removed because all things considered, their systems are far too weak to run new mods anyway.

[Kinsie]

I once had the fun of running GZDoom on an older Mac with an Intel HD3000 and calling the performance "bad" would be a major understatement

Apple's OpenGL drivers would make that problem even worse, no?

[Graf Zahl]

That may well be. According to some benchmark sites the HD3000 would be equal to a lowest end GL3 card from 10 years ago - but I never got the same kind of performance out of it. Its main problem on Windows is that Intel refuses to release full GL 3.3 drivers for it and as a result this cannot be used with all features. It's the same problem as with Intel GMA, only one generation aheacd. Those could support GL 2.x but the driver is stuck with GL 1.5. In both cases the lack of adequate driver renders the hardware essentially obsolete, although it'd be capable enough.

[drfrag]

I may get my hands at that system over the summer again and then will do some very thorough performance tests, and depending on those decide whether to keep GL2 support or not. In all seriousness, I do not really think that many people will lose out if it got removed because all things considered, their systems are far too weak to run new mods anyway.

I'm on an Intel Graphics Media Accelerator (GMA) 4500M and could do some testing so no need to wait.

Also i'm planning to do a legacy release (even for non SSE2 cpus) based on the g3.3mgw branch and you can expect some maintenance there (Rachael proposed adding MinGW builds to the archive at some point). I forked before the 2D refactor (but it's not a proper fork at least not yet, this time i'd do only minimal modifications). Even an official release from there if the refactor get messy and some important bug is found wouldn't be a crazy idea.

[Graf Zahl]

So, how many legacy releases do we really need?
More importantly, if all eventualities are being covered by legacy releases, does it make any sense to keep that pain-in-the-ass code in the main project any longer? At some point this becomes uneconomical, so what feature set should we support through which release?

I think we should have a clear roadmap here so that this doesn't get presented as a mess of different but for the layman indecipherable options to the end user. Furthermore, there should be a clear and justifiable reason for each single version. "Because we can" is not enough, if you ask me.

[Kinsie]

A roadmap for the renderer's next steps is a great idea. Engine development's had issues with lack of planning or communication between devs in the past, so improvements to that side of things are always welcome.

[Graf Zahl]

That's a lot harder to map out, because it depends a lot on personal motivation ands technical feasibility.
For me the main problem is that drfrag already maintains multiple legacy builds and we really need to get an idea what exists, what it is there for and whether it covers a segment adequately enough so that the main release does not need to be burdened with it any longer.

[drfrag]

Sorry i meant i'm going to do some maintenance in that legacy branch, so if something goes wrong it would be still possible to do a release from there saving the devs some work.
I don't want to be the guy responsible for the GL2 hardware path removal, that said...
As long as the software renderers can run on GL2 is that much of a problem? If that code is such a pain-in-the-ass may be it would be a good idea to remove it ASAP since the percentage of users will decrease in the next few months.

Now i plan to do some maintenance there porting all the stuff i can so whether keeping the old code in the main release is worth or not is something that could be discussed. This would be a release for non SSE2 cpus and XP but also would include a SSE2 executable (possibly even VS).

On the other projects they are old now and i think i'm going to discontinue them.
ZDoom LE is an incredibly long maintenance branch of the old ZDoom 2.8 codebase, mostly has bugfixes and a few conservative features (and the security fixes). Merged with an old GL renderer (1.8.4x) for GL 1.x hardware. Runs on win98.
ZDoom32 is a more modern ZDoom (classic software renderer with ASM and fmod) merged with the old dpJudas 32 bit renderer, this one runs very well on old hardware. Also an old optional GL renderer (1.9.1x). This one is from DEC 2016 before the zscript merge. Also with many later fixes and some conservative features.
So these are old versions mainly for old hardware but i still think they are cool.

So i really don't know what would be better and less troublesome, a separate legacy branch or keeping the old code in.

[Graf Zahl]

For now there's no need to change it. This will become more urgent once Vulkan becomes a thing. That may require some refactoring that's just incompatible with GL2. But before doing that I'll run another survey.