Jump to content

  • Log In with Google      Sign In   
  • Create Account


Vertex shader's failing to link...


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

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

#1 Aumnayan   Members   -  Reputation: 111

Like
0Likes
Like

Posted 13 August 2012 - 12:30 PM

I added the sampler1D colorTexture, the color offset and tmp calculations and changed the color from color = vColor. I'm simply not seeing why this wouldn't be linking. If I change color = tmp.rgba; to color = vColor; it links appropriately.

[source lang="cpp"]GLbyte TerrainVertexShaderStr[] = "uniform sampler1D colorTexture; \n" "in vec4 vPosition; \n" // Vertex Position "in vec3 vNormal; \n" // Normal "in vec4 vColor; \n" // The RGBA color "in vec2 vTexCoord; \n" // Texture Coordinate "out vec2 texCrd; \n" "out vec4 color; \n" "void main () { \n" " texCrd = vTexCoord; \n" " float color_offset; \n" " vec4 tmp; \n" " color_offset = (gl_Vertex.y + 400.0f) / 5120.0f; \n" " tmp = texture1D(colorTexture, color_offset); \n" " color = tmp.rgba; \n" " gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex; \n" "}";GLbyte TerrainFragmentShaderStr[] = "uniform sampler2D grndTexture; \n" "in vec4 color; \n" "in vec2 texCrd; \n" "void main () { \n" " vec4 tcolor = texture(grndTexture, texCrd); \n" " gl_FragColor = color * tcolor; \n" "}";[/source]

Sponsor:

#2 tanzanite7   Members   -  Reputation: 1247

Like
2Likes
Like

Posted 13 August 2012 - 02:21 PM

Erm, you forgot to tell what is the reported link error!

Code looks fine to me - bad drivers? Might confuse the driver with the no-op "rgba" swizzle/selector.

#3 mhagain   Crossbones+   -  Reputation: 7867

Like
0Likes
Like

Posted 13 August 2012 - 03:22 PM

There's no need for the use of tmp at all here - in fact the compiler should optimize it out (if it's doing it's job right). Maybe try "color = texture1D (colorTexture, color_offset);" instead?

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#4 Ignifex   Members   -  Reputation: 507

Like
0Likes
Like

Posted 14 August 2012 - 03:10 AM

GLSL does not use an 'f' after floating point constants. Any floating point is considered 32 bits, unless specified as a half. This causes a compilation error.
The reason you are not getting the error when using color = vColor; is because the compiler optimizes out your entire color_offset and texture1d statements.

#5 BitMaster   Crossbones+   -  Reputation: 3964

Like
0Likes
Like

Posted 14 August 2012 - 03:16 AM

Actually "f" as a suffix is allowed, it's just not needed in most cases.

That aside, you should be calling glGetShaderInfoLog to retrieve the actual error. It will most likely be something extremely simple once you see the error messages from the driver.

#6 mhagain   Crossbones+   -  Reputation: 7867

Like
0Likes
Like

Posted 14 August 2012 - 03:29 AM

Actually "f" as a suffix is allowed, it's just not needed in most cases.


Depending on your GL_VERSION and/or driver it may or may not be. The original GLSL specs explicitly didn't allow it and it should cause a compile to fail; NVIDIA have always accepted it.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#7 BitMaster   Crossbones+   -  Reputation: 3964

Like
0Likes
Like

Posted 14 August 2012 - 03:34 AM

Interesting. I'm pretty sure I sometimes mistyped float values with "f" on my hobby project and it compiled on an AMD card (that would be #version 330 then though). I tried finding which version started allowing it but could not find anything useful in a hurry. The Wiki mentions it explicitly for turning integer constants into floats but unfortunately does not make a clear distinction regarding the version.

While I certainly appreciate the correction, the core issue still stands: use glGetShaderInfoLog, it tells you everything you need to know about your errors without all the guesswork.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS