Advanced shader topics - Feature Request

[Steve5563]

Hi, I have been developing a shader pack called "Doom Liquid textures pack" that anyone can use in their own levels, and i have been working on adding a flow map texture feature to make the liquids flow in the direction based on the flow map texture color values for the next version update.
The flow map textures are designed and placed in the level by the user and then the shader works on the texture to perform calculations to the give desired result when in game.

The shader has the ability to use a selected range of flow map texture scales in relation to map geometry size.
This is useful to keep the flow map texture dimensions down to a reasonable size when making flow maps to cover large map area's to keep the vram usage down to a minimum, the problem is the effect is now very pixelated when looking up close.

One way to fix this is to use the GZDoom linear texture feature, this feature smooths everything out extremely nice when using low resolution textures, however not everyone likes to use texture filtering when playing doom.
I have tried adding a simple texture filter to the flow map shader that works well when the GZDoom linear texture filter is turned "OFF" but when the GZDoom linear texture filter is turned "ON" this now fights with the GZDoom linear texture filter,
and it basically inverts the texture filter effect to show the standard pixelation due to using a low resolution flow map texture.

GZDoom Linear texture filter "OFF" with flow map shader filtering active.


GZDoom Linear texture filter "ON" with flow map shader filtering active.


Currently the material shaders in GZDoom do not seem to have the ability to access CVAR menu info...

The feature request i am asking for to help resolve this issue when using a Material fragment shader is...
1: Have the ability in GLDEFS to define a Specific GZDoom texture filter to "Always" be used on all of the textures that the shader itself uses when being defined. [wiki]https://zdoom.org/wiki/GLDEFS#Materials[/wiki]
Or
2: Make the shader have access to the "int" value that reflects the texture filter mode that is being used by GZDoom.
[wiki]https://zdoom.org/wiki/CVARs:Display#gl_texture_filter[/wiki] - A way to pass the "int" CVAR values to GLDEFS that the shader can use?
[wiki]https://zdoom.org/wiki/GLDEFS#Advanced_shader_topics[/wiki] - Add a "int texturefiltermode" that the shader can use to find out what texture filter GZDoom is using?
I have tried using the "int texturemode" that is shown in the wiki but with no success, i think that might referring to a different texture mode and has no relation to the texture filtering mode that i am seeking.

This would be a good feature to have when wanting to use very low resolution textures in shaders for smooth masking, blending, making color transitions, normal map distortion effects, etc...
By having this feature for particular uses, it will keep the vram usage down and actually improve performance due to having less texels to calculate for almost the same visual quality.

A few extra screenshot's of the flow maps.

---

[Rachael]

Transmitting cvars to shaders would require them to be specifically defined as uniforms. It is currently not possible to transmit the entire cvarlist to shaders as uniforms - the uniform buffer would overflow too quickly and if I remember what I've been told correctly, it's too big already as it is - and if such a thing were implemented it would be with uniform sets like with the current post-process shaders.

[Graf Zahl]

No chance until we have excised the legacy rendering stuff. And knowing the resistance of these users to upgrade it doesn't look good.

[Darkcrafter]

Here is the blazing difference between Quake and Doom communities, when Ironwail came out which is GL4.4 only engine, even dumptrack_ds (a really experience modder) recommended it, because it's super fast. Does it really cost a fortune to get a GL4 compliant video adapter these days? What the fuck those intel and amd cocksuckers are doing when not implementing GL4.4 at least whereas it's 10 years old already? GL4.6 is 2017, kind of understandable that it does take a while to get to it. But GL3.3 support, this one is 2010. All of them support DirectX quite well, why not port GZDoom to DirectX instead, doesn't Linux work with DX via wine?

[phantombeta]

What the fuck those intel and amd cocksuckers are doing when not implementing GL4.4 at least whereas it's 10 years old already? GL4.6 is 2017, kind of understandable that it does take a while to get to it. But GL3.3 support, this one is 2010.

You're making a bogus assumption here. All the Intel and AMD GPUs that DON'T support GL4.4 and up are GPUs that either can't support it, or don't get driver updates anymore. No one's making new desktop and laptop GPUs without Vulkan support, much less without OpenGL 4.5 support. Doom just gets a lot of users with old hardware. (particularly from places like South America, where desktop GPUs that aren't old cost absurd amounts of money)

[Steve5563]

Transmitting cvars to shaders would require them to be specifically defined as uniforms. It is currently not possible to transmit the entire cvarlist to shaders as uniforms - the uniform buffer would overflow too quickly and if I remember what I've been told correctly, it's too big already as it is - and if such a thing were implemented it would be with uniform sets like with the current post-process shaders.

Ok thanks for the explanation, any method would do the trick, as long as the shader can obtain a number value that describes what texture filter is being used so i can make the flow map shader skip the texture filter process if GZDoom is already using the Linear texture filter.
i did see your post on a post process shader using the uniform values, was hoping that could be duplicated for the material shaders.

