So I went and implemented my own reader for #include "?" directives (to the extent of find any and just insert the code into the buffer with a #line directive before & after the inserted code, added the needed #extension directive at the top of my initial shader files and another #line directive to ensure that doesn’t throw debug info off either, I am now however encountering an issue that is in part GLSL (in that the resulting GLSL is apparently wrong) but I’m just not seeing where the error lies, without seeing it I cannot look for the C code that produces the erroneous code, someone mind having a look at my output to see if they can spot the error:
make debug=1 run
...
cd bin && ./d-check_extra.elf
Attempting to open 'libd-vfxglfw.so' & 'libd-vfxgl.so'
Creating program '[vfxapp.flat]'
src/extra/viewfx/gl/opengl_shader.c:93: Error 0xFFFFFFFF (-1) EUNKNOWN
src/extra/viewfx/shader.c:251: Error 0xFFFFFFFF (-1) EUNKNOWN
src/extra/viewfx/vfxapp.c:462: Error 0xFFFFFFFF (-1) EUNKNOWN
src/extra/viewfx/vfxapp.c:127: In shader 'point', path = 'shaders/null.glsl'
shaders/null.glsl:3(26): preprocessor error: syntax error, unexpected IDENTIFIER, expecting INTEGER or INTEGER_STRING or NEWLINE or PATH
#version 440
#extension GL_ARB_shading_language_include : require
#line 1 shaders/null.glsl
#ifndef SHARED_H
#line 1 shaders/same.glsl
#define SHARED_H
uniform UINTS { uint unused; } uints;
uniform DINTS
{
int FlatLine;
int VtxCount;
ivec2 WinPoint;
ivec3 WinSpace;
} dints;
uniform FNUMS
{
float unsused;
vec3s WinScale;
vec3s RegScale;
vec3s RegPoint;
/* Light emitted */
vec3s RegEmits;
/* Light taken before ray bounces */
vec3s RegTakes;
};
uniform DNUMS { double unused; } dnums;
#endif
src/extra/viewfx/vfxapp.c:141:
src/extra/viewfx/vfxapp.c:599: Error 0xFFFFFFFF (-1) EUNKNOWN
src/extra/viewfx/vfxapp.c:612: Error 0xFFFFFFFF (-1) EUNKNOWN
test/extra/launch.c:22: Error 0xFFFFFFFF (-1) EUNKNOWN
test/extra/main.c:108: Error 0xFFFFFFFF (-1) EUNKNOWN
Compilation finished successfully.
So you’re implementing #include manually by scanning the shader source and adjusting it. But you’re also… using the GL_ARB_shading_language_include extension.
#line must have, after macro substitution, one of the following forms: #line line #line line source-string-number
where line and source-string-number are constant integer expressions. If these constant expressions
are not integer literals then behavior is undefined. After processing this directive (including its
new-line), the implementation will behave as if it is compiling at line number line and source string
number source-string-number. Subsequent source strings will be numbered sequentially, until
another #line directive overrides that numbering.
The #line preprocessor directive does not accept a string as second argument, only constant integer expressions, that seems to match the error you are getting.
I went looking for that info, never found it, thx, I’ll have to modify my code to support that later but for now stringifying it is shutting it up about that particular error, getting another glsl error which is possibly of the same kind, just different type, I’ll post it after I finished adapting my log retrieval function to remove the quotes from the file path
Edit: Well here’s the other error, output included for context:
make debug=1 run
…
cd bin && ./d-check_extra.elf
Attempting to open ‘libd-vfxglfw.so’ & ‘libd-vfxgl.so’
Creating program ‘[vfxapp.flat]’
source = GL_DEBUG_SOURCE_SHADER_COMPILER, defect = GL_DEBUG_TYPE_ERROR, weight = GL_DEBUG_SEVERITY_HIGH, fromid = 1 (GL_ID_UNKOWN)
report = “shaders/same.glsl”:15(2): error: syntax error, unexpected NEW_IDENTIFIER, expecting ‘}’
src/extra/viewfx/gl/opengl_shader.c:110: Error 0xFFFFFFFF (-1) EUNKNOWN
src/extra/viewfx/shader.c:251: Error 0xFFFFFFFF (-1) EUNKNOWN
src/extra/viewfx/vfxapp.c:462: Error 0xFFFFFFFF (-1) EUNKNOWN
src/extra/viewfx/vfxapp.c:127: In shader ‘point’, path = ‘shaders/null.glsl’
shaders/same.glsl:15(2): error: syntax error, unexpected NEW_IDENTIFIER
Edit: 2 Tried modifying the method of posting the output to split the code from the general output, seems to have went reasonably well judging by the preview
Edit3 : btw I have noticed that main() is getting chopped off along with the #line directive that should be appearing directly after the #endif, I just don’t understand why opengl is complaining about that 15th line in same.glsl (float unused)
insert face emoji here forgot I had transplanted that from my C headers that are using cglm, is there a shader language specific define I can use to detect when not a C header? I’d like to use defines to avoid manual matching of uniforms vs C structs.
Since my next bug is not directly related to opengl I’ve opened up a new thread elsewhere but since it’s a follow on from these bugs I figured I’d at least mention the link in case someone here wants to go join that thread also out of interest.
regarding this topic, what if I have an array of vec3 or an array of mat3, how should I deal with in on a SSBO?
Should I delcare it as a vec4 or mat4 (respectively) and then convert it to a vec3/mat3? Won’t it consume more bandwidth wen sending it to the shader? And, do I need to convert my Mat3 within the application in order to send out Mat4 to the shader?
Don’t use those. Just use vec4 or mat4. Don’t “convert” them to anything; just don’t use them.
If you can, try to find some use for the extra space. And if not, so be it.
An array of vec3 will take up the exact same space (and therefore bandwidth) as an array of vec4. An array of mat3 will take up the same space as an array of mat3x4 (or mat4x3 with row_major layout). So just don’t use them.