Jump to content

  • Log In with Google      Sign In   
  • Create Account


Help with Compilation Error: 0:2

  • You cannot reply to this topic
9 replies to this topic

#1 Thiatsii   Members   -  Reputation: 145

Like
0Likes
Like

Posted 15 August 2014 - 03:56 AM

I hate to admit defeat at finding an answer to my problem, but after 6 hours of searching... I realize I better bite the bullet and ask those who know.

 

Background: I'm on Win7 64 using MSVS 2010 pro trying to compile Open GL source from Jorge Rodriquez' Math for Game Developers. Project compiles, windows pop up, disappear, and then spits out...

 

ERROR: 0:2: '' : Declaration must include a precision qualifier or the default precision must have been previously declared. 
ERROR:  compilation errors.  No code generated.  blink.png
 
Any help at all would be greatly appreciated. biggrin.png


Sponsor:

#2 Ohforf sake   Members   -  Reputation: 1794

Like
0Likes
Like

Posted 15 August 2014 - 04:42 AM

That's an error message from compiling a shader, not the program itself. And one I would expect from an OpenGL ES context, not from a plain OpenGL context. Can you post the shader that is causing this?

#3 Thiatsii   Members   -  Reputation: 145

Like
0Likes
Like

Posted 15 August 2014 - 04:54 AM

the source is from github here. I tried looking through the files... but so far no luck.

 

All I see for reference is: #include <GL3/gl3w.h>


Edited by Thiatsii, 15 August 2014 - 05:00 AM.


#4 BitMaster   Crossbones+   -  Reputation: 3883

Like
0Likes
Like

Posted 15 August 2014 - 08:17 AM

The line you are quoting appears to be C++ code. As Ohforf sake already said, the error message originates from GLSL though. At some point in your program glCompileShader is called  but fails and the error message you are seeing is retrieved with glGetShaderInfoLog. The problem you are seeing happens because something is wrong with the GLSL source which has been passed to that shader before using glShaderSource. Find out what kind of source has been passed and either fix it yourself or post it here. That should not be complicated to find out using the debugger. 



#5 haegarr   Crossbones+   -  Reputation: 4166

Like
1Likes
Like

Posted 15 August 2014 - 09:15 AM

That should not be complicated to find out using the debugger.

Seconded.

 

@OP: Here is a how-to (actually done without debugger, but using the debugger would have made investigations even easier; you should try it):

 

1.) With the hints given in above answers, you should be able to find the file within the C++ sources that is used to compile the shaders.

 

2.) If you investigate that CPP, you'll see that shader scripts are assembled into string variables. You'll see further that most of the shader scripts originates from the "content/shaders/" subfolder. Therein are 2 include files functions.si and header.si, a vertex shader pass.vs, and a fragment shader model.fs.

 

3.) Looking into the shader files, you'll see that there is a line "#version 130" which denotes the version of GLSL that the shader compiler should use.

 

4.) Looking at the error text, the keywords mentioned there are "precision" and "default qualifier", which both are missed.

 

5.) With this knowledge you visit www.opengl.org (or alternatively www.khronos.org) and navigate to the OpenGL specifications section. There you locate the GLSL specification that matches "#version 130", which you'll find as GLSLangSpec.Full.1.30.10.pdf. Download it, open it...

 

6.) ... and search for the keyword "precision". You'll find it explained in section 4.5 and especially 4.5.3 "Default Precision Qualifiers". At the end of that section you can read:

 

The vertex language has the following predeclared globally scoped default precision statements:

           precision highp float;
           precision highp int;

The fragment language has the following predeclared globally scoped default precision statement:

           precision mediump int;

The fragment language has no default precision qualifier for floating point types. Hence for float, floating point vector and matrix variable declarations, either the declaration must include a precision qualifier or the default float precision must have been previously declared. 

 

This leads to the conclusion that your fragment shader uses a float type but does not declare any precision for it.

 

7.) So ... going back to model.fs and see "yep, that's actually true".

 

8.) Correct the irregularity and try again.

 

 

Perhaps this isn't the actual solution, but anyway should demonstrate how to attack such a problem.


Edited by haegarr, 15 August 2014 - 09:16 AM.


#6 Thiatsii   Members   -  Reputation: 145

Like
0Likes
Like

Posted 15 August 2014 - 10:48 AM

