"Default" HardwareShader

Remember, just because you request it, that doesn't mean you'll get it.

Moderator: GZDoom Developers

"Default" HardwareShader

Postby TehRealSalt » Sat Jul 24, 2021 3:32 pm

I want to make my own lighting shader. I already wrote one and I love how it looks.
However the only way I could get it to work is by doing this:

Code: Select allExpand view
HardwareShader Texture DESBR
{
   Shader "shaders/lighting.fp"
}

HardwareShader Texture DESBR2
{
   Shader "shaders/lighting.fp"
}

HardwareShader Texture DESDOOR
{
   Shader "shaders/lighting.fp"
}

HardwareShader Texture DESDOOR2
{
   Shader "shaders/lighting.fp"
}

HardwareShader Texture DESEDGE
{
   Shader "shaders/lighting.fp"
}

HardwareShader Texture DESGRASS
{
   Shader "shaders/lighting.fp"
}

[ad infinitum]


With the current set-up, I would need to copy-paste this shader definition 479 times (and I didn't even count my sprites that would also need it, and this number will inevitably get bigger since it is an in-progress TC). That would be an incredibly obnoxious hell file.

I am hoping to instead just do something like omitting the texture name to make a shader apply to all of that type:

Code: Select allExpand view
HardwareShader Sprite
{
   Shader "shaders/snaplighting.fp"
}


Or, better yet, a way to make a shader apply to all Texture/Flat/Sprites with a different keyword:

Code: Select allExpand view
HardwareShader Default
{
   Shader "shaders/snaplighting.fp"
}


If another shader is defined for a specific texture name, then that would take priority over using the default shader.

(There could very well be something I'm missing, but I tried many things, searched on the forum, looked at the source code... and the one example I came across of a lighting shader like I would like to do was done in the exact way I would like to avoid doing. So I'm pretty sure there doesn't exist a way to do this, but I'd love to be wrong)
User avatar
TehRealSalt
ヽ(◕ᴥ◕)ノ
 
Joined: 03 Apr 2014
Discord: TehRealSalt#6754
Github ID: TehRealSalt
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia (Modern GZDoom)

Re: "Default" HardwareShader

Postby Nash » Sat Jul 24, 2021 10:52 pm

Maybe some kind of system that exposes the necessary data out of main.fp can be provided for mods, but at any rate, this doesn't seem easy to implement...
User avatar
Nash
AKA Nash Muhandes! Twitter/Facebook/Youtube: nashmuhandes
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Twitch ID: nashmuhandes
Github ID: nashmuhandes

Re: "Default" HardwareShader

Postby Graf Zahl » Sun Jul 25, 2021 12:17 am

There's something else, too. The 2D code uses the same fragment shaders as the 3D code, and these are bound to textures, so a bad shader can easily break the entire engine.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: "Default" HardwareShader

Postby Rachael » Sun Jul 25, 2021 4:42 am

How will a bad shader mess up the engine? What can you do in 2D shaders that you can't do in 3D shaders that would disable safety features like alt-f4?
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Debian-like Linux (Debian, Ubuntu, Mint, etc) 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: "Default" HardwareShader

Postby dpJudas » Sun Jul 25, 2021 7:45 am

If the shader applies to everything and you get a black screen or something like that there's a fair chance people would think it was GZDoom that crashed and not link it to the mod. Of course one could make the argument that this applies to any sufficiently advanced mod.
dpJudas
 
 
 
Joined: 28 May 2016

Re: "Default" HardwareShader

Postby Graf Zahl » Sun Jul 25, 2021 9:31 am

A default hardware shader would be used for all 2D rendering as well so if it is badly written, all 2D stuff may look off.
Another issue is that replacing the lighting code this way may cause problems with certain textures using different shaders, e.g. it would not apply the change to anything with a warp effect.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: "Default" HardwareShader

Postby TehRealSalt » Mon Aug 23, 2021 9:18 pm

I realize my suggestion was naïve after looking more into how the shader code works. I figured out that the default proc_prog_lump (func_normal.fp) is replaceable (until I looked at the source code I just assumed it would always take gzdoom.pk3's, like most of the other files in that folder), which is just a far more simple & less messy method to accomplish the same means anyway.

I guess I'm now just wondering, would it be OK to extent that functionality to light_fragprog without breaking anything? I would like to make dynamic lights look different in my project too, but ProcessMaterialLight doesn't belong in func_normal.fp ... in fact it would just be more convenient in general for what I'm trying to accomplish to go into material_normal.fp than in func_normal.fp.
User avatar
TehRealSalt
ヽ(◕ᴥ◕)ノ
 
Joined: 03 Apr 2014
Discord: TehRealSalt#6754
Github ID: TehRealSalt
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia (Modern GZDoom)

Re: "Default" HardwareShader

Postby Nash » Tue Aug 24, 2021 1:46 am

TehRealSalt wrote:I realize my suggestion was naïve after looking more into how the shader code works. I figured out that the default proc_prog_lump (func_normal.fp) is replaceable (until I looked at the source code I just assumed it would always take gzdoom.pk3's, like most of the other files in that folder), which is just a far more simple & less messy method to accomplish the same means anyway.

I guess I'm now just wondering, would it be OK to extent that functionality to light_fragprog without breaking anything? I would like to make dynamic lights look different in my project too, but ProcessMaterialLight doesn't belong in func_normal.fp ... in fact it would just be more convenient in general for what I'm trying to accomplish to go into material_normal.fp than in func_normal.fp.


Core shader lumps are not meant to be overridable by the mod side... this will most likely be plugged in a future engine update.

People used to do similar things with the main fp/vp in the past, which would break those mods if the engine itself does updates/refactors to the main shaders (which is more likely than most people would think).
User avatar
Nash
AKA Nash Muhandes! Twitter/Facebook/Youtube: nashmuhandes
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Twitch ID: nashmuhandes
Github ID: nashmuhandes

Re: "Default" HardwareShader

Postby Graf Zahl » Tue Aug 24, 2021 2:22 am

You are damn right about plugging that hole. It will now only allow use of user-provided files if a given name does not exist in gzdoom.pk3.
This is not a robust way to do things, any change in how the core shaders are set up might whack a mod doing such a thing.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: "Default" HardwareShader

Postby TehRealSalt » Tue Aug 24, 2021 6:53 pm

Fair enough. I wrote a script to just generate material definitions for every texture ... not my finest moment but seems like the only solution left.

I guess I would only like to ask if it'd be acceptable to open a PR that would not combine in the light_fragprog if you're loading a shader that already contains a ProcessMaterialLight (similar how it only combines other function files if specific functions don't exist / use a deprecated format). That function mostly handles dynamic lights, and you can already put in your own ProcessLight. At worst you could make a mod that creates a black screen from no lighting, but putting in a ProcessLight already lets you do that. It would just let you have more fine control over dynamic lights & how the light color itself is applied.
User avatar
TehRealSalt
ヽ(◕ᴥ◕)ノ
 
Joined: 03 Apr 2014
Discord: TehRealSalt#6754
Github ID: TehRealSalt
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia (Modern GZDoom)


Return to Feature Suggestions

Who is online

Users browsing this forum: No registered users and 0 guests