Have a cross-language bug I need help with

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.

Why?

Also, never use vec3s of any kind in uniform blocks.

The GLSL spec says this about #line:

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

opengl refused to process the #line directives without it

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

#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	unused;
	vec3s	WinScale;
	vec3s	RegScale;
	vec3s	RegPoint;
	/* Light emitted */
	vec3s	RegEmits;
	/* Light taken before ray bounces */
	vec3s	RegTakes;
} fnums;
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.

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)

My guess it is off by one line and actually complaining about vec3s.

Even if it is I still can’t see why it’s complaining, as far as I can see I haven’t made any syntax errors there

vec3s is not a valid GLSL type, nor have you defined a struct of that type. vec3 is a type.

Also, please stop using it in UBOs.

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.

Well, GLSL has one of 3 pre-defined macros, depending on which profile the shader is being compiled for. So if you do:

#if defined(GL_core_profile) || defined(GL_compatibility_profile) || defined(GL_es_profile)
...
#endif

That would work.

1 Like

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.

https://cboard.cprogramming.com/c-programming/180799-insertion-bug.html

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.

Just use mat4 in your application too.

Didn’t work out:

#if defined(GL_core_profile) || \
	defined(GL_compatibility_profile) || defined(GL_es_profile)
#define IS_OPENGL
/* Mappings to CGLM union names */
#define uvec2s	uvec2
#define uvec3s	uvec3
#define uvec4s	uvec4
#define ivec2s	ivec2
#define ivec3s	ivec3
#define ivec4s	ivec4
#define vec2s	vec2
#define vec3s	vec3
#define vec4s	vec4
#define dvec2s	dvec2
#define dvec3s	dvec3
#define dvec4s	dvec4
#else
#include <cglm/struct.h>
#include <cglm/cglm.h>
#include <cglm/call.h>
#define uniform typedef struct
#endif

Opengl saw the second half when it shouldn’t have

Edit: Whoops,forgot that could be my own code’s error, and it was, I’ll take it to the cboard instead

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.