This obviously isn't ready yet, it will need some work (and extreme amounts of testing - you can't EVER be sure that it works)

My goal for now:

• Is to make a functional renderer that works cross-platform - Windows and Linux (macOS if I manage to get my hands on it)
• That my build system doesn't puke upon adding a new dependency (GLEW)
• To add configuration options, which include specifying a shader file (fragment and vertex for "cool effects")
• Add default shader files from which the user can poke around, preferably placed in in the config directory and included with the install environment (cmake + NSIS)

Also doesn't my project become GLava basically after these mods (except it has windows support)?

Yes, defining the shader files in the config would be pretty good. In the GLSL code, we need to access X.A.V.A. variables, it would be good if you could pass:

• A function called data that we call with a float from 0 to 1 as an argument, it returns the bar height.
• A float variable called time that is seconds since X.A.V.A. start.
• A vec2 variable called resolution that is the screen resolution.
• A float variable called bar_width that is the bar width.
• A float variable called bar_spacing that is the bar spacing.
• A float variable called bar_count that is the bar count.

If you have another idea of variables to pass, go ahead.
PS: This isn't GLava as it is cross-platform.

Also while the code works it is less efficient in terms of video card usage

Didn't build it properly, I'm good now, no shadows though...

Did some work on it, I figured out (somewhat) what to do. But there are so many annoying bugs to fix. (fxp. shader compilation failures, as OGL is asyncronous AF). And also the way that I deal with variables is backstabing me. I'm thinking of just making all major variables global, since having 3 different variables with the same name is driving me insane (messy code, i know).....

Will update as I go through on this.

But I think the first order of duty is to update the branch to mainline, since the removal of bar limits is causing seg. faults all over the place. Thank GDB for giving me insight about my variable issue.

Also your assumption is correct, shaders are expesive (in cycles) as it gets when it comes to code. Any slight change to the shader code can change the temps of the GPU from 40 to 80*C.

But I'm thinking of doing geometry inside of a shader, that'll give more flexibility to the developer/end-user (and possibly reduce the load). Only catch though: it's not EGL friendly.

Also those shaders (that you demonstrated) draw every single pixel, unlike real fragment shaders which are ran on every pixel that is occupied by a 2d raster of the final polygon.

Can I work around this by using two polygons that just cover the entire screen and use fragment shaders for the final image? (kinda hacky, but may work)

Yeah, I think having 2 polygons that cover the screen is an idea worth exploring but the frag makers need to have an easy way to map the fragment shader to the screen.

update: the two polygon thing is working, I've managed to cram the entire renderer into a fragment shader that runs about 30 lines of code per pixel (not sure if it's bad or not)

comparing with the legacy OGL code it uses 20% more GPU, but it's not so bad as you get the complete flexibility of GLSL

However, uno problemo: GLSL had no way to put a dynamic array as an "uniform" variable up until OGL 4.0
So my workaround was to limit the bars to something absurdly high, such as 10000 bars. I did this because like 70% of all computers I ever used barely go above OGL 3.0, so I've did it like this in order to preserve compatibility.

Also the current shader I wrote is about 100 LoC and implements most features (80%) and works with the minimum version tag of 110 = OGL 2.0 minimum, which is ok compatibility IMO.

Yup, sounds great, +20% GPU should be fine for most people.

Review this, and try to find bugs and other things (if you're willing to do so).
Anyway I think this is the polishing phase.

Just need to update the windows code as well, and do a bit of testing there before merging.

Anyway it wasn't 20% more it was more like triple, my benchmarking was flawed.
However I believe I can optimize the shader as the GPU isn't that good at doing logic (for which I rely heavily on)
So I believe more reliance on floats should help in any case.
Would writing inline code help as well?

Besides it's only 10% of my GPU (when I disable compositing ofc)

Also the conversion between ints and floats is expensive, so maybe it's that.

Ok, I will test it ASAP, thanks!

"xava" terminated by signal SIGSEGV (Adress boundary error), basically a segmentation fault...

Also, shaders do not get copied over by install and it has to regenerate them in Ubuntu 20.04...
xava installs to /usr/local/bin/xava

"xava" terminated by signal SIGSEGV (Adress boundary error), basically a segmentation fault...

Error is in src/config.c line 226, it does: assert(!(fragmentShader&&vertexShader));
So if you check the memory addresses instead it goes a bit further(assert(!(*fragmentShader&&*vertexShader));), so basically one of those vars is null...

Both should be non-NULL at that point... I have no idea what might be going on.

I mean look at the lines behind... it's just two mallocs!?!

Also it doesn't matter if the package is installed in /usror /usr/local as all hardcoded directory paths are generated on compile time, so if CMake built it for a PREFIX=/usr/local, all the functions would be using that.

Gonna have to rebuild it on another PC to find out what is going on, in the meantime do you have a Windows build?

I have to work on it since I've changed the renderer code

New system, different error...

It works but there is no way to make another shader, in the config changing the shader variable does nothing.