"Default" HardwareShader

[TehRealSalt]

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 all

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 all

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 all

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)

[Nash]

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...

[Graf Zahl]

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.

[Rachael]

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?

[dpJudas]

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.

[Graf Zahl]

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.

[TehRealSalt]

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.

[Nash]

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).

[Graf Zahl]

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.

[TehRealSalt]

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.