[Feature Request] Glow bars...

[make-42]

Basically like the shadow effect but with colors and gradients...

[nikp123]

you can change the shadow color, which should achieve the same effect, though gradients are yet to be implemented

[make-42]

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

[make-42]

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

}

http://glslsandbox.com/e#65127.5

[nikp123]

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.

[nikp123]

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.

https://github.com/nikp123/xava/tree/opengl-vbo

[nikp123]

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.

[make-42]

Will do!

[make-42]

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

[make-42]

Improved the demo and edited my comment...

[make-42]

Hell yeah! Nice work!

[make-42]

Made it generate a curve http://glslsandbox.com/e#65127.6

[make-42]

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

[make-42]

ehehehehe http://glslsandbox.com/e#65239.0

[make-42]

A short video shot at 800x450,60fps showing my shader in action... XAVAShaderDemo.zip

[make-42]

Ported my shader to GLava in about 10 min...

reencodeportedtoglava.zip

[nikp123]

Guess I closed this issue by accident, sorry.

[nikp123]

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:

• Customizable (being able to change not just the looks, but also the shape of the visualizer) - like being able to go from bars (the default) to a circle (potentially)
• Lightweight (I mean this speaks for itself really)
• Simple to implement (Like not adding an additional 10k SLOC and/or chaning the entire codebase to accomidate the change)

solution, I would gladly accept it.

[nikp123]

dynamically loading code sounds fun

Obviously need to clean this up and make the functionality flawless before even thinking about merging it to master.

[nikp123]

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.

[nikp123]

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

[make-42]

:+1:

[nikp123]

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

[nikp123]

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.

[make-42]

Sounds good to me!

[nikp123]

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

[make-42]

Will do when X11 port is done!

[nikp123]

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

[nikp123]

literally took me less than an hour

PS: x11_egl is what you're after

[make-42]

gonna test it out if I have free time today

[make-42]

Error while building unstable xava: error while loading shared libraries: libxava-shared.so: cannot open shared object file: No such file or directory