Open make-42 opened 4 years ago
you can change the shadow color, which should achieve the same effect, though gradients are yet to be implemented
It sort of achieves it but I think a different spreading curve and having it be on both sides of the bars would make the glow more convincing
I made a demo with GLSL of what a glow effect could look like.
#ifdef GL_ES
precision mediump float;
#endif
#extension GL_OES_standard_derivatives : enable
uniform vec2 resolution;
uniform float time;
float rand(float n){return fract(sin(n) * 43758.5453123);}
float noise(float p){
float fl = floor(p);
float fc = fract(p);
return mix(rand(fl), rand(fl + 1.0), fc);
}
void main( void ) {
vec2 position = ( gl_FragCoord.xy / resolution.xy );
float brightness=1.;
float color = 0.0;
float r = (position.y*0.843)+((1.-position.y)*0.243);
float g = (position.y*0.)+((1.-position.y)*0.286);
float b = (position.y*0.564)+((1.-position.y)*1.);
float barheight = (noise(position.x+time))*(1.-position.y);
color += ceil(sin(position.x*50.));
color += exp(sin(position.x*50.)/brightness);
color *= barheight;
gl_FragColor = vec4( vec3( color*r, color*g,color*b),1);
}
True, it's as convincing as I thought it would be. Since shaders achieve a lot of functionality that pure code doesn't, I though of migrating the entire OGL renderer to be VBO based instead of 90s OGL, which would allow me to just cram in shaders. But I have no idea how to organize them, so that would be a major pain to do. Also this would resolve many workarounds that I've implemented simply due to default shaders being different on different drivers and OS-es. I think I have a demo working in VBO, so that would be a good starting point.
The tree is 70 commits old, so it shouldn't be that hard to work with. Just updates are going to be slow since I'm busy atm.
Also since I'm kinda bad with OGL, can you link me to a resource where I could share local variables (in C code) with shader code.
Will do!
OpenGL Shading Language 4.5 Documentation: https://www.khronos.org/registry/OpenGL-Refpages/gl4/ IO GLSL code: https://gamedev.stackexchange.com/questions/29672/in-out-keywords-in-glsl
Improved the demo and edited my comment...
Hell yeah! Nice work!
Made it generate a curve http://glslsandbox.com/e#65127.6
For integrating it inside the program I just need to replace float barheight = (noise(position.x+time))*(1.-position.y);
with float barheight = data(position.y);
ehehehehe http://glslsandbox.com/e#65239.0
A short video shot at 800x450,60fps showing my shader in action... XAVAShaderDemo.zip
Ported my shader to GLava in about 10 min...
Guess I closed this issue by accident, sorry.
I'm adding the "help wanted", since the current shader is quite unoptimized (a whole third of an Intel HD5500 used when being run). If anyone could come up with a:
solution, I would gladly accept it.
dynamically loading code sounds fun
Obviously need to clean this up and make the functionality flawless before even thinking about merging it to master.
by the way, I think leaving XAVA logic purely to the cpu is the best option, while I could for example make an output mode which processes shaders on top of what the dynamic function did
If this turns out to be the best solution, redoing this as a lib would be the solution, since it doesnt interfere with what I've already done, increasing stability.
I guess implementing geometry shaders would be better, as doing this logic in fragments is just silly.
Anyway future me, start off here: https://www.youtube.com/watch?v=r2hue52wLF4
:+1:
Conflicted once again, as geometry shaders do not work on EGL (which I'm trying to switch to (because wayland))
I guess I'll just add textures to absolutely everything or something else "creative".
EGL in wayland is a thing now and shaders work
However planning to add more variables such as intensity
and post-rendering textures so you can do your magic.
Sounds good to me!
Well, it's done.
Only thing left to do is port this thing back to X11 and add a few useful parameters as mentioned.
For your use case @xE0F9, you can fiddle around with the "post shaders".
Will do when X11 port is done!
Will do when X11 port is done!
Speaking of which, like a good 80% of the code is reusable, so the port should be a piece of cake (figuratively).
literally took me less than an hour
PS: x11_egl
is what you're after
gonna test it out if I have free time today
Error while building unstable
xava: error while loading shared libraries: libxava-shared.so: cannot open shared object file: No such file or directory
Error while building unstable
xava: error while loading shared libraries: libxava-shared.so: cannot open shared object file: No such file or directory
try make install
-ing it
still nothing
try to cd into the build directory, i mean "it works on my machine"(TM)
or maybe just LD_LIBRARY_PATH=.
when running xava
that works
[ERROR] EGLCreateContext at src/output/shared/egl.c:401 - EGL was unable to create a surface
[ERROR] EGLShaderBuild at src/output/shared/egl.c:94 - Failed to build shader
Seems like this is an issue with my Arch install I will try on another pc
@xE0F9 most likely your display driver doesnt support EGL unfortunately
In 2 hours I'm going to test on an RTX 3090 to see if it works.
[WARN] xavaFindAndCheckFile at src/shared.c:182 - The current system does not support XDG_CONFIG_HOME.
There is a high likelyhood that something may be broken
[ERROR] xavaFindAndCheckFile at src/shared.c:186 - This system is $HOME-less. Aborting execution...
iniparser: cannot open /home/ontake/xava/
Is this normal?
[WARN] xavaFindAndCheckFile at src/shared.c:182 - The current system does not support XDG_CONFIG_HOME. There is a high likelyhood that something may be broken [ERROR] xavaFindAndCheckFile at src/shared.c:186 - This system is $HOME-less. Aborting execution... iniparser: cannot open /home/ontake/xava/ Is this normal?
it's not, as expected, i'd have to look into it
for some reason it occurs only when using an X11 session. Something weird is going on
Fixed. Anyway it was a dumb memory safety issue. Should probs learn nim or rust.
The amount of memory errors is ridiculous.
Should be fixed?
Should be fixed?
Yes, obviously.
Should be fixed?
try regardless, i cant know memory errors ahead of time
Shaders are progressing ;)
Tho atm they kinda GPU heavy for an Intel HD 5500 that barely can render anything
and by that I mean this
Current implementation is kinda soft: https://gist.github.com/nikp123/19047776f961bd9e725a003574f3c039
tho im kinda probably use something like this
Basically like the shadow effect but with colors and gradients...