Thankyou Ohforf sake, haegarr and BitMaster. I actually managed to get to that page on khronos before I posted here, yet I was still baffled on where to look in the code. Your explanation though, got me right to the model.fs. This Open GL is an entirely different animal which I will have to acquaint myself with. I have to say that the last 2 months has been devoted entirely to DirectX. Yep... noob when it comes to graphics programming. I'm only redeemed in the realms of modeling and animation. Anyhow... this is the file, but I don't have a clue where to fix it. If it wasn't for the awesome video tutorials on math related to graphics programming, I would have thrown in the towel long ago.

</span>
<span  style="font-size:14px">uniform bool bDiffuse = false;</span>
uniform sampler2D iDiffuse;
uniform vec4 vecColor = vec4(1.0, 1.0, 1.0, 1.0);
 
uniform vec3 vecSunlight;
 
uniform float flAlpha;
 
in vec3 vecFragmentPosition;
in vec2 vecFragmentTexCoord0;
in vec3 vecFragmentNormal;
in vec3 vecFragmentColor;
 
uniform mat4 mView;
uniform mat4 mGlobal;
 
void main()
{
// This 3x3 matrix should have the rotation components only. We need it to transform the fragment normals into world space.
mat3 mGlobal3x3 = mat3(mGlobal);
 
// Dot product of the sunlight vector and the normal vector of this surface
float flLightDot = dot(vecSunlight, normalize(mGlobal3x3*vecFragmentNormal));
 
// Remap the light values so that the negative result becomes positive
float flLight = RemapVal(flLightDot, -1.0, 0.0, 0.9, 0.4);
 
// Multiply that by the color to make a shadow
vec4 vecDiffuse = vecColor * flLight;
 
// Add in a diffuse if there is one
if (bDiffuse)
vecDiffuse *= texture(iDiffuse, vecFragmentTexCoord0);
 
// Use that as our output color
vecOutputColor = vecDiffuse;
 
if (vecDiffuse.a < 0.01)
discard;
<span  style="font-size:14px">}</span><span  style="color:rgb(0,0,0);font-family:'Courier New';font-size:13.714285850524902px;">


Edited by Thiatsii, 15 August 2014 - 11:00 AM.


#7 haegarr   Crossbones+   -  Reputation: 4166

Like
0Likes
Like

Posted 15 August 2014 - 11:11 AM


... but was still baffled on where to look in the code ...

As BitMaster told, look for "glGetShaderInfoLog"; you can use a simple text search function for that. The term occurs in "renderer/shaders.cpp" two times, once for the vertex shader and once for the fragment shader, locates in the CShader::Compile routine. At the beginning of that routine you can see that files inside the "shaders/" sub-directory are opened, read in, and their content appended to string variables, which themselves are passed to the glShaderSource routines.

 


... but I don't have a clue where to fix it.

Well, from a compilers point of view and considering the quoted part of the specification, it should be fixed before the first occurrence of a float, float vector, or float matrix. So you can try and place the fix at the very beginning of the shader script, because already in the 2nd line there is a float vec4 declaration.

 

However, as told earlier, the source that is passed to the shader compiler seems to be assembled from various files. So the above solution (which considers only a single file) may or may not work. Hence the better way would be: Start your debugger, set a breakpoint where the fragment script's glShaderSource is invoked, and check how the entire script (as referred to by pszStr) looks like. Then decide where to place the fix.



#8 Thiatsii   Members   -  Reputation: 145

Like
0Likes
Like

Posted 15 August 2014 - 12:13 PM

Thanks again for all the help. All I keep seeing is a ridiculous amount of  f  ra   g me  nt ed  fr ag  men ts... and after 13 hours on this I'm just going to give up. Does code REALLY need to be diced into to so many pieces?  wacko.png This isn't even my code!


Edited by Thiatsii, 15 August 2014 - 12:14 PM.


#9 BitMaster   Crossbones+   -  Reputation: 3883

Like
0Likes
Like

Posted 16 August 2014 - 12:58 AM

If that the source you posted is indeed the one causing the problems the important line should be:

uniform vec4 vecColor = vec4(1.0, 1.0, 1.0, 1.0);

Out of the top of my head, add a "#version 330" as the very first line and see if that fixes the problem. You might have to do that for every GLSL code used. Initializing a uniform with a default value was not allowed in GLSL from the start and unless you specify which version to use explicitly, the driver's compiler should use the very first GLSL version.



#10 Thiatsii   Members   -  Reputation: 145

Like
0Likes
Like

Posted 16 August 2014 - 12:32 PM


add a "#version 330" as the very first line and see if that fixes the problem

 

Nada. Zip. Kaput. Thank you though.

Aside: I am in contact with the author and will post up what the result ends up being.







PARTNERS