No chance until we have excised the legacy rendering stuff. And knowing the resistance of these users to upgrade it doesn't look good.

"GZDoom Gold Edition" - To suit modern hardware and not be held back by old methods?

[Graf Zahl]

Here is the blazing difference between Quake and Doom communities, when Ironwail came out which is GL4.4 only engine, even dumptrack_ds (a really experience modder) recommended it, because it's super fast. Does it really cost a fortune to get a GL4 compliant video adapter these days? What the fuck those intel and amd cocksuckers are doing when not implementing GL4.4 at least whereas it's 10 years old already? GL4.6 is 2017, kind of understandable that it does take a while to get to it. But GL3.3 support, this one is 2010. All of them support DirectX quite well, why not port GZDoom to DirectX instead, doesn't Linux work with DX via wine?

A bit late, but I only yesterday read that one port's developer proudly proclaimed that their port still supports OpenGL 1.5!
This is an iteration that was dropped by NVidia and AMD almost 20 years ago and even by intel almost 15 years ago.
And if you look at the other ports, they all stick to ancient OpenGL versions "because compatibility matters!"

The irony here is, there is very, very little hardware still in use that supports OpenGL 4.6 but no Vulkan. The vast majority of GL-only systems are 10+ year old craptops from the bottom of the barrel, i.e. systems entirely unsuitable for gaming with weak CPUs and even weaker GPUs, and even with Doom not capable of handling more than vanilla complexity.
The takeaway here is, that standalone graphics cards from pre-Vulkan times, i.e. before 2013 have mostly vanished from use entirely. What remains is non-upgradeable laptops, and even here it's not the good ones but mainly the cheap ones that get used way beyond their expiration date.

I think this paints a very good picture why I consider it a waste of time to invest any more time in OpenGL support. I'll keep a legacy version with the GLES backend around for token support but it won't see any active development anymore aside from getting non-render features cherry-picked, but even so the expiration date of this is close. This will be strictly a no-work-invested undertaking and once that's no longer possible, be stopped.

[Darkcrafter]

I think that providing support to the ancient hardware is not just about statistics, it's like a hobby and accepting challenges. Thanks to fdoom port it might run much faster on 386 systems now, making the game playable on really highly rare PCs, that proud owners will show off, now with Doom on their highly collectible potatos. There is simply no limits to the way on achieving perfect. DSDA-Doom can now provide you with the same gameplay over a huge variety of systems, thanks to support of ancient GLs. That way I won't get surprised if someone some day ported modern GZDoom to DOS, GL1 or DX, for a mere fun.

[Major Cooke]

Meanwhile GZDoom is working to get some amazing new features that's hinted at in the changelogs to usher it closer to modern engines that I'm very much in favor of.

[Professor Hastig]

I think that providing support to the ancient hardware is not just about statistics, it's like a hobby and accepting challenges.

That it is indeed. Which clearly separates projects into two categories, on the one hand you get the tinkerers that try to make the impossible work on old hardware, on the other you got projects being aimed at being used in realistic environments, i.e. all mainstream and quasi-mainstream ports out there.

The problems surface when maintainers of the second type of project desperately try to be as backwards compatible as they can be, and that will always be a very double edged sword because the hardware they target is too different. In extreme cases this can make 99% of the user base suffer just to hold on to that last final percent or less.

I think we are there with lots of the simpler ports, they do not feel like a port of Doom to modern times, they often feel like a relic from the past being maintained just enough to work on current hardware without ever taking into account that not only hardware but also user expectations have changed over that time. The same is often true for ports of other old games as well.

Thanks to fdoom port it might run much faster on 386 systems now, making the game playable on really highly rare PCs, that proud owners will show off, now with Doom on their highly collectible potatos.

Yes, but that's clearly not a mainstream project so it doesn't really matter.

There is simply no limits to the way on achieving perfect. DSDA-Doom can now provide you with the same gameplay over a huge variety of systems, thanks to support of ancient GLs. That way I won't get surprised if someone some day ported modern GZDoom to DOS, GL1 or DX, for a mere fun.

And here's where the problems start. DSDA also has recently demodernized its renderer and true to your statement it went the route of the lowest common denominator here, the entire setup is at a point where it is actually slower on my high end system than GZDoom while only providing sub-par visuals. I've stopped using the port altogether by now because it got nothing to offer to me anymore. And that lauded backwards compatibility you seem to hold in such high regard means it won't be able to dig itself out of that hole anymore.
The issue here that has been repeated ad nauseum by Graf and others is that support for old hardware is not free - you always have to compromise and at some point the question to ask is, is it worth it to sacrifice better support for hardware as it exists right now for a small number of people on hopelessly outdated hardware which cannot even run the game well?