Page 2 of 4

Re: Shader Help Thread

PostPosted: Thu Sep 14, 2017 10:26 am
by kodi
Is there any way to access the cameras angle(s) in a texture shader? I only know how to get its position.

Edit: I'd also like to know if there's a way to find a sprite/actors origin point for an unrelated WIP shader that does something I'd like to release and share.

Edit 2: seems some type of angle data can be extracted from ViewMatrix[x][y], but it doesn't work for sprites drawn to the screen, at least not without other data. :blergh:

Re: Shader Help Thread

PostPosted: Tue Oct 24, 2017 12:35 pm
by skornedemon
Decided to post here instead of making my own topic.

Ive never dealt with hardware shaders before, least anything 'complex'. I'm looking to try to get this shader: https://www.shadertoy.com/view/ltc3RX used on a texture in gzdoom.
Is anyone willing to help walk me through it? Converting the code to gzdoom's style, implementing, etc.

I was also thinking if we get a few 'generic' shaders in, I could make a new topic in the 'resources' forum so people could easily use them.

Cheers!

Re: Shader Help Thread

PostPosted: Wed Oct 25, 2017 9:18 am
by UsernameAK
Okay, I got GZDoom 3.2.1, but i haven't even bloom effect in option! WTF? (My GPU supports OpenGL 4.5, but gl_legacy_mode is true)

Re: Shader Help Thread

PostPosted: Fri Oct 27, 2017 11:11 am
by Major Cooke
Hey Nash, think you could include this tutorial link to the top of your thread? Trying to relearn shaders and lost the link, big thanks to Gutawer for getting it back to me.

If only converting shaders from toybox to GZDoom wasn't such an insane process...

Re: Shader Help Thread

PostPosted: Fri Oct 27, 2017 1:34 pm
by _mental_
UsernameAK wrote:Okay, I got GZDoom 3.2.1, but i haven't even bloom effect in option! WTF? (My GPU supports OpenGL 4.5, but gl_legacy_mode is true)

Strange, did you try to remove it from config file or set to false?

Re: Shader Help Thread

PostPosted: Fri Oct 27, 2017 1:42 pm
by Rachael
gl_legacy_mode is re-evaluated every time the OpenGL subsystem is initialized - and therefore, cannot be changed with any actual effect in the config file.

Its only purpose is to remove certain menu options when the software renderer is active, if the config file in question was last run in legacy mode.

The fact that it's true means that there was a problem initializing a context that supports advanced features; a startup log would be handy.

Re: Shader Help Thread

PostPosted: Sat Oct 28, 2017 1:40 am
by Nash
Major Cooke wrote:Hey Nash, think you could include this tutorial link to the top of your thread?


Donerino

Re: Shader Help Thread

PostPosted: Sat Oct 28, 2017 8:32 am
by UsernameAK
Rachael wrote:gl_legacy_mode is re-evaluated every time the OpenGL subsystem is initialized - and therefore, cannot be changed with any actual effect in the config file.

Its only purpose is to remove certain menu options when the software renderer is active, if the config file in question was last run in legacy mode.

The fact that it's true means that there was a problem initializing a context that supports advanced features; a startup log would be handy.

Spoiler: GZDoom log


Well, why does it work in compat profile?

Spoiler: glxinfo

Re: Shader Help Thread

PostPosted: Sat Oct 28, 2017 8:33 am
by UsernameAK
and yes, add uniform system to old fragment shader system

Re: Shader Help Thread

PostPosted: Sat Oct 28, 2017 8:49 am
by _mental_
Most likely it's the same problem as in this report. There is a patch in the topic although we need volunteers to check it.

Re: Shader Help Thread

PostPosted: Sat Oct 28, 2017 1:22 pm
by UsernameAK
_mental_ wrote:Most likely it's the same problem as in this report. There is a patch in the topic although we need volunteers to check it.

Code: Select allExpand view
MESA_GL_VERSION_OVERRIDE=4.5 ./gzdoom
works well

Re: Shader Help Thread

PostPosted: Sat Oct 28, 2017 1:54 pm
by _mental_
This should be fixed in code so proper OpenGL profile will be selected by default, i.e. without environment variables or any other user actions.
Unfortunately I can check in VM only but this definitely needs to be tested on real hardware.

Re: Shader Help Thread

PostPosted: Wed Mar 28, 2018 4:05 am
by Pixel Eater
Before I make a fool of myself with a feature request I thought I'd ask something here. How feasible would it be for GZDoom to store a texture of the scene "pre-shaded" for custom shaders to access? It would look the same as if the light amplification visor were on. The idea is that the shader would be able to determine whether the pixel it's processing had been affected by the lighting system and by what amount by comparing it to the proposed texture. I think there could be some interesting effects made achievable with this setup.
What do people think? Is the concept flawed or maybe impractically slow?

Re: Shader Help Thread

PostPosted: Wed Mar 28, 2018 4:27 am
by dpJudas
This would require GZDoom to output an extra gbuffer with this information. Technically possible, nothing of this sort is currently planned. If such a thing was added it wouldn't make sense to hardcode it output a "pre-shaded" value - it would be better to allow texture shaders to output anything they want into such gbuffers.

Re: Shader Help Thread

PostPosted: Wed Mar 28, 2018 5:03 am
by Pixel Eater
Sorry dpJudas, I'm having trouble following. I looked up what a g-buffer is and it sounds like what I'm suggesting. Except where you are mentioning shaders writing to the texture I'm hoping to have them read from it.
The goal here is for the shader to separate what is an index colour from what has been shaded by the lighting and by how much.

Edit: I'm referring to post-processing shaders in case I haven't mentioned :oops: